Schwerpunkte für die zukünftige RouteConverter-Mapsforge-Integration

[routeconverter]

Für die zukünftige RouteConverter-Mapsforge-Integration ließen sich unterschiedliche Schwerpunkte setzen:

1. Ein RouteConverter, das eine identische Kartendarstellung sowie dieselbe Such- und Routingfunktionalität wie bei Android-Mapsforge-Apps auf Smartphones bietet. Es schließt eine essentielle Lücke für viele Android-Mapsforge-Kartennutzer weil es den einfachen Austausch von Tracks und Routen bietet.
   
2. Ein RouteConverter, der ohne Netzwerkverbindung für das Planen von Routen auskommt und auf Note- und Netbooks läuft, ermöglicht es Nutzern von Navigationsgeräten nicht nur zu Hause, sondern während längerer Touren auch unterwegs zu planen.
   
3. Ein RouteConverter, der Google-Dienste nicht mehr benötigt, stärkt die offene Alternativen
   

Je nach Schwerpunkt haben Nutzer an RouteConverter andere Erwartungen.

Annahmen für den Schwerpunkt 1.:

• Existierende Maps und Themes müssen in RouteConverter eingebunden werden.
  
• Existierende Routen und Tracks sollten in RouteConverter leicht verfügbar sein (z.B. direkt im Durchstöbern-Tab).
  
• Das Aufsuchen der Websites und der Download von Maps und Themes wird vom Nutzer manuell erledigt, der die heruntergeladenen Dateien auch entpackt und passend im Dateisystem verteilt.
  
• Der Betrieb ohne Netzwerkverbindung ist nur für die Android-Mapsforge-Apps essentiell.
  

Annahmen für den Schwerpunkt 2.:

• Existierende Routen und Tracks liegen bereits vor und können im Durchstöbern-Tab in RouteConverter leicht zugegriffen werden.
  
• RouteConverter bietet Maps, Themes, Routinginformationen, Höheninformationen (idealerweise: Reverse Geocoding) zum Download für den Betrieb ohne Netzwerkverbindung an.
  
• Der Ort und die Strukturierung der heruntergeladenen Daten erledigt RouteConverter.
  
• Vor dem Kappen der Netzwerkverbindung müssen alle Daten heruntergeladen sein.
  
• Der Betrieb ohne Netzwerkverbindung ist für RouteConverter essentiell.
  
• Die Funktionalität, die die Google Maps API basierte Variante bot, muß wieder erreicht werden.
  

Annahmen für den Schwerpunkt 3.:

• Existierende Routen und Tracks liegen bereits vor und können im Durchstöbern-Tab in RouteConverter leicht zugegriffen werden.
  
• RouteConverter bietet Maps, Themes, Routinginformationen, Höheninformationen (idealerweise: Reverse Geocoding) zum Download für den Betrieb ohne Netzwerkverbindung an.
  
• Der Ort und die Strukturierung der heruntergeladenen Daten erledigt RouteConverter.
  
• Die Funktionalität, die die Google Maps API basierte Variante bot, muß wieder erreicht werden.
  

Bitte schreibt, ob ihr dieselben Schwerpunkte und Annahmen seht und nehmt an der Abstimmung teil, welcher Schwerpunkt für Euch am relevantesten wäre.

[toc-rox]

Essentiell wäre für mich der Punkt "identische Karten und Funktionen" sowohl im Android-Device als auch im RouteConverter. Bei den Funktionen sehe ich die (Online-)Suche und das (Online-)Routing. Hierbei sollten OSM-basierte Dienste zum Einsatz kommen, zumal das Google-Routing-API m.W. ohnehin nur mir Googlekarten genutzt werden darf. Auch wichtig ist der Austausch von Routen und Tracks. Potentielle Problemfelder wie die Bereitstellung von Karten, Themes und Tracks sollten außerhalb des RouteConverters implementiert werden. Z.B. in Form eines RouteConverterHelpers. Hierdurch bleibt die Kernanwendung konsistent und schlank, und die Starthürde niedrig.

Gruß Klaus

[bianchifan]

Für die zukünftige RouteConverter-Mapsforge-Integration ließen sich unterschiedliche Schwerpunkte setzen:

1. Ein RouteConverter, das eine identische Kartendarstellung sowie dieselbe Such- und Routingfunktionalität wie bei Android-Mapsforge-Apps auf Smartphones bietet. Es schließt eine essentielle Lücke für viele Android-Mapsforge-Kartennutzer weil es den einfachen Austausch von Tracks und Routen bietet.
   
2. Ein RouteConverter, der ohne Netzwerkverbindung für das Planen von Routen auskommt und auf Note- und Netbooks läuft, ermöglicht es Nutzern von Navigationsgeräten nicht nur zu Hause, sondern während längerer Touren auch unterwegs zu planen.
   
3. Ein RouteConverter, der Google-Dienste nicht mehr benötigt, stärkt die offene Alternativen
   

Ehrlich gesagt, verstehe ich die Intention Deiner Frage nicht so ganz.

Unter der Voraussetzung, dass eine Mapsforge Integration damit also beschlossen zu sein und aller Voraussicht nach wohl oder übel auf dem mf-Zweig 0.4.0 aufbauen wird, sind die Punkte 2 +3 doch obligatorisch:
mapsforge ist OFFLINE und 0.4.0 heißt plattformunabhängig ohne google API.
Bleibt Punkt 1, identische Kartendarstellung, was verstehst Du darunter?
Ich kenne zwei Programme, die bei identischen Thema eine fast identische Kartendarstellung bieten: C:geo und Oruxmaps, beide bauen auf der 0.3.0 "Produktionsversion" von mf auf. Locus und ACB (Cachebox) stellen die Karten sichbar anders dar, bei Locus ist die Linienstärke anders ausgeprägt, Farbe und Font könne ebenfalls leicht differieren. Und bei ACB siehst Du...nix! Der Locusentwickler nimmt nach anfänglicher Skepsis das mf 0.3.0. nur als Basis und hat es in vielen Punkten nach seinen individuellen Vorstellungen angepasst, der ACB Entwickler nimmt wie Du den 0.4er Zweig mit dem Resultat, dass nix läuft außer interenen Themen, alles andere muss angepasst werden

Fazit: Es gibt nur die Darstellung, die man gewohnt ist. Wenn ein Anwender von Locus kommt und dessen internen bzw. externen Themen, dann wird er sich im RC momentan nicht wiederfinden können.
Kommt er von Oruxmaps, wird er u.U. auch verzweifeln, da der Anpassungsaufwand teilweise recht hoch ist (Toleranz ggü. nicht unterstützten Attributen).
Kommt er von OSMAND, wird er sich ziemlich umgewöhnen müssen, da OSMAND ggü. mf ein deutlich angenehmeres Zoomverhalten zeigt und auch die Beschriftung unterschiedlich und oftmals stimmiger gelöst ist.

Meine Frage ist eine andere: Warum RC?
GPX, KML (KMZ) sollte heutzutage jedes Geo-Programm beherrschen und wird es auch, proprietäre Formate gängiger Outdoorgeräte (Garmin & Co.) lassen sich bei vielen Onlineportale konvertieren (z.B. GPSies) oder unter ZUhilfenahme der zugehäörigen PC Software aber als solche abspeichern bzw. exportieren.
Bezogen auf den namensgebenden Punkt Routen konvertieren ist RC nur ein Programm unter vielen. Um hier zukünftig wahrgenommen zu werden, müsste es in der lage Lage sein, so ziemlich jedes erdenkliche und abstruseste Format lesen und möglichst auch ausgeben zu können.

Bezogen auf den Punkt mf Integration böten sich aber zwei Bereiche an, die noch nicht abgegrast erscheinen: (mf spezifisch) Themenentwicklung und Routenplanung.
Aufgrund seier hohen Darstellungsgeschwindigkeit bietet sich RC dafür geradezu an, jedoch sollte dann ein möglichst breites Spektrum realisiert werden, eine Erweiterung der rudimentären 0.4er Optionen ist dazu obligatorisch.

Zur Routenplanung habe ich bislang MagicMaps eingesetzt, kein anderes Programm hat diesen Planungskomfort, wenn auch Kosten mitunter nicht unerheblicher Abweichungen bei der Georeferenzierung, sind halt alte Topokarten.
Neue Route: Klick, Klick, Klick,... jeder Klick ein neuer Wegpunkt.
Bestehende Route abändern:
Vorauswahl, ob neuen Punkt am Amfang oder Ende einfügen, oder zwischen zwei bestehenden, dann Klick, KLick....
Oder bestehenden Punkt anfassen und verschieben.

Letztes WE hatte ich ein wenig mit der Linuxversion gespielt, sehr beeindruckt hat mich folgendes Scenario:
ABzug einer OSM-Relation mittels JOSM, Laden des Tracks in RC: Ein völlig undurchsichtiges Polygon, alle Teilstückstücke unterschiedlich geordnet und gerichtet, und nu? Track in Route konvertieren und voila..ein einzige zusammenhängende Route mit eindeutiger Richtung wird präsentiert. Als gpx abgespeichert lässt sich das gemüse in Orux & Co. laden und auf einmal findet man Wanderwege auch da, wo die Natur oder deren helfende Hände die Auszeichnung vernichtet haben. Problem waren nicht zusammenhängende tracks, hier half aber die zwischenzeitliche Speicherung als Wegpunktliste.

Bei der Routenerstellung sehe ich noch Luft, für einen neuen Wegpunkt waren min. zwei Klicks notwendig.

[toc-rox]

...Ehrlich gesagt, verstehe ich die Intention Deiner Frage nicht so ganz. ...

Ehrlich gesagt, verstehe ich die Intension deiner Antwort(en) nicht. Was willst du damit sagen?

Gruß Klaus

PS: Einige deiner Ausführungen sind übrigens sachlich falsch.

[womisa]

...Ehrlich gesagt, verstehe ich die Intention Deiner Frage nicht so ganz. ...

Ehrlich gesagt, verstehe ich die Intension deiner Antwort(en) nicht. Was willst du damit sagen?

Gruß Klaus

PS: Einige deiner Ausführungen sind übrigens sachlich falsch.

+++++1

wie bei früheren Posts von mir bemängelt auch. Behhauptungen die einfach falsch sind.
Abschließender Kommentar meinerseits an "bianchifan" üblege deine Antworten und behaupte nur Sachen die du sicher weißt.....
.... überhaupt über Fremdprodukte deren Mächtigkeit du nicht abschätzen kannts...

Wie schon früher:

!!!!Vorsicht mit deinen Äusserungen"... man könte die Ernst nehmen....

[routeconverter]

Ehrlich gesagt, verstehe ich die Intention Deiner Frage nicht so ganz.

Ich überlege, wo ich Schwerpunkte setze. Und ob ich vielleicht nur noch eine RouteConverter-Version habe, die nur Offline-mapsforge-Karten unterstützt - dann könnte ich viele, viele leidige Browser-Probleme loswerden. Oder ich mache für die RouteConverter-Mapsforge-Integration ein neues Programm, dessen Name besser kommuniziert, was es macht. Andererseits gibt es hunderttausende RouteConverter-Nutzer, einen bekannten Namen, viele Unterstützer... das wirft man doch nicht einfach weg. Zwei Versionen mit auseinanderdriftendem Funktionsumfang längerfristig zu pflegen ist auch keine Option, da wird die wenige Zeit, die ich für RouteConverter aufbringe, auch noch halbiert und auf zwei Versionen verteilt bzw. im Moment mache ich gar nichts für nächste 2.11 Release. Das ist auch nicht optimal.

Fazit: Es gibt nur die Darstellung, die man gewohnt ist. Wenn ein Anwender von Locus kommt und dessen internen bzw. externen Themen, dann wird er sich im RC momentan nicht wiederfinden können.
Kommt er von Oruxmaps, wird er u.U. auch verzweifeln, da der Anpassungsaufwand teilweise recht hoch ist (Toleranz ggü. nicht unterstützten Attributen).
Kommt er von OSMAND, wird er sich ziemlich umgewöhnen müssen, da OSMAND ggü. mf ein deutlich angenehmeres Zoomverhalten zeigt und auch die Beschriftung unterschiedlich und oftmals stimmiger gelöst ist.

Das heißt doch ganz platt, daß die Nutzer dieser Programme sich eh umstellen müßten? Aus Kartenanbietersicht hatte toc-rox geschrieben:

Sollte die Integration gelingen, so wird eine essentielle Lücke für viele Android-Mapsforge-Kartennutzer geschlossen. Typischerweise wollen die Nutzer auf dem PC (Linux, Mac, Windows) die gleichen Karten, und wichtig, mit den gleichen (Basis-)Funktionen wie auf dem Smartphone haben ... also:

- identische Kartendarstellung
- gleiche (Online-)Suchfunktionen
- gleiche (Online-)Routingfunktionen
- einfacher Austausch von Tracks und Routen

Meine Frage ist eine andere: Warum RC?

Richtig.

Bezogen auf den namensgebenden Punkt Routen konvertieren ist RC nur ein Programm unter vielen. Um hier zukünftig wahrgenommen zu werden, müsste es in der lage Lage sein, so ziemlich jedes erdenkliche und abstruseste Format lesen und möglichst auch ausgeben zu können.

Die Liste der Formate ist ziemlich lang und allerlei abstruse Formate sind auch unter den über 75 unterstützen Formaten dabei. Tyre, ITNConverter oder GPSies bieten m.W. nicht so viel. GPSBabel hat noch mehr abstruse Formate dabei, dafür schreckt die UI viele ab und eine Karte gibt es auch nicht.

Bezogen auf den Punkt mf Integration böten sich aber zwei Bereiche an, die noch nicht abgegrast erscheinen: (mf spezifisch) Themenentwicklung und Routenplanung.

Bei Routenplanung scheint Google Maps in den Augen vieler Nutzer das Werkzeug der Wahl zu sein.

[routeconverter]

PS: Einige deiner Ausführungen sind übrigens sachlich falsch.

+++++1

wie bei früheren Posts von mir bemängelt auch. Behhauptungen die einfach falsch sind.
Abschließender Kommentar meinerseits an "bianchifan" üblege deine Antworten und behaupte nur Sachen die du sicher weißt.....
.... überhaupt über Fremdprodukte deren Mächtigkeit du nicht abschätzen kannts...

Wie schon früher:

!!!!Vorsicht mit deinen Äusserungen"... man könte die Ernst nehmen....

Ich bin ziemlich irritiert ob des Tones dieser Äußerungen. Habe ich da irgendeinen Konflikt verpaßt?

Ich kenne mich im Android-mapsforge-Bereich nicht aus und kann die Korrektheit der Aussagen schwer einstufen. Von daher bin ich auf die Hilfe von Euch da draußen angewiesen und es ist wenig hilfreich, wenn ihr Euch solche Sätze um die Ohren haut. Da fehlt Respekt und ganz viele Belege für den eigenen Standpunkt, so daß sich der Leser ein Bild machen kann, welcher Argumentation er nun folgt.

@bianchifan's Post habe ich gelesen. Von @toc-rox habe ich die grundsätzlichen Anmerkungen dankbar aufgenommen. Wo seht ihr da Differenzen?

[toc-rox]

Ich überlege, wo ich Schwerpunkte setze. Und ob ich vielleicht nur noch eine RouteConverter-Version habe, die nur Offline-mapsforge-Karten unterstützt - dann könnte ich viele, viele leidige Browser-Probleme loswerden. Oder ich mache für die RouteConverter-Mapsforge-Integration ein neues Programm, dessen Name besser kommuniziert, was es macht. Andererseits gibt es hunderttausende RouteConverter-Nutzer, einen bekannten Namen, viele Unterstützer... das wirft man doch nicht einfach weg. Zwei Versionen mit auseinanderdriftendem Funktionsumfang längerfristig zu pflegen ist auch keine Option, da wird die wenige Zeit, die ich für RouteConverter aufbringe, auch noch halbiert und auf zwei Versionen verteilt bzw. im Moment mache ich gar nichts für nächste 2.11 Release. Das ist auch nicht optimal.

Im Grunde ist dies die Beschreibung eines "klassischen" Dilemmas. Konsequent wäre m.E. die Erstellung eines neuen Programmes. Das schafft Freiräume ohne das Erreichte zu tangieren, erlaubt es andere oder neue Schwerpunkte zu setzen ... löst aber keinesfalls das Dilemma auf.

Gruß Klaus

[routeconverter]

Konsequent wäre m.E. die Erstellung eines neuen Programmes. Das schafft Freiräume ohne das Erreichte zu tangieren, erlaubt es andere oder neue Schwerpunkte zu setzen ... löst aber keinesfalls das Dilemma auf.

Dann verlöre ich nach außen hin die "Marke" RouteConverter mit allem, was daran hängt - und innen die bewährte Codebasis. Auch nicht schlau

[toc-rox]

Vermutlich habe ich mich da mißverständlich ausgedrückt. Mit "neuen" Programm meinte ich ein zusätzliches Programm. Den jetzigen RouteConverter würdest du nicht "anpacken" ... was aber mittelfristig zum Problem der Pflege zweier Programme führt.

Gruß Klaus