Sprint1 - srybi/datavis GitHub Wiki

[[TOC]]

Download APK Sprint 1

09.05.2022 - 23.05.2022

• Aufbau des Applikationsgerüsts: Eine funktionierende Applikation mit Interface.
• Dateien können ausgewählt und in die Applikation geladen werden.
• Die Antenne kann dargestellt werden.
• Es können Sphären dargestellt werden, die in späteren Sprints mit der Logik der .ffs Datei verknüpft werden

ID	Name	Priority	Story Points
US_101	Positionierung der Antenne im Raum	Middle	3
US_108	Kombinierte Darstellung von Antenne und Feldstärke	Middle	2
US_110	Feldstärke als Schar von Sphären anzeigen	High	5
US_113	Farbliche Darstellung von Sphären	Low	2
US_201	Hochladen von Rohdaten	High	2
US_305	Interpretation der .ffs Dateien in linearer Darstellung	High	13
US_306	Interpretation der .ffs Dateien in logaritmischer Darstellung		5
US_404	Skalierung der Feldstärke	Middle	8

Velocity (Summe der SP): 40

• .glb und .ffs Datein können in der App in einer Maske hochgeladen werden. Das System speichert die Verknüpfung dieser beiden Datein.
• Der Nutzer kann wie gewohnt, eine Feldstäke auswählen, um diese dann in AR darzustellen. In der Landing Page können noch nicht die hochgeladenen Antennen ausgewählt werden, wie eigentlich geplant (siehe GUI).
• Eine .ffs Datei mit mehren Frequenzen kann gelesen werden. Die Anzahl der Frequenzen und die Anzahl der Samples wird zwar berechnet, jedoch wird nur die erste Frequenz tatsächlich abgebildet.
• Die Feldstärke wird - fast schon wie in CST - in AR abgebildet. Dabei werden die einzelnen Spähren abhängig ihrer Intensität passend eingefärbt. Das Farb-Mapping findet ebenfalls wie in CST statt. Größte Intensität bildet die Obergrenze.

  Untergrenze = Obergrenze - 1

• Die Skalierung der Spähren und der Antenne findet nicht dynamisch statt, es wurden stattdessen Skalierungsfaktoren im Code hinterlegt.
• Es wurden Unit Test geschrieben, die die Berechnungen der Spähren Koordinaten mit einem erwarteten Wert vergleichen.

ID	Name	Ist-Status
US_101	Positionierung der Antenne im Raum	Closed
US_108	Kombinierte Darstellung von Antenne und Feldstärke	Closed
US_110	Feldstärke als Schar von Sphären anzeigen	Closed
US_113	Farbliche Darstellung von Sphären	Closed
US_201	Hochladen von Rohdaten	On Going
US_305	Interpretation der .ffs Dateien in linearer Darstellung	On Going
US_306	Interpretation der .ffs Dateien in logaritmischer Darstellung	On Going
US_404	Skalierung der Feldstärke	On Going

• Warum ist US_201 On Going?
  • Momentan wird nicht geprüft, ob auch das richtige Dateiformat hochgeladen worden ist.
  • Der Nutzer hat noch nicht die Möglichkeit mehrere Datein auf ein Mal hochzuladen.
• Warum ist US_305/US_306 On Going?
  • Wie schon im IST Zustand beschrieben werden die Anzahl der Frequezen schon berechnet. Der Nutzer kann jedoch noch nicht zwischen den einzelnen Frequzen wechseln.
• Warum ist US_404 ON Going?
  • Die Skalierung findet noch nicht dynamisch statt.

Um dem Nutzer die Möglichkeit zu bieten .step Datein in die Applikation hochzuladen und diese dann in .glb Datein für die AR Darstellung umzuwandeln, müssten wir eine der folgenden Alternativen wählen.

1. Wir implementieren einen vollständigen Converter, der (ähnlich wie für die .ffs Datein) die .step Datein in unser gewünschtes Format umwandelt.
2. Wir nutzen externe Bibliotheken, um den Umwandlungsprozess "auszulagern".

Nach Absprache mit Herrn Tobias Mann haben wir uns gegen beide dieser Alternativen entschieden. #1 Würde den Rahmen dieses Projektes komplett sprengen, besonders weil .step Datein unglaublich detailiert werden können. #2 Könnten aus Datenschutzgründen nicht funktionieren, da die Gefahr bestehen könnte, dass die Ersteller der Bibliothek die .step für ihren Nutzen abspeichern.

Eine Dritte, noch nicht genannte, Alternative ist das Nutzen eines Drittprogrammes, das lokal auf einem Rechner verwendet werden kann, um diese Umwandlung vorzunehmen. Wir empfehlen dabei das Progamm CAD Exchanger. Dieses wurde bereits verwendet, um die bereitgestellte Dummy-Antenne in das .glb Format umzuwandeln. Das Team und Herr Tobias Mann haben sich darauf geeignet es bei dieser Alternative zu belassen. Dadurch wird die US_304 obsolete.

Um die .ffs Datein, die mehrere Frequzen beinhalten, richtig zu interpretieren, müssen wir uns an die gegebenen Header der Datei orientieren., Uns ist jedoch aufgefallen, dass unterschiedlicher .ffs Datein auch unterschiedliche Headers besitzten. Hier ein Beispiel (Typo in #theta):

Header der Sample Größe in der ersten .ffs Datei:
// >> Total #phi samples, total #theta samples

Header der Sample Größe in der neusten .ffs Datei:
// >> Total #phi Sample, total #theata samples

Als Lösung für dieses Problem nutzen wir die Levenshtein Distance, um zu prüfen ob die Header ungefähr identisch sind und wenn ja wird dieser Typo ignoriert.

Bei der neusten .ffs Datei sind für eine einzelne Frequezn 65.000 Messwerte zu interpretieren. Das sorgt einerseits für A) eine relative (im Vergleich zu den anderen Prozessschritten) hoche Ladezeit der Sphären und andererseits für B) eine schwach Performance der AR Darstellung.
Als Lösungsvorschlag für Problem A schlagen wir vor, den Interpretationsprozesses (im Ladeprozess beinhaltet) direkt nach dem Import der .ffs Datei stattfinden zulassen. Die Informationen der Spähren (Koordinaten, Intensität) werden zusätzlich in der Datenbank abgespeichert und beim initialen Laden bzw. beim Wechseln der Frequezen von dort ausgelesen.
Das Problem B entsteht offensichtlich wegen der großen Maße an AR-Objekten, die momentan bei uns in der App dargestellt werden. Uns ist aufgefallen, dass viele Spähren sich überlappen (vermutlich auch wegen unserer Sklaierung) und diese eigentlich gar nicht angezeigt werden müssen, um die Feldstärke sauber darzustellen. Eventuell können wir die Performance durch das Nicht-Anzeigen von sicher überlappenden Spähren verbessern.

ALL-IN-ALL: Wir sind uns dieser Probleme bewusst und arbeiten daran sie zu lösen.

ActivityResultLauncher wird in einem Fragment aufgerufen. (ergebnis des Dateiwählers)
Unter Android 11 & 12 Kein Problem.
Unter Android 9 wird das Result nicht bis in das Fragment durchgereicht.
Lösung: Result in der Activity behandeln.

Dank unserer explorativen Tests ist uns aufgefallen, dass wir die Winkelgrade für Theta und Phi falsch interpretiert haben (Grad statt Radiate). Ähnlich wie in einer Matheklausur hat es das Ergebnis deutlich verschlechtert.
Außerdem ist das Ergebnis der programmatischen Berechnung von sin(0) nicht exakt 0. Ob dieser Fakt unser Ergebnis ebenfalls verschlechtert können wir momentan nicht sagen.

Bei den neuen .ffs Datein haben wir festgestellt, dass wir in eine JNI (Java Native Interface) Exeption laufen.
JNI ERROR (app bug): global reference table overflow (max=51200)global reference table dump:

Ab ca. 2500 Spheren wird dieser Fehler ausgelöst. Problem ist: 1 Frequenz hat ~ 65.000 Koordinaten Punkte
Lösung: (Vermutung) Nicht mehr 65.000 einzelne Objekte erzeugen, sondern 1 großes Objekt.

• Die Aufteilung der User Stories, und anderer Aufgaben hat sehr gut funktioniert
• Auch die Rollenverteilung passt gut und war hilfreich für die Produktivität

• Das Team war allgemein zeitlich ziemlich eingeschränkt (40% hatten eine Prüfung & 60% hatten lange Blockveranstaltungen)
• Die Akzeptanzkriterien waren mangelhaft ausgestaltet - Zu User Stories fehlen Akzeptanzkritieren oder sie sind nicht mehr auf dem neusten Stand der Erkenntnisse
• Es dauert ein wenig um den Code Anderer zu lesen - Kommentare wären hilfreich

• Wir müssen die Aufgaben besser verteilen, damit jeder ein gleichmäßiges Maß erfüllt (Dominik hatte sehr viel zu tun)
• Für den neuen Sprint geplanten Userstories und Akzeptanzkriterien sollen noch vor Sprint überarbeiten werden

• Meetings finden jetzt als Längere Teammeetings und viele spontane Meetings (ähnlich wie Standups) statt
• Es gab einen großen Change-Request Mid-Sprint von Tobias Mann: Dadurch wurde die Epic der Metadatenanzeige in mehrere Userstories aufgenommen, die viel Aufwand darstellen. Dies haben wir im 1. Sprint umgangen und adressieren es nur teilweise im 2. Sprint, da wir nicht genug Zeit für eine angemessene Planung hatten.
• Die Überarbeitung der Userstories und der Akzeptanzkritiern dauert sehr lange

• Im Jour Fixe auf das Wesentliche beschränken und die Redezeit besser planen -> Tassilo und Stefan
• Um die doppelte Pflege der Anforderungen zu vermeiden, wird die Anforderungsliste innerhalb der Wiki minimiert. Die Anforderungen werden auf das Issue-Board verlinkt und nur dort gepflegt. -> Stefan (Done)
• Definition of Ready wird überarbeitet -> Leo
• Es wird auf Kommentare im Code geachtet -> Jeder. In Spielregeln aufgenommen
• Es gibt eine klare Aufgabenverteilung durch Issues
• Überarbeitung der Spielregeln bzgl. Stand-Ups -> Stefan