Konvertieren Route in Track

[stoffel]

Das alte Leiden: faßt man zuviele Schritte zusammen, gibt es Anfänger, die damit nicht zurechtkommen. Tut man es doch, meckern die Fortgeschrittenen, weil es eben nicht immer Sinn macht.

Das hab' ich jetzt nicht verstanden. Bin ich Anfänger oder Fortgeschritten ?-) Warum kommt ein Anfänger nicht mit einer kombinierten Funktion zurecht?

Also ich behaupte mal, dass das beschriebene Verhalten (von Google Maps-API oder anderen) weder für die eine noch die andere Gruppe von Anwendern nachvollziehbar ist, oder? Und wenn die besagte Funktionalität nur im Kontext eines Tracks Sinn macht, und bei Routen ein nichtdeterministisches Verhalten aufweist, warum lässt man dann dem Anwender die Freiheit... sich über unerwartete Phänomene zu wundern???

[routeconverter]

Das hab' ich jetzt nicht verstanden. Bin ich Anfänger oder Fortgeschritten ?-)

Anfänger

Warum kommt ein Anfänger nicht mit einer kombinierten Funktion zurecht?

Anfänger kämen mit einer einfacheren Funktion besser zurecht, nicht jedoch mit vielen Funktionen, die ihnen die Wahlfreiheit lassen, die sie aber kombinieren müßten.

Also ich behaupte mal, dass das beschriebene Verhalten (von Google Maps-API oder anderen) weder für die eine noch die andere Gruppe von Anwendern nachvollziehbar ist, oder?

Da gibt es genügend Mails und Forenbeiträge, die zeigen, daß es für fortgeschrittene Nutzer nutzbar ist. Das gab eine richtige Protestwelle, als die Funktion in der 1.32 auf ein Tab gewandert war.

Und wenn die besagte Funktionalität nur im Kontext eines Tracks Sinn macht, und bei Routen ein nichtdeterministisches Verhalten aufweist, warum lässt man dann dem Anwender die Freiheit... sich über unerwartete Phänomene zu wundern???

Weil Tracks und Routen nur Konventionen für die Anzeige von GPS-Daten sind. Bis auf GPX und OziExplorer unterscheidet sie kein Format und sie sind selbst dort identisch repräsentiert.

In den mir zugesandten Dateien befindet sich alles: mal sind es Wegpunktlisten/POIs, mal Tracks, mal Routen - in demselben Dateiformat. Darum ist die Typ: Box so zentral. Siehe dazu auch folgenden Thread.

PS: Ich habe Deinen Punkt verstanden. Bevor wir weiterdiskutieren, laß mir etwas Zeit, um die Funktion prototypisch umzubauen, daß sie a) einfach für Anfänger wird und b) flexibel für meine Bedürfnisse.

[stoffel]

Weil Tracks und Routen nur Konventionen für die Anzeige von GPS-Daten sind. Bis auf GPX und OziExplorer unterscheidet sie kein Format und sie sind selbst dort identisch repräsentiert.

Muss mich jetzt doch nochmal kurz melden (keine Angst ;-). Habe jetzt nochmal etwas getestet, mit der modifizierten Version meiner Route und AUSGESCHALTETER Routenplanung für Fußgänger (Der Einfluss war mir auch nicht klar):

- Belasse ich vorher den Typ auf Route, erhalte ich bei jedem Aufruf von 'Positionen einfügen' ein anderes Ergebnis! Scheinbar werden jedes mal willkürlich unterschiedliche Segmente der Route nicht durch Positionen ergänzt. Kann man sehr gut an der Höhenlinie erkennen.

- Setze ich vorher Typ auf Track, erhalte ich bei jedem Aufruf das gewünschte Ergebnis: Alle Segmente werden ergänzt. Der Track entspricht nachher der Route.

Das widerspricht doch eigentlich der Sichtweise, dass Tracks und Routen nur Konventionen zur Anzeige sind, oder. In diesem Fall müsste das Ergebnis in beiden Fällen immer identisch sein.

[routeconverter]

Muss mich jetzt doch nochmal kurz melden (keine Angst ;-).

Vielen Dank fürs Testen und Berichten

Habe jetzt nochmal etwas getestet, mit der modifizierten Version meiner Route und AUSGESCHALTETER Routenplanung für Fußgänger (Der Einfluss war mir auch nicht klar):

- Belasse ich vorher den Typ auf Route, erhalte ich bei jedem Aufruf von 'Positionen einfügen' ein anderes Ergebnis!

Hier habe ich mit Deiner Rhodos1.txt normalerweise 1418 Positionen nach Alles markieren/Alle Wegpunkte. Etwa jedes 8. oder 10. Mal sind es weniger, man sieht es an Lücken im Höhenprofil.

Ich vermute, daß die Belastung durch das Neuzeichnen nach dem Einfügen einiger Positionen zu einer ungewünschten Wechselwirkung mit dem Einfügeprozeß führt. Denn beim Zeichnen von Routen werden die Google-Server angefragt (bei Tracks ist das nicht erforderlich) - es ist fast derselbe API-Call.

Dafür spricht, daß der Effekt bei mir nicht mehr zu sehen war, wenn ich das Zeitinterval, indem ich 2 Positionen an die Google-Server übergebe, von eine auf zwei Sekunden erhöht habe. Halbiere ich das Interval auf 500ms passiert es jedes 2. Mal...

Das widerspricht doch eigentlich der Sichtweise, dass Tracks und Routen nur Konventionen zur Anzeige sind, oder.

Nein.

In diesem Fall müsste das Ergebnis in beiden Fällen immer identisch sein.

Korrekt, das ist es auch, wenn man das Zeichnen ausstellt, während Positionen eingefügt werden.

[routeconverter]

Ich vermute, daß die Belastung durch das Neuzeichnen nach dem Einfügen einiger Positionen zu einer ungewünschten Wechselwirkung mit dem Einfügeprozeß führt. Denn beim Zeichnen von Routen werden die Google-Server angefragt (bei Tracks ist das nicht erforderlich) - es ist fast derselbe API-Call.

So, nach vielen, vielen Versuchen habe ich gerade eine neue Vorabversion hochgeladen, die vier Verbesserungen auf einmal versucht:

• die Einfügen/Löschen-Funktion im Positionen-Menü ist hoffentlich klarer benannt
  
• im Positionsliste-Menü gibt es eine Konvertiere R nach T... Funktion für unerfahrene Nutzer
  
• intern werkeln mehr Threads daran, die Wechselwirkung vom Routenzeichnen und Positionen einfügen zu reduzieren (bei mir trat in 10 von 10 Versuchen kein Fehler mehr auf)
  
• mehr Menüpunkte sind ausgegraut, wenn ihre Auswahl keine Sinn macht
  

Bitte testet besonders die Stabilität der Einfügen-Funktion und berichtet.

[stoffel]

Ich vermute, daß die Belastung durch das Neuzeichnen nach dem Einfügen einiger Positionen zu einer ungewünschten Wechselwirkung mit dem Einfügeprozeß führt. Denn beim Zeichnen von Routen werden die Google-Server angefragt (bei Tracks ist das nicht erforderlich) - es ist fast derselbe API-Call.

So, nach vielen, vielen Versuchen habe ich gerade eine neue Vorabversion hochgeladen, die vier Verbesserungen auf einmal versucht:

• die Einfügen/Löschen-Funktion im Positionen-Menü ist hoffentlich klarer benannt
  
• im Positionsliste-Menü gibt es eine Konvertiere R nach T... Funktion für unerfahrene Nutzer
  
• intern werkeln mehr Threads daran, die Wechselwirkung vom Routenzeichnen und Positionen einfügen zu reduzieren (bei mir trat in 10 von 10 Versuchen kein Fehler mehr auf)
  
• mehr Menüpunkte sind ausgegraut, wenn ihre Auswahl keine Sinn macht
  

Bitte testet besonders die Stabilität der Einfügen-Funktion und berichtet.

Ausgiebiger Test steht noch aus, hier nur noch eine dumme Frage: Warum wird überhaupt während der Punktermittlung neu gezeichnet. Ist es nicht möglich das Neuzeichnen zu unterbinden bis ALLE Punkte ermittelt sind? Das Refreschen von Tabelle UND Karte während der Berechnung irritiert enorm! Man weiß eigentlich nie wann der Vorgang eigentlich beendet ist.

[routeconverter]

Ausgiebiger Test steht noch aus, hier nur noch eine dumme Frage: Warum wird überhaupt während der Punktermittlung neu gezeichnet.

Model-View-Controller ist das Entwurfsmuster, das hinter eigentlich allen UI-Rahmenwerken liegt. Es entkoppelt die Daten (das Model) von den Sichten die Daten (die Views) und den Manipulationsmöglichkeiten (die Controller) auf die Daten. Immer, wenn das Model verändert wird, werden alle Views benachrichtigt, daß sie darauf reagieren. Das ist Stand der Technik. Nur bewege ich mich mit der Karte arg an der Grenze des technisch machbaren: das View (d.h. der Webbrowser mit der Karte) ist "teuer" zu zeichnen, hat große Latenzen, ist schnell instabil und schwer zu kontrollieren. Da steckt inzwischen eine ganze Menge Erfahrung, Knowhow und Tüfelkram drin, daß es trotzdem für die meisten Nutzer ausreichend gut läuft. Das ist ein komplexes Stück Software mit Multithreading, Locks, Signalen, Queues, Deferred Execution, Delayed Execution, Event Aggregation, einer Swing-SWT-Wrapper-Bibliothek, einer SWT-Browser-Komponente, dem Douglas-Peucker-Algorithmus...

Ist es nicht möglich das Neuzeichnen zu unterbinden bis ALLE Punkte ermittelt sind?

Etwas zum Hintergrund: Die Ermittlung der Punkte ist im Google API asynchron realisiert, d.h. man übergibt Punkte und eine Funktion, die aufgerufen wird, wenn die Punkte berechnet sind. Konkret heißt das, daß man niemals weiß, ob und wann man alle Punkte wirklich hat. Unterbinde ich das Neuzeichnen also, dann weiß ich nicht, wann ich das Neuzeichnen initiieren soll. Ich habe schon ein Zusammenfassen der Benachrichtigungen implementiert, so daß nicht auf jede Änderungsnachricht direkt reagiert wird, sondern es wird maximal alle 500ms neu gezeichnet. Dadurch mußte ich jedoch Ausnahmen einbauen, damit ein Verschieben von Punkten nach Benutzerinteraktionen noch die gewünschte Reaktion hat. Vielleicht kann ich da noch nachlegen.

Man weiß eigentlich nie wann der Vorgang eigentlich beendet ist.

Das ist m.E. der Kern des Problems: irgendetwas müßte dem Benutzer verraten, ob gerade noch etwas passiert und wie lange es noch dauert. Knifflig, wenn man nicht ermitteln kann, ob noch etwas passiert und wie lange das eventuell passierende noch andauert... ;-)