Hallo NOP,
habe gerade versucht, für den bevorstehenden Wander Urlaub noch mal die passende Composer Karte neu bilden. Dabei ist folgendes passiert:
der Download der Plant Files klappt nicht mehr, Beispiel Oberfranken:
alter File Name: oberfranken.osm.pbf
neuer File Name: oberfranken-250908.osm.pbf
Wie es aussieht, werden jetzt wohl die osm.pbf Files mit einem Datum versehen, die der aktuelle MC 1.4 noch nicht erkennt.
Diese "Datums Ergänzung" hat sich allen Downloads, die ich "manuell" gestartet habe bestätigt.
Bitte prüfen und und dem MC ggf. korrigieren.
Mit freundlichen Güssen
Wilfried
Und nochmals zu den Höhendaten.
Wäre es möglich, im MC die Auswahl für "ViewFinderPanoramas" so zu ergänzen, das entweder die 1",3",oder 15" Höhendaten genutzt werden. Der User obliegt es dann. die richtige Auswahl zu treffen.
Problem beim Download der Plantfiles
Re: Problem beim Download der Plantfiles
Danke für den Hinweis mit den Planetfiles - hatte ich noch nicht bemerkt.
Muß ich mir mal anschauen wie ich das Composer beibringen kann. Momentan habe ich aber sehr viel um die Ohren...
Das mit den unterschiedlichen Auflösungen ist ein größeres Thema, wo vermutlich ziemlich viel neu geschrieben werden muß, außerdem verwendet auch mkgmap die Daten für die Schummerung mit, ich weiß nicht ob das damit klar kommt. Eher ein langfristiges Thema...
Muß ich mir mal anschauen wie ich das Composer beibringen kann. Momentan habe ich aber sehr viel um die Ohren...
Das mit den unterschiedlichen Auflösungen ist ein größeres Thema, wo vermutlich ziemlich viel neu geschrieben werden muß, außerdem verwendet auch mkgmap die Daten für die Schummerung mit, ich weiß nicht ob das damit klar kommt. Eher ein langfristiges Thema...
Re: Problem beim Download der Plantfiles
Ich habe jetzt mal versucht das Ganze nachzustellen, aber bei meinem Test hat der Download von Planetfiles einwandfrei funktioniert.
Composer sucht die *-latest.osm.pbf und auch die manuelle Kontrolle des Geofabrik Servers zeigt, daß die Dateien vorhanden sind.
Kannst Du es bitte auf Deiner Seite nochmal prüfen? Evtl. hatte der Geofabrik server mal einen Schluckauf und hat die *-latest Dateien nicht erzeugt. Jetzt sieht aber für mich alles gut aus.
Composer sucht die *-latest.osm.pbf und auch die manuelle Kontrolle des Geofabrik Servers zeigt, daß die Dateien vorhanden sind.
Kannst Du es bitte auf Deiner Seite nochmal prüfen? Evtl. hatte der Geofabrik server mal einen Schluckauf und hat die *-latest Dateien nicht erzeugt. Jetzt sieht aber für mich alles gut aus.
Re: Problem beim Download der Plantfiles
Hallo Nop,
du hast völlig recht, die Planet Files lassen sich ( auch bei mir) wie gewohnt wieder runter laden - also keinerlei Aktivitäten mehr von deiner Seite notwendig. Ob ich, wie du annimmst, einen "unglücklichen" Zeitpunkt für meinen Karten Update erwischt habe oder was auch immer - manchmal lohnt sich Geduld oder "keine Zeit" wirklich und ein vermeintliches Problem löst sich von alleine.
Bezüglich er Höhendaten habe ich auch noch mal überlegt - ist die (vermeintliche) Genauigkeit bei den Höhenangaben von Karten oder gespeicherten Tracks wirklich ein echtes der nur ein "akademisches" Problem?
Hier bei mir zu Hause differieren die Höhenangaben bei gespeicherten Tracks der verschiedenen H-Modell um ~3- 4 m, aus dem letzten Urlaub in Garmisch je nach Höhe (Wank) bis max 16 m und auf der Zugspitze ist die grösste Abweichung 39 m.
Wie du geschrieben hast, ist es sicher eine Aufwand/Nutzen Abwägung. Also erst einmal deine Ressourcen so verteilen, wie du es für nötig empfindest.
Einen schönen Tag noch und viele Grüsse
Wilfried
du hast völlig recht, die Planet Files lassen sich ( auch bei mir) wie gewohnt wieder runter laden - also keinerlei Aktivitäten mehr von deiner Seite notwendig. Ob ich, wie du annimmst, einen "unglücklichen" Zeitpunkt für meinen Karten Update erwischt habe oder was auch immer - manchmal lohnt sich Geduld oder "keine Zeit" wirklich und ein vermeintliches Problem löst sich von alleine.
Bezüglich er Höhendaten habe ich auch noch mal überlegt - ist die (vermeintliche) Genauigkeit bei den Höhenangaben von Karten oder gespeicherten Tracks wirklich ein echtes der nur ein "akademisches" Problem?
Hier bei mir zu Hause differieren die Höhenangaben bei gespeicherten Tracks der verschiedenen H-Modell um ~3- 4 m, aus dem letzten Urlaub in Garmisch je nach Höhe (Wank) bis max 16 m und auf der Zugspitze ist die grösste Abweichung 39 m.
Wie du geschrieben hast, ist es sicher eine Aufwand/Nutzen Abwägung. Also erst einmal deine Ressourcen so verteilen, wie du es für nötig empfindest.
Einen schönen Tag noch und viele Grüsse
Wilfried
Hochendaten in 1"
Naja, ich muß zugeben auch wenn es in dem Fall gut war - der Verzug war nicht geplant. 
Normalerweise bekomme ich eine Mail wenn jemand was Neues im Forum posted und schaue dann gleich rein. Aber manchmal scheint das schiefzugehen und ich übersehe dann den Beitrag auch mal eine Weile...
Das mit den Höhenangaben ist problematisch. Wenn die Daten aus der ursprünglichen Space-Shuttle Mission kommt (NASA SRTM), dann wurden im Wald die Baumspitzen gemessen, nicht der echte Boden, und auf Seen und im Gebirge haben die Daten Löcher, die irgendwie aus anderen Quellen oder durch kreative Mathematik aufgefüllt wurden. Mich erinnert das immer an einen Zahnarzt, der eine Füllung einsetzt und dabei die Form des Zahns so gut wie möglich nachahmt. Die von Dir festgestellten Abweichungen im Gebirge passen da sehr gut dazu.
Wenn nicht mittlerweile neuen Datenquellen aufgekommen sind, dann sind alle DEMs mit präzieseren Höhenangaben entweder kostenpflichtig oder haben eine zweckgebundene Lizenz (z.B. nur für Forschung) oder sind nur lokal für kleine Bereiche verfügbar. Der beste Kompromiß ist Viewfinderpanoramas, da wurden aber auch sehr viele verschiedene Quellen verwendet. Der Zugriff auf die 3" war schon recht kompliziert mit viel Handarbeit und Try&Error umzusetzen, weil die Kacheln nicht direkt zugänglich sind sondern in unregelmäßig benannten Archiven gruppiert.
Die 1" Daten haben eine ähnliche Struktur, aber die einzelnen Kacheln sind 9mal größer weil sie entsprechend mehr Stützpunkte enthalten. Das heißt dieser viel größere Kacheltyp muß neu eingebaut werden und die Zugriffslogik für die 1" ähnlich den 3" herausgetüftelt werden. Mkgmap kann solche Daten laut Dokumentation verarbeiten, allerdings habe ich in der Vergangenheit da schon schlechte Erfahrungen gemacht daß die Dokumentation - naja sagen wir etwas optimistisch war (laut Doku unterstützt, hat aber anfangs nur geklappt wenn alle Daten innerhalb einer einzigen DEM Kachel waren
).
Was auf jeden Fall bleibt ist das Problem, daß die 1" Daten nicht flächendeckend verfügbar sind und daß man bei einer Mischung wahrscheinlich immer eine sichtbare Kante beim Wechsel zwischen unterschiedlichen Quellen bekommt. Von daher würde ich nur entweder/oder unterstützen.
Vielleicht probier ich es mal einzubauen wenn der Winter lang wird...
Normalerweise bekomme ich eine Mail wenn jemand was Neues im Forum posted und schaue dann gleich rein. Aber manchmal scheint das schiefzugehen und ich übersehe dann den Beitrag auch mal eine Weile...Das mit den Höhenangaben ist problematisch. Wenn die Daten aus der ursprünglichen Space-Shuttle Mission kommt (NASA SRTM), dann wurden im Wald die Baumspitzen gemessen, nicht der echte Boden, und auf Seen und im Gebirge haben die Daten Löcher, die irgendwie aus anderen Quellen oder durch kreative Mathematik aufgefüllt wurden. Mich erinnert das immer an einen Zahnarzt, der eine Füllung einsetzt und dabei die Form des Zahns so gut wie möglich nachahmt. Die von Dir festgestellten Abweichungen im Gebirge passen da sehr gut dazu.
Wenn nicht mittlerweile neuen Datenquellen aufgekommen sind, dann sind alle DEMs mit präzieseren Höhenangaben entweder kostenpflichtig oder haben eine zweckgebundene Lizenz (z.B. nur für Forschung) oder sind nur lokal für kleine Bereiche verfügbar. Der beste Kompromiß ist Viewfinderpanoramas, da wurden aber auch sehr viele verschiedene Quellen verwendet. Der Zugriff auf die 3" war schon recht kompliziert mit viel Handarbeit und Try&Error umzusetzen, weil die Kacheln nicht direkt zugänglich sind sondern in unregelmäßig benannten Archiven gruppiert.
Die 1" Daten haben eine ähnliche Struktur, aber die einzelnen Kacheln sind 9mal größer weil sie entsprechend mehr Stützpunkte enthalten. Das heißt dieser viel größere Kacheltyp muß neu eingebaut werden und die Zugriffslogik für die 1" ähnlich den 3" herausgetüftelt werden. Mkgmap kann solche Daten laut Dokumentation verarbeiten, allerdings habe ich in der Vergangenheit da schon schlechte Erfahrungen gemacht daß die Dokumentation - naja sagen wir etwas optimistisch war (laut Doku unterstützt, hat aber anfangs nur geklappt wenn alle Daten innerhalb einer einzigen DEM Kachel waren
).Was auf jeden Fall bleibt ist das Problem, daß die 1" Daten nicht flächendeckend verfügbar sind und daß man bei einer Mischung wahrscheinlich immer eine sichtbare Kante beim Wechsel zwischen unterschiedlichen Quellen bekommt. Von daher würde ich nur entweder/oder unterstützen.
Vielleicht probier ich es mal einzubauen wenn der Winter lang wird...