mstumpp / pse13ss13-app Goto Github PK

Erstelle eine Kapselung, die es ermöglicht, Kacheln bei Netzwerkverbindung vom Server zu holen.
Falls vorhanden sollen stattdessen Offline-Kacheln verwendet werden.

Issue zur Datei gantt/2013-06-18/gantt.pdf (4e0d2dc) im repo.
Wenn ihr Vorschläge zur Verbesserung habt, dann her damit.
Einfach kommentieren.

Verwandt mit #118.

Beim einfügen von zu vielen wegpunkten im routeview schieben sich die unteren buttons aus der view

Ladebildschirm der alle initialisiert

Beim Systemstart idCounter für Locations hochsetzen, sodass IDs nicht mehrfach vergeben werden.
Wert aus LocationDataIO bestimmen.

Beherrsche die METIS API (Graph-Partitionierung) und wende diese auf den OSM Graphen an.

Generelle Verbesserungen an den Menüs
Neue Grafiken
Neue Schriftart
Übersetzungen
User Interaktionen Testen
Alerts hinzufügen

Die MapView-Komponente implementieren.

Ziele:

• Anzeige von Bildern (Bildgröße = Bildschirmgröße abzgl. Leisten), die von außen geschickt werden (updateMapImage() und updateRouteOverlayImage())
• Entgegennehmen von MotionEvents und weiterleiten an Listener

Erweitere die bestehende Implementierung des Dijkstra's Algorithmus mit Arc-Flags.

Es wird benötigt:

• Komponente (z.B. Kommandozeilen-Tool) für Vorverarbeitungen auf dem OSM-Graphen; dies beinhaltet die Graph-Partitionierung mit METIS und die Berechnungen der arc-flags an den Kanten des OSM-Graphen
• Anpassung des Dijkstra's Algorithmus, so dass die arc-flags bei der Kurze-Wege-Berechnung berücksichtigt werden

Vermutlich verwandt mit #108.

wir brauchen dafür ein Template! Ein erster Anfang steht in Navi, passt aber noch nicht ganz

Gerade Verbindung zwischen Wegpunkten. Idealerweise in anderer Farbe, als berechnete Routen.
Vorbild: http://osrm.at/4u2

Implementiere die Routenkomponente.

Ziele:

• Interface RouteInfo
• Klasse Route, die RouteInfo implementiert

Anmerkung:

Hier werden viele der Datenstrukturen aus shared verwendet.
@themk: Kannst gerne auch mit den Datenstrukturen anfangen und anschließend die Routen.

Implementiere das im Paper "Efficient Implementation of Jogging Routes" beschriebene "Partial Shortest Path"-Verfahren.

Anfragen an den Server synchron absetzen.
Antwort des Servers wird per Callback erhalten

Ermögliche das Einlesen von *.osm.pbf-, sowie *.osm-Dateien als Java-Objekte.

Ziele:

• Einlesen der OSM-Datei
• Validitätsprüfung
• Schreiben der Graph-Datei (mithilfe von GraphDataIO)
• Schreiben der LocationData-Datei (mithilfe von LocationDataIO)

Implementiere die Utility-Klassen.

Ziele:

• CoordinateUtility für Koordinaten-Berechnungen (Umrechnung Display-/Geo-Coordinate, Distanz, Größe des Android-Display [vmtl. ohne Leisten])
• TileUtility für die Umrechnung der Tilekoordinaten (siehe http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames#Java)
• CoordinateNormalizer (ehemals Projection) für Projektion einer Koordinaten auf den Graphen
• TextToSpeechUtility nur, um eine Instanz der Klasse TextToSpeech von Android vorzuhalten

Muss noch als spezieller Fall behandelt werden.

Hat vermutlich mit der hauptsächlichen Verwendung von topLeft (aka upperLeft) zu tun.
Verwandt mit #106.

onbackpressed() in mapview implementieren, dass der "zurück-button" bestimmte dinge erfüllt

Vorausschauendes herunterladen von Kacheln.
Kacheln, die noch außerhalb, aber in der Nähe des dargestellten Bereichs sind, sowie aus den beiden "angrenzenden" Zoomleveln herunterladen, bevor diese überhaupt beim TileFetcher angefragt werden

Implementiere den klassischen Dijkstra's Algorithmus (Algorithmus und Datenstrukturen) und setze diesen zur Kurze-Wege Berechnung auf dem OSM Graphen ein.

Wikipedia-Informationen darstellen
Adressen anzeigen
Etc

Erstelle eine Struktur, die es ermöglicht, aus den eingelesenen OSM-Elementen (Nodes, Ways, Relationen) diejenigen eines bestimmten Typs herauszufiltern.

Implementiere die Komponente, die auf die Android-Sensoren zugreift.

Ziele:

• Interfaces PositionListener, SpeedListener, CompassListener existieren
• PositionManager, SpeedManager und CompassManager empfangen Werte von den Sensoren des Androiden und leiten diese an die jeweiligen Listener weiter

Vermutlich verwandt mit der "Lock Position"-Funktion (#125).

im Routenverwaltungsmenü
moveActiveWaypointInOrder Methode fertigstellen

Vorschlag:
Warum benennen wir die Branches nicht danach, was wir in Ihnen ändern (z.B. "android-map", "gui", "tiles", ...)? Der Vorteil läge darin, dass die Arbeit weniger nach Personen, sondern eher nach Aufgaben unterteilt wird.
Das würde meiner Meinung nach Teamarbeit fördern.

Dieses Verfahren wird so auch bei den Entwicklern von github.com praktiziert:
https://help.github.com/articles/what-is-a-good-git-workflow

Wer von euch befürwortet das? Einfach abhaken:

• @ProFreak
• @themk
• @MStumpp
• @TKey99
• @teiesti
• + natürlich meine Stimme (@floscher)

Entwickle ein Konzept für die Annotation der Kanten des OSM-Graphen mit einem oder mehreren "Badness"-Werten (im folgendem "Individual Egde Badness"-Werte genannt). (mehrere => ein "Individual Egde Badness"-Wert für jeden zu unterstützenden "OSM-Objekt-Typ").

Die Berechnung der "Individual Egde Badness"-Werte könnte analog zum Arc-Flags Verfahren im Rahmen eines Vorverarbeitungsschritts erfolgen. Dabei wird die Umgebung einer jeden Kante des OSM-Graphen nach dem Vorhandensein von "OSM-Objekt-Typen" untersucht und die Kante dann entsprechend annotiert.

Bei der Rundkurs-Routen Berechnung könnte dann, entsprechend der vom Benutzer angegebenen Wunsch OSM-Objekt-Typen, ein "Total Edge Badness"-Wert aus den (eventuell gewichteten) "Individual Egde Badness"-Werten berechnet werden.

Der "Total Edge Badness"-Wert dient als Grundlage für die Priorisierung der Candidate Rundkurs-Routen.