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

[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.