Beiträge von weoli

Hallo Popej,

ich habe für mich privat schon einen Teil der Oberfläche übersetzt. Nur habe ich das dann wieder eingestellt, da ich dabei das Problem hatte, das übrigens auch auf des Screenshots im spanischen Blog erkennbar ist. Einzelne Texte passen leider nicht auf die Buttons oder in die Dialogfelder. Deutsch braucht immer etwas mehr Platz als Englisch (und Polnsich? sprech ich leider nicht). Kann man daran etwas machen?

Grüße

weoli

Hallo papaluna,

nachdem ich eben im Yahoo Forum Stans Ankündigung einer GUI für MapRoute gesehen habe, habe ich mal die cGPSmapper Seite besucht und festgestellt, dass es zusätzlich auch eine neue Version 097d gibt. In der zugehörigen Changelist zur 097d schreibt Stan dann eine Menge zu den Änderungen an MapRoute und erwähnt dabei auch das Navteq Format. Ein Blick auf die Navteq Seite lässt dann die Vermutung aufkommen, dass diese CarPool Lanes (in Amerika heißen die scheinbar HOV lane) tatsächlich in den Navteq Daten enthalten sind und nicht in den Karten (Linientyp) oder sonstigen Routingdaten, die man in GPSMapEdit vergeben kann. Und bei Navteq gibt es dann auch ein RDF Format (Relational Database Format). Vielleicht meint mike_hd das mit TRF.

Das basiert ja dann wohl alles auf einer Lösung, bei der die Grafiken (Polylinien, Polygone, ...) und ihre Attribute getrennt vorgehalten werden. Das Anhängen der Attribute direkt an eine Linie ist ja aus meiner Sicht sowieso Wahnsinn und viel zu mühsam. Lieber eine eindeutige ID für die Linie und dann die Attribute in einer Datenbank pflegen. Aber das ist ein anderes Thema.

Auf den Seiten von Navteq http://developer.navteq.com finden sich nach Anmeldung im Developerbereich jede Menge interessante Informationen zum Erstellen von routingfähigen Navteq Karten (eine wahre Fundgrube mit jeder Menge Background Infos, allein die drei Referenzen zum RDF, GDF und NAVSTREETS Fromat sind fast 3800 Seiten). Das sind Unterlagen, da kann man Wochen wenn nicht gar Monate lesen

In der NAVSTREETS Referenz findet sich übrigens Beschreibungen zu den Fahrgemeinschaftsspuren.

Ich denke daher auch, dass die nötigen Informationen (Attribut Fahrgemeinschaftsspur wäre ja noch denkbar, aber die Zeiten und ggf. sogar noch getrennt nach Datum, …???) nicht direkt an der Polylinie mit abgespeichert werden können, sondern das solche Attribute woanders hergeholt werden.

Noch eine Frage zu Deiner Ausgangsfrage: "Warum sollte sich eigentlich deiner Ansicht nach der Linientyp einer Fahrgemeinschaftsspur von einer normalen Autobahnspur unterscheiden. Auf einer Karte sehen die doch eigentlich beide gleich aus, oder? Oftmals sind das doch Spuren, die nur zu bestimmten Zeiten für den normalen Verkehr gesperrt sind.“

Und noch etwas ist mir in den Navteq Referenzen aufgefallen. Das Wort bicycle insgesamt nur 3 mal auf 3800 Seiten. Immerhin gibt es die Fußgänger und sogar eine eigenen beschreibung zur Erstellung von Karten für Fußgänger.

Grüße

weoli

PS ist es dir eigentlich gelungen ein Routing über „unbefestigte Wege“ eindeutig auszuschließen? Ich habe bei meinen Versuchen damit bisher keinen Erfolg gehabt.

Edit: Link zur Navteq Developer Seite ergänzt

Hallo papaluna,

habe gerade gesehen, dass Du dieselbe Frage auch im Groundspeaks Forum gestellt hast. Bisher noch ohne sinnvolle Antwort

Hast Du mal daran gedacht bei http://tech.groups.yahoo.com/group/map_authors nachzufragen? Vielleicht weiß ja da jemand Bescheid. Habe dort bisher keine Frage zu dem Thema gefunden.

Möchtest Du über die Carpool Lanes irgendwelche Ausschlüsse definieren?

Grüße

weoli

PS mit meinen Untersuchungen zum Routen bin ich bisher leider nicht viel weiter gekommen.

Hallo papaluna,

habe zurzeit leider nicht sehr viel Zeit zum Testen. Vielleicht wird es zwischen den Feiertagen etwas .

Bei der OSM Ecke habe ich noch die folgenden Diskussionen zum Thema gefunden. Vielleicht kannst Du da noch einiges rauslesen, falls Du die nicht eh schon kennst:

http://forum.openstreetmap.org/viewtopic.php?id=2008
http://forum.openstreetmap.org/viewtopic.php?id=666
http://forum.openstreetmap.org/viewtopic.php?id=1162

http://wiki.openstreetmap.org/wiki/Mkgmap/routing
http://wiki.openstreetmap.org/wiki/Talk:Mkgmap/routing

Mir war z.B. die Option -e für cgpsmapper zum Unterdrücken der Fehler bei zu dicht zusammenliegenden Knoten (das sind diese ominösen 5.4 m, die cGPSMapper anmahnt) neu. Der Rest gibt aus meiner Sicht auch nicht allzu viel Neues her. Das ist genauso ein Stochern im Nebel und Rumprobieren, wie wir es hier betreiben. Schade, dass über den Routingalgorithmus oder besser gesagt über den Einfluss der verschiedenen Parameter so wenig bekannt ist.

Zitat

Ich habe die "blauen" Nodes nicht gezählt, aber ich sitze seit 2 Monaten dran die nachzuarbeiten.

Ich vermute mal, dass Du deine Tracks in TTQV verwaltest. Ich mache dass zumindest mit meinen Zeichnungen und Tracks für meine selbst erstellten Karten so. Und dabei fällt mir immer wieder auf, dass selbst dann, wenn ich in TTQV die Polylinien mit der Option VORHANDENE PUNKTE FANGEN erstelle, und diese in TTQV somit eigentlich exakt aufeinander liegen, die Knoten in GPSMapEdit dann doch einen Abstand zueinander haben. Hast Du das Problem auch? Ich muss die Knoten dann immer mit Verify Map in GPSMapEdit suchen. Ist aber, wie Du schreibst, mühsam, ...

Ob die Option kürzere Strecke ein sinnvolles Routing ergibt, weiß ich nicht so Recht. Ich habe nur die diversen Diskussionen hier im Forum im Hinterkopf man solle beim Routing für das Rad immer die Option kürzere Zeit wählen, das kürzere Strecke zu den seltsamsten Ergebnissen führt.

Als Unterschied beim Routen für das Fahrrad und Fußgänger ist mir bisher nur aufgefallen, dass ich als Fußgänger durch eine Einbahnstraße in beide Richtungen geroutet werde. Als Fußgänger hingegen nicht.

Werde mir jetzt wohl erstmal eine kleine Testkarte erstellen und damit weiter versuchen.

Schöne Weihnachten

weoli

Hallo papaluna,

es erstaunt mich immer wieder wie die Entwicklungen parallel laufen! Vor ein paar Wochen habe auch ich, nachdem ich mir bisher eigentlich immer Overlaykarten erstellt habe, meine erste "experimentellen", routingfähigen Karten erstellt. Leider stehen ja dafür, wie Du schreibst, nicht allzu viele Informationen zur Verfügung! Beruht alles nur auf Untersuchungen und Experimenten.

Als Unterlagen für meine Untersuchungen habe ich nachstehende Quellen verwendet. Vielleicht ist ja was Neues für dich dabei und gibt Neues her:

http://v-dorogu.narod.ru/article/routemap.htm Ist zwar auf russich, aber Google Sprachtools reichen für das Verständnis des Artikels aus

http://rotweilermaps.com/files…lersAuto-routingGuide.pdf nicht mehr ganz aktuell, da die neuen Möglichkeiten von GPSMapEdit noch nicht beschreiben sind.

http://www.malsingmaps.com/wik…php/Making_a_Routable_Map

Ich fand eigentlich, dass die Arbeit zum Erstellen der Knoten, ... in GPSMapEdit gar nicht so schlimm ist. Knoten erzeugen geht leicht von der Hand, schwierig ist eher das Nacharbeiten und Zuweisen von Abbiegevorschriften. Wobei man darauf bei Fahrrad- oder Wanderkarten wohl eh meistens verzichten kann. Aufwendiger wird es aus meiner Sicht mit dem Zuweisen der Eigenschaften zu den Straßen, Wegen. Ich habe dazu meine Straßen, Wege bereits nach späteren Klassen auf verschiedenen Dateien unterteilt, die ich dann einzeln lade, Eigenschaften zuweise und dann wieder abspeichere. Erst am Ende erzeuge ich dann die Knoten und erstelle eine Karte daraus.

Leider weist GPSMapEdit den routingfähigen Polylinien nicht automatisch eine "Default" Eigenschaft für das Routing zu (Z.B: Typ Autobahn ==> Route Class = (4)Major HW, Speed Limit = (7)No Speed Limit). Die haben immer erst einmal nur die Einstellung Route Class = (0), Speed Limit = (0) und müssen so immer erst einmal richtig zugewiesen werden, außer man möchte diese Voreinstellungen behalten.

Das Routing in GPSMapEdit hat dann meistens auch wie erwartet geklappt. Kürzerer Weg oder kürzere Zeit in MapSource funktioniert auch. Am GPS (VISTA HCx bzw. 60Cx) habe ich nur einfache Versuche gemacht. Was mir z.B. bisher nicht gelungen ist, ist zdie Einstellung zur Vermeidung "unbefestigter Straßen", die sich in GPSMapEdit scheinbar direkt nach dem definierten Linientyp richtet, in MapSource aber überhaupt keine Auswirkungen hat. Gerade diese Eigenschaft ist aber für die Unterscheidung von Rennrad- (bei mir Tandemtouren) auf denen ich weitestgehend asphaltierte Wege und Straßen bevorzuge, normalen Fahrradtouren und ggf. MTB Touren für mich das Hauptkriterium.

In MapSource scheinen sich, zumindest entnehme ich das der russischen Beschreibung so, nur die Einstellungen für Speed Limit, Route Class und die sonstigen Einstellungen (Einbahnstraße, Maut, ...) auf dem Karteireiter Routing einer Polylinie in GPSMapEdit auszuwirken. Der Linientyp selbst hat keinen Einfluss.

Man muss wahrscheinlich daher an dieser Ecke ansetzen. Ich wollte über den Winter mal ein bisschen weiter experimentieren. Z.B. mit der Option Mautstraße als Eigenschaft für Routen die ich nur mit dem MTB befahren kann. Tragestrecken, Starke Steigungen, ... bekommen dann die Eigenschaft Mautstraße. Oder an den Geschwindigkeiten schrauben um bei "Kürzere Zeit" den Rennradstrecken eine hohe Geschwindigkeit zuzuweisen, die dann zu deutlich kürzeren Zeiten führt (das hat bei meinen Versuchen bisher als Einziges geklappt). Leider Hab' ich da nicht so viel Zeit.

Etwas scheint manchmal zu Fehlern zu führen. Wenn Du z.B. eine Strecke mit einer bestimmten Option berechnen lassen willst (z.B. vermeide Mautstraßen), der Algorithmus dann aber keine durchgängige Strecke ohne Mautstraßen findet, kommt eine Fehlermeldung, dass keine Route möglich ist.

Vielleicht tut sich ja in der nächsten Zeit etwas an der OSM Ecke. Da geht es ja mit schnellen Schritten voran.

Zurzeit habe ich es erst einmal bei einfachen "A nach B" Routingkarten belassen. Berechne Track oder Route, die exportiere ich dann und lade sie in GPSMapEdit. Dann Aufbereitung zur routingfähigen Karte, Import in MapSource, Setzen von Wegpunkten auf dieser neuen Karte (Anfangspunkt, Endpunkt, ggf. Zwischenpunkte) damit ich aussagekräftige Namen habe, Route auf dieser neuen Karte neu berechnen. Routet dann natürlich nur auf dieser einen "A nach B" Routingkarte. Das Ganze lade ich dann aufS GPS (Karte, Route und Wegpunkte). Karte liegt hinter meiner TOPO D. Dann am GPS Route neu berechnen auf der "A nach B" Routingkarte. Route folgt dann natürlich exakt der von mit gewünschten Strecke, ich bekomme Abbiegehinweise, kann die Autobahnseite benutzen, ... Ist natürlich noch keine vollständige Lösung, aber für die Aufbereitung meiner Touren besser als das Nachfahren eines einfachen Tracks. Und wer keine Arbeit macht, der macht sich eben welche Benötige aber zurzeit weniger als eine Stunde zur Erstellung einer "A nach B" Routingkarte. Für eine Mehrtagestour lohnt sich das dann schon.

Grüße

weoli

Martin,

Freitagnachmittag bei der Arbeit

mit fehlender Pixelreihe meinte ich nicht eine Pixelspalte oder -zeile in der "seamless" GeoTiff Kachel, sondern in der *.Bil oder den abgeleiteten *.hgts. Sobald ich Zeit habe, schreibe ich das mit ein paar Screenshots zusammen.

Ich nehme immer die 40_04 Kachel und sehe mir da die nordöstliche Ecke (N 45° E 20°) an. An den übrigen Ecken ist dann der Versatz gleich. Die 40_04er Kachel nehme ich deshalb, weil das die Kachel ist, deren Höhendaten ich für meine private Karte vom Gargano (Stifelsporn Italien) brauche.

Und nur ganz kurz zu den bisherigen Erkenntnissen:

Geotiff ==> Global Mapper ==> *.BIL kein Versatz (neue Kachel schließt oben rechts bei N 45° E 20° ab) ==> *.hgt mit BILxSTRM ergibt Versatz (1/2 Pixel nach Süden und Westen wenn ich es recht in Erinnerung habe, N 44° 59' 58.5" E 19° 19' 58.5")

Geotiff ==> MICRODEM ==> *.BIL ergibt Versatz (wenn ich es recht in Erinnerung habe 1/2 Pixel nach Norden und Westen N 45° 00' 1.5" E 19° 19' 58.5") ==> *.hgt mit BILxSTRM ergibt weiteren Versatz (1 ganzer Pixel [3'] nach Westen N 45° 00' 1.5" E 19° 19' 55.5")

Das liegt wahrscheinlich daran, dass die GeoTiff 6000 Pixel hat und exakt bei N 45° E 15° angebunden ist. Eine *.BIL oder *.hgt steht ja normalerweise um 1/2 Pixel über den Anhängepunkt hinaus. Das kann man sehr gut sehen, wenn man eine hgt in Global Mapper öffnet und das Gitternetz einblendet. Daher hat eine solche Kachel auch immer 1201 oder 3601 Pixel. Wenn man jetzt den Mittelpunkt des obersten linken Pixels der *.hgt betrachtet, liegt der z.B. exakt auf N 45° und E 15°. Bei der GeoTiff liegt der Mittelpunkt des obersten linken Pixels aber bei N 44° 59' 58.5" E 15° 00' 1.5". D.h. Du hast hier schon einen Versatz drin. (Bilder und genauere Auswertung folgen)

Grüße

weoli

Martin,

habe gerade nicht sehr viel Zeit mich mit der Materie zu befassen. Gestern abend habe ich mal angefangen den Grund für den fehlenden Pixel an der östlichen Kachelgrenze zu suchen. Da es schon spät war, bin ich nicht sehr weit gekommen. So weit aber schon mal vorweg, der Fehler beginnt bereits beim Abspeichern der *.BIL Datei. Da bekommt man schon einen Pixelshift mit MICRODEM rein. Bei Global Mapper übrigens nicht. Wenn man dann daraus *.hgt Dateien macht, pflanzt sich das fort und wird bei den aus der MICRODEM *.BIL erzeugten *.hgts noch größer. Ich hoffe, dass ich am Wochenende dazu komme das fortzuführen und kurz zusammenzufassen.

Grüße

weoli

PS "srtm_40_04_ARINFO_ASCII..." war der Name unter dem ich die Datei abgespeichert hatte, damit ich sie im Verzeichnis besser unterscheiden kann. Das ist die normale srtm_40_04.asc Datei. Die Adresse des italienischen FTP Servers hats Du ja zwischenzeitlich gefunden und die des CGIAR Servers steht im Eingangspost. Habe übrigens jetzt festgestellt, dass die Daten auf beiden Servern identisch sind. Meine Kachel vom CGIAR Server hatte ich am 18.09. runtergeladen. Das war in der Zeit der Umstellung von Version 4.0 auf 4.1. Jetzt liegen auf dem CGIAR Server dieselben Dateien vom 19.09. Bei denen ist dann auch der GeoTiff Header in Ordnung und es kommt keine Fehlermeldung beim Öffnen mehr. Damit entfällt das Anpassen des Headers wie weiter oben beschrieben.

PS

@martin

Danke für den Hinweis auf den italienischen FTP Server Wenn man den direkt über einen FTP client öffnet, ist das ja eine richtige Fundgrube. Da liegen ja viel mehr Daten rum als auf dem CGIAR Server direkt Der Pfad zum Server wird angezeigt, wenn man oben bei den Radio Buttons den italienischen Server wählt, im Webinterface irgendeine Datei auswählt und dann auf die zweite Seite des Webinterfaces wechselt. Entweder mit der Maus über die zum Download angebotene Datei fahren und den Pfad in der Statuszeiile des Browsers ablesen oder per Rechtsklick den Pfad speichern. Password ist keines erforderlich.

Habe eben mal die verschiedenen Dateien in Global Mapper geöffnet. Da kommen ja selbst wenn man Daten derselben Version (?) direkt vom FTP Server oder über das Webinterface herunterlädt unterschiedliche Ergebnisse raus. Scheinbar sind die Daten je nach Server unterschiedlich.

Aber eines habe ich zumindest in Global Mapper rein optisch schon mal festgetellt. Die ARC ASCII Daten und die GeoTiff Daten vom italienischen Server passen mit meinem Beispiel (das ist die Datei 40_04) exakt in das Gitter zwischen N 40.00° E 15.00° und N 45.00° E 20.00°. Mit den Daten müsste man also ohne jegliche Probleme die *.hgt Dateien erzeugen können.

Bei den Daten vom CGIAR Server kann man dafür in Global Mapper sehr gut sehen, dass sie um jeweils einen halben Pixel gegenüber dem Gitter versetzt sind, was dann ja zu dem von Dir beschrieben Problem bei der Erzeugung der hgt Dateien mit BILxSTRM führt.

Noch ein Hinweis. Bei den italienischen GeoTiff Daten ist ein *.twf Worldfile und eine *.hdr Headerdatei dabei, so dass beim Öffnen der Datei auch keine Fehlermeldung oder Abfrage nach der Projektion, ... kommen. ERGÄNZUNG: auch die GeoKeys im Datei-Header der GeoTiff Datei sind richtig eingetragen!

Grüße

weoli

PS in dieser PDF Datei (geotiffs.pdf) sieht man die Ergebnisse für die verschiedenen Dateien

Papaluna,

hab' Dank für den Hinweis. Gerade gestern hab ich im Installationsverzeichnis von MICRODEM die readme.txt gefunden. Und da steht es ja auch! Ich sag nur RTFM Und dann steht es auch noch groß auf der Downloadseite. Lesen müsste man können.

Grüße

weoli

Hallo Martin,

bist ja gerade mächtig am probieren ;), War leider am WE krank und jetzt ruft die Arbeit wieder.

Mir ist noch etwas eingefallen, was ich schon länger ausprobieren wollte, aber keine Zeit dafür gefunden habe.

Im Dokument ftp://e0srp01u.ecs.nasa.gov/sr…tes_for_ARCInfo_users.pdf findet sich folgender Satz:

Zitat

Users of ARC/INFO or ArcView can display the DEM data directly after renaming the file extension from .HGT to .BIL.

Dazu muss dann noch eine Header Datei erzeugt werden. Vgl. die Datei, die beim Abspeichern des GeoTiffs im *.BIL Format angelegt wird.

Dann müsste ja eigentlich auch der umgekehrte Weg gehen. Und ein bisschen Suchen führt dann zu diversen Beschreibungen wie z.B. der folgenden

Zitat

So theoretically what you could do is :

1. Download from Seamless in BIL format.
2. Change the extension from .bil file to .hgt
3. Rename the file so that it conforms to the hgt file name format.

Die *.hgt Datei hat ja keine Header Datei. Da ergibt sich der "Header" sozusagen implizit aus dem Dateinamen, der die Lage des DEMs festlegt. Durch die vorstehende Vorgehensweise müsstest Du eigentlich auch *.hgt ohne den Umweg über BILxSTRM erzeugen können. Die 5°x5°-Kacheln dürften nur für viele Programm etwas groß sein. MapEdit++ ist mir vor längerem immer beim Laden mehrerer *.hgt Dateien abgestürzt, die ich aus einem GeoTiff erzeugt hatte.

Die vorstehende Umwandlung ist übrigens auch im folgenden Thread http://forum.ttqv.com/viewtopi…0cdca7ed9d54f38f2c1f41b2c im TTQV Forum angesprochen. Jedoch hat der Schreiber seine Ergebnisse nicht mehr mitgeteilt.

Grüße

weoli

PS bekommst Du beim Starten von MICRODEM übrigens auch immer eine Fehlermeldung? Ich muss die wegklicken und danach in den Optionen die Menus für MICRODEM wählen. Mir fehlem ansonsten immer die ganzen bunten Icons in der Menuleiste. Die werden nicht gespeichert. Adminrechte habe ich. Vielleicht liegt es daran, dass ich weder MICRODEM in das vorgegebenen Verzeichnis installiert habe, noch die Daten im vorgeschlagenen Verzeichnis liegen.

Martin,

noch etwas ist mir gerade eingefallen. Du schreibst

Zitat

Nun die Probleme auf die ich gestoßen bin:
Problem 1: MICRODEM liest die *.ASC Dateien von CGIAR ebenso versetzt ein wie 3DEM die *.tif Dateien. Im Beispiel von Beitrag 13 wird die nördliche westliche Ecke eben nicht mit 45.000, 15.000 sondern mit 44.9995836, 14.9995837 eingelesen. Dadurch werden natürlich alle Höhendaten verschoben dargestellt, und bei der Erzeugung der *.hgt Dateien werden am westlichen und südlichen Rand der *.ASC Dateien zusätzliche *.hgt Dateien erzeugt; anstelle von 5 mal 5 werden 6 mal 6 *.hgt Dateien erzeugt.

Muss das nicht sogar so sein. Die Geotiffs überlappen sich um jeweils eine Pixelreihe/-spalte am Anfang der Kachel . Deshalb auch 1201 bzw. 3601 Pixel. Jedes Pixel stellt 3"x3" dar (0,000833°x0,000833°). Die Pixel tragen die Information GTRasterTypeGeokey=RasterIsPixel. D.h. der angegebene Höhenwert bezieht sich auf den Mittelpunkt des Pixels. Bei 1 Pixel Überlappung ergeben sich so genau die angegebenen Koordinaten 44,9995836 = 45 - 0,000833/2 bzw. 14,9995837 = 15 - 0,000833/2.

Siehe folgenden Abschnitt aus dem Dokument ftp://e0srp01u.ecs.nasa.gov/sr…umentation/Quickstart.pdf

Zitat

SRTM3 files contain 1201 lines and 1201 samples. The rows at the north and south ecges as well as the columns at the east and west edges of each cell overlap and are identical to the edge rows and columns in the adjacent cell. SRTM1 files contain 3601 lines and 3601 samples, with similar overlap.

Ich bin bisher davon ausgegangen, dass dieser eine Pixel am Anfang der Kachel automatisch von den lesenden Programmen richtig berücksichtigt wird.

Grüße

weoli

Edit: Text aus pdf der NASA zur Erläuterung

Martin,

die Daten der VErsion 4.1 findest Du auch direkt auf dem FTP Server der CGIAR unter folgender Adresse ftp://srtm.csi.cgiar.org/SRTM_v41/SRTM_Data_GeoTIFF/. Denke, dass Du mit den Kachelbezeichnungen klar kommst.

Joern, weißt Du um welche Daten es sich beim Herunterladen über die grafische Oberfläche der CGIAR handelt? Sind das die Daten der Version 4.1? Oder sind das noch Daten der Version 4.0? Ich hatte damals als die Daten von der 4.0 auf dei 4.1 umgestellt wurden durch Zufall gerade versucht Dateien vom FTP Server runterzuladen. Und da sind dann nach und nach die Daten im FTP Verzeichnis der Version 4.0 verschwunden. Die der Version 4.1 waren erst ein paar Tage unvollständig und wurden dann nach und nach vervollständigt. Jetzt sind die Verzeichnisse der Version 4.0 alle leer und direkt finde ich nur die Daten der Version 4.1 im GeoTiff Format.

Grüße

weoli

Joern,

hab Dank für die interessante Anmerkung. Jede deiner kurzen Einlassungen wirft für mich meistens wieder eine Menge Fragen auf.

Z.B. schreibt ja sowohl die NASA als auch die CGIAR, so wie Du es oben angemerkt hast, dass für die herunterladbaren Höhendaten das 'horizontal datum' WGS84 und das 'vertical datum' EGM96 gültig ist. Gibt's da übrigens einen Unterschied zwischen EGM96 (CGIAR) und WGS84/EGM96 (NASA)? Auf beiden Seiten wird das 'vertical datum' unterschiedlich bezeichnet.

Daher gehe ich davon aus (auch wenn ich Deinen post richtig verstehe), dass bei den heruntergeladenen Daten der Shift nicht eingerechnet ist. Die Korrektur des Shifts müsste ich mit einem Programm vornehmen und bekäme daraus die Werte für WGS84. Diese so korrigierten Werte wären dann die richtigen? Nur welches der 'consumer'-Programme (Global Mapper, TTQV, ...) berücksichtigt diesen Shift zwischen WGS84 und EGM96? Ich kann doch immer nur ein Datum angeben und das ist das Horizontaldatum. Woher sollten die Programme wissen, dass sie die Höhenwerte (seien es nun *.hgt Dateien der NASA, GeoTiffs der CGIAR oder USGS), die sie bekommen umrechnen müssten. Die Angabe des 'vertical datum' habe ich noch in keinem Headerfile oder GeoTiff-Header gesehen. Woher sollten die Programme die Information bekommen? Soweit ich das auf der Seite von remotesensing.org zu den GeoTiff Spezifikationen sehe, gibt es da zwar schon diverse 'Vertical ..' Keys zur Beschreibung des verwendeten Vertikaldatums, EGM96 fehlt aber. Man könnte es also gar nicht in den GeoTiff Header eintragen.

Dieselbe Unstimmigkeit, wie bei den von mir im Header ergänzten GeoTiff Daten der CGIAR, tritt doch auch auf, wenn ich eine Original USGS GeoTiff Datei nehme. Auch da ist als Datum lediglich das Horizontaldatum eingetragen (siehe CGS ...). Auch die haben als Vertikaldatum aber EGM96. Daher muss man doch im Augenblick wahrscheinlich immer mit dieser Unstimmigkeit leben, oder? Außer man würde nach dem Herunterladen die Daten enstprechend aufbereiten. Für meine Anwendungsfälle zur Abschätzung der zurückgelegten oder vor mir liegenden Höhenmeter, kleine eigene Karten, ... wäre das wohl doch zuviel Aufwand.

Grüße

weoli

Hallo Papaluna,

habe mal versucht die folgende Problematik

Zitat

In MICRODEM 10.0, Build 2008.11.2 fehlte bei mir die Möglichkeit ins BIL-Format zu exportieren.
Habe ich da etwas übersehen.???

nachzuvollziehen und weiß jetzt woran es liegt.

Wenn Du die CGIAR Daten im GeoTiff Format runterlädst und versuchst die in irgendeinem Programm, das die Höhendaten anzeigen oder verwenden kann (GlobalMapper, DEM2TOPO, 3DEM, TTQV und auch MICRODEM), zu öffnen, kommt es zu Warnungen bzw. Fehlermeldungen, dass die Einträge (GeoKeys) im Datei-Header nicht vollständig sind. Es fehlen u.A. Informationen zum Kartenbezugssystem, … (z.B. Fehlermeldung von DEM2TOPO welche die fehlenden tags GTModelTypeGeoKey, GTRasterTypeGeoKey und GeographicTypeGeoKey anmahnt).

Lädt man hingegen die SRTM3 Daten der NASA Version 2 bei http://seamless.usgs.gov/ im Geotiff Format runter und öffnet diese in einem der vorgenannten Programme so kommt keine Meldung. Man kann die Header der Dateien dann z.B. mit ListGEOg (GeoTIFF Tools GUI) analysieren.

Vgl. den folgenden Header der Kachel srtm_40_04.tif von CGIAR, da müssten die vorgenannten GeoKeys hinter Keyed Information: folgen und normalerweise auch ein Block zur Definition des Kartenbezugsdatum, ...

Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
14.9995837 44.9995836 0
ModelPixelScaleTag (1,3):
0.000833333333 0.000833333333 0
End_Of_Tags.
Keyed_Information:
End_Of_Keys.
End_Of_Geotiff.

Corner Coordinates:
Upper Left ( 15.000, 45.000)
Lower Left ( 15.000, 40.000)
Upper Right ( 20.000, 45.000)
Lower Right ( 20.000, 40.000)
Center ( 17.500, 42.500)

Im Vergleich dazu ein Header einer GeoTiff Datei von seamless.usgs.gov (Kachel deckt einen kleineren Bereich ab, als die vorgenannte)

Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
15.30625 42.1120833 0
ModelPixelScaleTag (1,3):
0.000833333333 0.000833333333 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeGeographic
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GTCitationGeoKey (Ascii,219): "IMAGINE GeoTIFF Support\nCopyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved\n@(#)$RCSfile: egtf.c $ $Revision: 1.11.2.3 $ $Date: 2004/11/24 09:12:56EST $\nProjection Name = GCS_WGS_1984\nUnits = dd\nGeoTIFF Units = dd"
GeographicTypeGeoKey (Short,1): GCS_WGS_84
GeogAngularUnitsGeoKey (Short,1): Angular_Degree
End_Of_Keys.
End_Of_Geotiff.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)

Corner Coordinates:
Upper Left ( 15d18'22.50"E, 42d 6'43.50"N)
Lower Left ( 15d18'22.50"E, 41d34'34.50"N)
Upper Right ( 16d12'19.50"E, 42d 6'43.50"N)
Lower Right ( 16d12'19.50"E, 41d34'34.50"N)
Center ( 15d45'21.00"E, 41d50'39.00"N)

Wenn man nun die fehlenden tags (den tag GTCitationGeoKey hab ich nicht eingetragen) und den Block zwischen Enf_Of_Geotiff. ..... Corner Coordinates: in den CGIAR Daten analog zu den vorstehenden Einträgen ergänzt, lässt sich die CGIAR Datei ohne Meldungen in allen Programmen öffnen und in MICRODEM steht auf einmal auch wieder die Option zum Speichern als BIL zur Verfügung. Die Daten im ArcInfo ASCII-Format hingegen sind von Anfang an wahrscheinlich richtig referenziert und bringen alle nötigen Informationen mit. Daher kannst du die dann wohl auch immer im BIL Format exportieren. Scheint wohl eine Eigenart von MICRODEM zu sein. Allein mit dem Programm könnte man Tage verbringen um die ganzen Möglichkieten auszuloten.

Grüße

weoli

Klaus,

so habe jetzt ein bisschen gespielt und folgende Erkenntnisse für die Darstellung in MapSource gewonnen:

a) Damit die Schummerung erscheint, müssen die Leveleinstellungen der eigenen Karte mit der Leveleinstellung der Karte übereinstimmen, aus welcher das DEM stammt. Die Anzahl der Level muss sowieso übereinstimmen. Siehe auch den Blog von YoMismo

Beispiel mit der Basemap des COLORADO und einer selbst erstellten Karte

Basemap: Level0 - Level5 haben die BITs 17, 15, 13, 12, 11, 10
Eigene Karte: Level0 - Level5 haben die BITs 24, 22, 20, 18, 17, 16

==> Schummenrung wird nur dargestellt, wenn ich Detailstufe Mittel wähle und ganze Karte anzeige (STRG+-) In MapSource 6.13.7 wahllose Abstürze beim Zoomen. In MapSource 6.14.1 aber ok . Sobald ich reinzomme verschwindet die Schummerung. Wenn ich von Anfang an Detailstufe am höchsten wähle sehe ich nie eine Schummerung.

Basemap und eigene Karte Level0 - Level5 haben die BITs 17, 15, 13, 12, 11, 10

==> Schummerung unabhängig von Zoomstufe und Detailstufe sichtbar. Die Karte ist dann jedoch aufgrund der starken Generalisierung (keine Kurven in Straßen, Höhenlinien nur noch gerade Linien mit Knicken, die sich überschneiden, ...) für eine TOPO mit den o.g. Level und zugehörigen BIT Einstellungen nicht mehr brauchbar.

b) die Schummerung wird unabhängig von der Einstellung für die Transparenz gezeigt. In meinem Beispiel habe ich die Karte immer ohne Transparenz erzeugt. Habe aber auch die beiden anderen Einstellungen in cGPSmapper probiert.

c) die unter dem Cursor angezeigten Höhenwerte (sichtbar unten neben den Koordinaten oder beim Absetzen eines neuen Wegpunktes) weichen zum Teil sehr stark von den aus eine TOPO abgelesenen Werten ab (mehr als 400 m). Je weiter ich rauszoome umso schlechter stimmen die Werte überein. Aber auch bei Überzoom weichen die Werte zum Teil in dem von mir untersuchten Bereich um mehr als 50 m ab. Das dürfte aber ein Effekt sein, der aus der schlechten Auflösung der DEMs resultiert. Bei der TOPO D v2 ist die Übereinstimmung wesentlich besser.

==> Basemap des COLORADO zum Testen ganz schön, aber für eigene TOPOs oder für eine OSM Karte wohl kaum brauchbar. Eben eine Basemap und kein SRTM3 oder 1. Wohl eher SRTM30.

Grüße

weoli

PS ich könnte Dir noch ein kurzes PDF mit ein paar Bildern schicken. Ist zu groß zum Anhängen (1,8 MB). Falls Du es möchtest bitte PN

Klaus,

und noch etwas zu dem Thema. Habe eben in meiner Mittagspause noch mal in Ruhe den spanischen Blog gelesen. Jetzt weiß ich auch, was YoMismo mit dem Erzeugen der *.tdb in GmapTool meint. Damit ist das Extrahieren der einzelnen Kacheln aus der gmapsupp.img mit der Option Split gemeint. Nur so wird wohl eine *.tdb erzeugt, die etwas von den DEMs weiß.

Grüße

weoli

Klaus,

hab' leider frühestens morgen Abend Zeit da ein bisschen zu experimentieren. Hoffe auf ein regnerisches WE

Schade, dass es noch nicht gelungen ist die Garmin DEMs zu entziffern. Hatte Joern Weber ja neulich auch schon mal gefragt, ob es da was Neues gibt und von popej zur Antwort ein Nein bekommen. Dann könnte man sonst seine eigenen DEMs produzieren. Habe neulich mal versucht ein Garmin DEM mit allen zur Verfügung stehenden Importmöglichkeiten in GlobalMapper zu öffnen. Aber leider nur jede Menge Fehlermeldungen wegen ungültiger Header, unbekannte Datei, ... Ist wahrscheinlich wieder so ein proprietäres Binärformat und dann noch komprimiert und ... Viel mehr als Koordinatenpaare und zugeh. Höhen wird da wohl nicht drin sein. Aber wer weiß, was die Zukunft bringt? Bei den vielen Spezialisten in Osteuropa (Konstantin, Stan, Popej, ...), ohne die wahrscheinlich eh nicht viel gehen würde und vor denen man nur den Hut ziehen kann. Wir wenden ja in der Regel nur deren Tools an.

Grüße

weoli

Klaus,

wenn der höchste Level der TOPO jetzt 17 ist, dürfte das mit der COLORADO Basemap aber keine gute Idee sein, da dann die Topo zu stark generalisiert worden ist. Da müssten ja alle Straßen fast nur noch gerade Verbindungslinien zwischen zwei Orten sein und kleine, kurze Wege, Bäche, Flächen fast ganz verschwunden sein, oder?

Grüße

weoli

PS Während ich die geantwortet habe, wurde der Thread abgetrennt. Hab Dir zuerst im alten Thread geantwortet und mich gewundert, dass die vorherigen Fragen und Antworten weg waren..

Klaus,

wenn der höchste Level der TOPO jetzt 17 ist, dürfte das mit der COLORADO Basemap aber keine gute Idee sein, da dann die Topo zu stark generalisiert worden ist. Da müssten ja alle Straßen fast nur noch gerade Verbindungslinien zwischen zwei Orten sein und kleine, kurze Wege, Bäche, Flächen fast ganz verschwunden sein, oder?

Grüße

weoli

Klaus,

so wie ich das verstanden habe, müssen die Levels Deiner neuen Karte aber mit den Levels der Karte übereinstimmen, aus der Du das DEM extrahiert hast (hier also die Basemap). Wenn die TOPO Deutschland v1 5 Levels hat, dann hat die Basemap wahrscheinlich auch 5 Levels oder weniger.

Grüße

weoli