Ja, das weiß ich. Das ist die DEM-info aus den Karten, aber nicht aus den Routen.
Wenn ich einen Track mit Höheninformationen nach eine Route konvertiere wird die Höheninformation mitgenommen aber nicht als Profil gezeigt. Die Track zeigt das Profil aber schon.
Ok, jetzt habe ich das Problem Verstanden,
Sorry
Grüße, Hein
Jetzt gibt es WinGDB3 Version 3.55 beta.6
BaseCamp Routen ließen WinGDB3 manchmal crashen, weil Garmin das GDB-Format etwas anders gebrauchte als mir bekannt war. Es bleibt Rätsel lösen mit diesem nicht dokumentierter Format. Mit Dank an Dieter dass er das Problem gemeldet hat. Ist gelöst.
Doch auch wieder einen neuen Funktion. WinGDB3 kann jetzt aus einem NMEA log einen Track konstruieren. Dafür werden die $GPRMS Sätze gebraucht, eventuell erweitert mit Höheninformation aus $GPGGA Sätze. Ich gebrauche das für meinem GPS Data Logger und das Format scheint allgemein zu sein.
Nach WinGDB3 Version 3.55 Beta.6 gibt es jetzt Beta.7
Darin ist Support für TomTom itn-Dateien.
Man kann dieser Dateien konvertieren in Tracks oder Routen in MapSource.
Die itn Routepunkte werden behalten als Wegpunkte (Tracks) oder als Zwischenziele (Routen). Die Routen können dann gleich wieder in MapSource neu berechnet werden.
Viel Spaß.
Hallo Edward,
ist es grundsätzlich möglich, dass man mittels einer Funktion in WinGDB bei Tracks alle 10 Meter einen Trackpunkt automatisch hinzufügen könnte?
Gruß Oeschi
Grundsätzlich werde das natürlich möglich sein, aber warum?
Hinzugefügte Punkten liegen dann in eine rechte Linie zwischen 2 andere Punkte.
WinGDB3 Version 3.55 Final ist jetzt verfügbar!!!
Nach Wochen von basteln an diese Version und nach 9 Beta's ist endlich Version 3.55 erwachsen geworden. Das Anzahl hinzugefügte Funktionen ist ziemlich groß.
- Konvertieren mit copy/cut/paste über das neuen Zwischenablage Menü
- BaseCamp Unterstützung
- Support von NMEA log Dateien
- Support von TomTom ITN Dateien
- Verbesserte Aufteil- und Filter Funktion
- Viel interne Verbesserungen
Vielleicht ein gutes Moment um die letzte up-to-date Version zu downloaden.
Viel Vergnügen mit WinGDB3 Version 3.55
_________________
Nochmals vielen Dank für dieses tolle Programm.
Das Problem bei den SRTM-Daten ist schlichtweg, dass sie sofern das 3" Raster (das gilt z.B. für das südliche Oberbayern)) nur zur Verfügung steht, einfach ungeheuer ungenaue Werte liefert. Deshalb wäre es sehr gut, wenn Autorouting Dateien auf eventuell vorhandene Kartenwerte zurückgreifen könnten.
also ich habe das jetzt nochmals mit den höhendaten in 3.55 ausprobiert.
In einer Route, die mit einer Karte mit Höhendaten geplant wird, ist das Höhen-Profil sichtbar. Gleiches gilt für einen Track, den man in dieser Karte zeichnet.
Wenn ich nun aber diese Routing Datei in einen Track konvertiere und diesen Track dann in Mapsource einfüge, so wwerden nur ein paar Höhenwerte angezeigt. Woran liegt das?
Grüße
Michael
Hallo,
WinGDB konvertiert nur die Höhenwerte, die es in der Route findet.
Das trifft für den Startpunkt, den Endpunkt und für die während der Routenerstellung geklickten Zwischenziele zu. Dazwischen werden die Höhenwerte nicht interpoliert.
Viele Grüße
Dieter
Michael, kannst du mir bitte die Route schicken?
Alles anzeigenHallo,
WinGDB konvertiert nur die Höhenwerte, die es in der Route findet.
Das trifft für den Startpunkt, den Endpunkt und für die während der Routenerstellung geklickten Zwischenziele zu. Dazwischen werden die Höhenwerte nicht interpoliert.
Viele Grüße
Dieter
Wenn ich eine Routing- Datei als GPX abspeichere und dann z.B. nach MagicMaps importiere, so ordnet MM dieser GPX Datei das korrekte Profil der Kartenhöhenwerte zu, anschließend kann ich diese mit Höhenwerten versehene Datei als TXT Strecke mit korrektem Höhenprofil an den Edge geben.
Wenn ich aber die gleiche Routing Datei per WINGDB3 als Track in MSource einfüge, so hat dieser Track eben halt nur die von dir erwähnten 3 Punkte.
Deshalb: was läuft da unterschiedlich in Bezug zwischen MagicMaps und Mapsource?
Wie gesagt: wenn das so ginge wie bei MagicMaps, so könnte man europaweit auf die wesentlich genaueren DEM-Werte der Garminkarten zurückgreifen. DIese Werte sind IMHO genauer als die SRTM Daten (erst recht bei den 3" Werten).
Grüße
Hallo,
vorab - mir ist das Verhalten auch schon aufgefallen....
Ich kenne in diesem Zusammenhang jedoch nur das Verhalten von MapSource, bzw. BaseCamp.
Das Verhalten dürfte damit begründet sein, dass Mapsource entlang der Route neben den Routenpunkten auch alle dazwischen liegenden Höhenwerte generiert und im Höhenprofil anzeigt (eine geeignete Karte vorausgesetzt).
Diese Höhenwerte sind jedoch nicht Bestandteil der Routendatei (und offensichtlich auch nicht Bestandteil der Zwischenablage); und gehen damit bei der WinGDB-Konvertierung "verloren".
Viele Grüße
Dieter
OK ja wegen der Routing-GPX. Aber warum nochmal ordnet dann MS dem eingelesenen konvertierten Track keine Höhen zu, was Magicmaps ja dann bewerkstelligen kann?
hallo riesenflitzer,
normalerweise ist ein Track die Aufzeichnung einer mit einem GPS-Gerät zurückgelegten Strecke. Du würdest dich schön bedanken wenn beim Einlesen deines Tracks alle Höhen mit denen eines DEMs überschrieben würden.
Ordentliche GPS-Software kann beides - aufgezeichnete Höhen und DEM-Höhen nutzen.
Grüsse - Anton
hallo riesenflitzer,
normalerweise ist ein Track die Aufzeichnung einer mit einem GPS-Gerät zurückgelegten Strecke. Du würdest dich schön bedanken wenn beim Einlesen deines Tracks alle Höhen mit denen eines DEMs überschrieben würden.
Ordentliche GPS-Software kann beides - aufgezeichnete Höhen und DEM-Höhen nutzen.
Grüsse - Anton
jepp! aber in diesem Fall geht es ja nicht darum, bereits gefahrene Tracks einzulesen, sondern möglichst genaue Planungsstrecken zu erzeugen.
Kennst du (Free)Software, die das kann? Und das mit Garmin Karten?
Hallo Edward,
mir ist aufgefallen, dass bei Option 12, nur ein Luftlinientrack erzeugt wird. Entspricht das einem gewünschten Verhalten, oder habe ich was übersehen?
Grüße
Michael
Das ist richtig so.
Mit der Option 12 werden weniger Trackpunkte erzeugt als mit der Option 11. Wenn der Track möglichst genau so aussehen soll, wie die Route, muss die Option 11 verwendet werden. Damit werden zusätzliche sogenannte Routenpunkte erzeugt, die in einer Route als genau definierte Punkte gar nicht vorhanden sind.
Die Originalroute enthält nur Zwischenziele und Richtungspunkte (das sind die Punkte, die du mit der Option 12 siehst). Damit kann ein Navi mit Autoroutingfunktion schon arbeiten. Für eine bildhafte Spur ist das aber nur sehr grob und muss daher mit zusätzlichen Punkten ergänzt werden, damit sich ein Bild wie bei einer Route mit Autoroutingfunktion ergibt. Das macht dann die Option 11.
Das ist richtig so.
Mit der Option 12 werden weniger Trackpunkte erzeugt als mit der Option 11. Wenn der Track möglichst genau so aussehen soll, wie die Route, muss die Option 11 verwendet werden. Damit werden zusätzliche sogenannte Routenpunkte erzeugt, die in einer Route als genau definierte Punkte gar nicht vorhanden sind.
Die Originalroute enthält nur Zwischenziele und Richtungspunkte (das sind die Punkte, die du mit der Option 12 siehst). Damit kann ein Navi mit Autoroutingfunktion schon arbeiten. Für eine bildhafte Spur ist das aber nur sehr grob und muss daher mit zusätzlichen Punkten ergänzt werden, damit sich ein Bild wie bei einer Route mit Autoroutingfunktion ergibt. Das macht dann die Option 11.
stimmt! auch in 3.5. Dann enthält der Track aber keine Nav-Hinweise. Die Frage besteht für mich, ob man eine eierlegende Wollmilchsau, also eine TCX mit Nav-Hinweisen, machen kann. Ich meine mich zu erinnern, dass ich da mal irgendwas hinbekommen habe
Danke Chris das du mich helfen willst. Ich verstehe auch nicht alles so gut. Was ist eigentlich eine eierlegende Wollmilchsau 