10.10.2016, 07:21 (This post was last modified: 10.10.2016, 08:12 by ThommyS.)
Hallo @.
Erstmal ein Hallo.
Ich habe dieses Programm beim stöbern entdeckt.
Für die Auswertung von längeren Routenaufzeichnungen sowie zum Füttern des Navis mit neuen Routen wird das wohl mein Lieblingswerkzeug :-)
Aber nun eine Frage zu der ich im Forum nach mehreren Tagen Suche nichts gefunden habe:
Bisher verwendete ich zur Darstellung einer gefahreren Route in GoogleEarth den GPSVisualizer.
Damit konnte ich kml-Dateien erzeugen die zu jedem Trackpoint auch folgende Darstellung ermöglichten:
Wie kann ich das mit dem RouteConverter erreichen?
Thommy
Nachtrag.
Ich habe noch einen kurzen Ausschnitt einer Route beigelegt.
Darin ist der oben gezeigte Trackpoint auch drin.
Sowie die KML, die mir der GPSVisualizer erstellt hat....
10.10.2016, 20:52 (This post was last modified: 10.10.2016, 20:52 by routeconverter.)
(10.10.2016, 07:21)ThommyS Wrote: Ich habe dieses Programm beim stöbern entdeckt.
Für die Auswertung von längeren Routenaufzeichnungen sowie zum Füttern des Navis mit neuen Routen wird das wohl mein Lieblingswerkzeug :-)
Das freut mich.
(10.10.2016, 07:21)ThommyS Wrote: Bisher verwendete ich zur Darstellung einer gefahreren Route in GoogleEarth den GPSVisualizer.
Damit konnte ich kml-Dateien erzeugen die zu jedem Trackpoint auch folgende Darstellung ermöglichten:
Was heisst ermöglichen? Ist das eine Option, die man anschalten kann?
Sehe ich das richtig, dass GPSVisualizer dann folgendes aus 1 Wegpunkt macht?
(10.10.2016, 07:21)ThommyS Wrote: Wie kann ich das mit dem RouteConverter erreichen?
Programmieren ;-)
(10.10.2016, 07:21)ThommyS Wrote: Ich habe noch einen kurzen Ausschnitt einer Route beigelegt.
Darin ist der oben gezeigte Trackpoint auch drin.
Sowie die KML, die mir der GPSVisualizer erstellt hat....
Das ist eine ungewöhnliche Art, KML zu strukturieren. RouteConverter macht daraus 759 Routen und 1 Wegpunktliste. Die Routen sind das <Placemark> mit dem <LineString> der 2 Positionen verbindet. Wenig inhaltstragend...
Das ist ganz schön weit weg von dem KML, das RouteConverter erzeugt.
(10.10.2016, 20:52)routeconverter Wrote: Das ist eine ungewöhnliche Art, KML zu strukturieren. RouteConverter macht daraus 759 Routen und 1 Wegpunktliste. Die Routen sind das <Placemark> mit dem <LineString> der 2 Positionen verbindet. Wenig inhaltstragend...
Das ist ganz schön weit weg von dem KML, das RouteConverter erzeugt.
Hallo routeconverter.
Danke für die Antworten.
Ich habe mal ein wenig in deiner KML 'rumgewühlt' und an der letzten Placemark von Hand editiert....
Kann das was ich bei deiner 'Placemark' eingefügt habe durch Routeconverter gefüllt werden?
sind diese Daten einfach aus dem .nmea zu extrahieren?
In der Hauptsache interessiert mich: Datum, Zeit, Geschwindigkeit. Der Rest is 'nice to have' :-)
kenntlich durch die geringere Einrückung....
Wenn ich das jedoch ändere, steigen mir alle Nutzer aufs Dach, die nur mal kurz etwas in einer KML-Datei ändern wollten und dann ihre <description> nicht so vorfinden, wie sie war, sondern transformiert.
(11.10.2016, 07:32)ThommyS Wrote: sind diese Daten einfach aus dem .nmea zu extrahieren?
Hallo Christian.
Wäre der Aufwand für folgendes vertretbar:
Bei den Optionen ein weiterer Reiter 'Trackpoint-Deskription' in dem die gewünschten Angaben einfach per 'Haken' ausgewählt werden...
Und als default den bisherigen Zustand?
(13.10.2016, 06:00)ThommyS Wrote: Wäre der Aufwand für folgendes vertretbar:
Bei den Optionen ein weiterer Reiter 'Trackpoint-Deskription' in dem die gewünschten Angaben einfach per 'Haken' ausgewählt werden...
Und als default den bisherigen Zustand?
sorry, wenn ich mich da in eure Diskussion einmische. Ich persönlich fände es irgendwo nicht gut, wenn man die andere Variante einfach mit einem Haken einschalten kann. Da kommt dann irgendwann ein Anderer, der dann einen anderen Aufbau oder Formatierung will. Evtl. soll es auch nur in einer anderen Sprache sein.
Was wäre, wenn man in den versteckten Optionen eine Option machen würde, bei der man die ganze Beschreibung vorgeben kann, wobei für die dynamischen Werte entsprechende Platzhalter definiert werden. Man kann sich dann das Ganze nach seinem Gusto zusammenbauen. Im RC würde dann dieser Text genommen, die Platzhalter ersetzt und ausgegeben. Für solche Ersetzungen gibts genug Beispiele, Libs und auch Java-Onboard-Lösungen, so dass ich den Aufwand als überschaubar ansehen würde.
(13.10.2016, 09:09)lundefugl Wrote: sorry, wenn ich mich da in eure Diskussion einmische. Ich persönlich fände es irgendwo nicht gut, wenn man die andere Variante einfach mit einem Haken einschalten kann. Da kommt dann irgendwann ein Anderer, der dann einen anderen Aufbau oder Formatierung will. Evtl. soll es auch nur in einer anderen Sprache sein.
Hallo Thomas,
ich bin Deiner Meinung - genau darum versuche ich Extra-Knöpfe und -Optionen zu vermeiden.
(13.10.2016, 09:09)lundefugl Wrote: Was wäre, wenn man in den versteckten Optionen eine Option machen würde, bei der man die ganze Beschreibung vorgeben kann, wobei für die dynamischen Werte entsprechende Platzhalter definiert werden. Man kann sich dann das Ganze nach seinem Gusto zusammenbauen. Im RC würde dann dieser Text genommen, die Platzhalter ersetzt und ausgegeben. Für solche Ersetzungen gibts genug Beispiele, Libs und auch Java-Onboard-Lösungen, so dass ich den Aufwand als überschaubar ansehen würde.
Könnte man machen.
Thommy schreibt
Quote:Je flexibler eine solche Lösung, desto besser.
Sie muss halt auch für 'Nichtprogrammierer' verwendbar bleiben.
und damit hat man dann ein Problem. Alle Programmierer können ja den Quelltext nehmen und sich ihre Spezialanforderungen einbauen. Und das passiert auch.
(13.10.2016, 09:09)lundefugl Wrote: ..... Evtl. soll es auch nur in einer anderen Sprache sein.
Das mit der Überschriftensprache und den angebotenen Feldern lässt sich einfach eingrenzen:
wenn das auf diese Felder beschränkt ist:
die zum Zeitpunkt der kml-Generierung aktiviert wurden, dann brauche ich wieder nur exakt 1 Optionsfeld: 'Erweiterte Trackpointbeschreibung in KML einfügen'
und der Fall hätte sich.
Quote:Je flexibler eine solche Lösung, desto besser.
Sie muss halt auch für 'Nichtprogrammierer' verwendbar bleiben.
und damit hat man dann ein Problem. Alle Programmierer können ja den Quelltext nehmen und sich ihre Spezialanforderungen einbauen. Und das passiert auch.
das ist richtig, allerdings bin ich auch als Programmierer kein Freund von irgendwelchen eigenen Versionen.
Die muss man dann selbst pflegen. D.h. immer wieder deinen Master da rein mergen. Und wenn du dann was umstellst, dann muss man seine eigene Anpassung wieder selbst neu entwickeln.
Ich glaube auch nicht, dass das etwas mit "Nichtprogrammierer" zu tun hat. Jeder, der halbwegs mit einem Computer umgehen kann, sollte es können. Das Problem ist eher, dass die versteckten Optionen für einen Außenstehenden eher unbekannt sind. D.h. es ist eher eine Frage der Dokumentation, wie das aufgebaut sein muss und wo man es eintragen muss.
Allerdings spräche dann auch nichts dagegen, wenn ein Anderer dann einfach hier im Forum fragt, wie der Aufbau sein muss, wenn er ein Beispiel hier postet. Dann kann man ihm das erklären und ggf. den einzutragenden Text posten.
Mit den Linienoptionen (Farbe, Stärke) wird ja hier auch ab und an gefragt, wie der Farbcode korrekt aufgebaut sein muss.