Grenzproblem mit Geofabrik Extrakten

Hallo,

beim Bau meiner Garminkarte ist mir folgendes aufgefallen: An der deutsch/österreichischen Grenze gibt es auf deutscher Seite einen Wald der in den Bayern- oder Oberbayernextrakten nicht enthalten ist, aber sehr wohl in den Austria Extrakten. Alle anderen Elemente dieses Bereichs (Wege, etc.) sind aber (korrekterweise) in den Bayern und Oberbayern Extrakten enthalten. Das führt dazu das für diesen Bereich kein Extrakt alle Daten hat. Korrekterweise müßte der Wald eigentlich in den Bayernextrakten enthalten sein, da es noch deutsches Gebiet ist. Gebiet ist beim Schinder:
http://www.openstreetmap.org/?mlat=47.618&mlon=11.8546&zoom=14&layers=M

Ist das bei den Geofabrikextrakten einfach so und ich muß es hinnehmen, oder gibt es da Möglichkeiten alles komplett zu haben? Oder liegt das womöglich sogar an splitter/mkgmap?

Übrigens ist Deutschland auch im Bereich des Wettersteingebirges (südlich von Garmisch) abgeschnitten in den Geofabrik Extrakten. Da ist ein Bereich der eigentlich noch zu Deutschland gehört, aber nicht enthalten ist (das Reintal):
http://www.openstreetmap.org/?mlat=47.41&mlon=11.0572&zoom=14&layers=M

Etwas überlappende Extrakte wären eigentlich ganz nett.

Gruß
unixasket

Vieles sollte eigentlich seit ein paar Tagen behoben sein. Falls die Extrakte neuer sind als 24.6. solltest Du Frederik bescheidgeben.

Edit: Einige Fehler können natürlich auch mit einem grosszügigeren Ausschnitt noch bleiben. Es gibt ja auch Polygone, die weit über die Grenzen hinausgehen. Die sind dann auch mit dem grösseren Ausschnitt verstümmelt.

Meine Extrakte sind von gestern (ich achte immer auf ganz frische Ware :))

Das ist zum Beispiel am Schinder nicht der Fall. Der Wald ragt etwas in österreichischen Gebiet rein, liegt zum größten Teil aber in Deutschland und der Teil der nach Austria geht, geht dort maximal etwa 800 Meter rein.

Gruß
unixasket

Edit: Wie erreiche ich Frederik am besten?

Im Falle von Relationen die nur teilweise im Bereich des Extrakts liegen, ist nicht garantiert, daß die Daten vollständig enthalten sind.

Gruß Klaus

Bei Relationen und Multipolygonen ist relativ sicher davon auszugehen das diese nicht komplett im Extrakt enthalten sind wenn diese Objekte ausserhalb des Polygons haben.
Wenn dabei noch komplette Way der Relation bzw. MP ausserhalt des Polygons sind wird diese üblicherweise nicht gezeichnet.

Auch genauere Polygons schaffen da nur bedingt Abhilfe - da dazu alles an dieser enden (Strassen, Flächen…) müsste.

Alternative selber aus den europa-extrakt die Länder ausschneiden ( z.B. bei osmconvert mit --complex-ways) - da wird man erstaunt sein was da noch an Ways und Flächen dazugehört um “Komplett” zu sein.

OK, das erklärt das Waldproblem am Schinder, aber die vollständig fehlenden Teile im Wettersteingebirge dürften nicht sein. Auch der Schneeferner (Polygon vollständig in D) fehlt.

Gruß
unixasket

P. S.: Möglicherweise baue ich noch eine spezielle Grenzkarte mit einem Custom Extrakt von bbbike.org. Da sieht man nur leider nie von wann die Daten sind.

Der schreibt hier als Woodpeck, ich würde es über eine OSM-Nachricht versuchen. Die Geofabrik veröffentlicht die .poly-files, die sie zum Ausschneidfen verwenden. Da kannst ja vorher mal sehn, ob Schneeferner und der Wald drin liegen. Falls alle Ways eines MPs innerhalb des ausgeschnittenen Bereichs liegen, liegt der Fehler woanders.

Eigentlich finde ich das Polygon für Oberbayern (hier mal ein Stück Oberbayern- und Deutschland-Polygon) ganz passend in den beiden Gebieten. Immer schön ausserhalb der Grenzen und jedenfalls weit genug vom Schneeferner weg.

Das Datum der BBB-Extrakte kannst Du hier einsehen: http://download.bbbike.org/osm/planet/

Gruß, Thomas

Sorry, ich muß mich korrigieren in meiner jetzigen Bayern und auch Oberbayern-Karte ist der Schneeferner drin und auch das Reintal. Ich werde aber trotzdem eine Grenzkarte erstellen, da es zum Wandern im unmittelbaren Grenzgebiet nicht so toll ist, ständig eine andere Karte im Gerät aktivieren zu müssen (oder gar die SD-Karte austauschen zu müssen). Ich habe bereits einen Extrakt auf bbbike.org erstellt der das Gebiet München-Innsbruck, bzw. Bodensee-Salzburg umfaßt.

Der Europa-Extrakt ist ein bisschen heftig zum Download. Ich habe 6 Mbit-DSL. Mit VDSL sicher kein Problem, aber dann kommt hinzu das ich das auch noch speichern und weiterverarbeiten muß. Das Ausschneiden ist dann ja auch ein Akt der Recht viel RAM benötigt. Mit einem Quadcore mit 8 GB RAM mag auch die Weiterverarbeitung ein Klax sein, aber eine derartige Ausstattung habe ich nicht.

Klasse, danke. Wenn ich das recht interpretiere heißt das, wenn ich heute einen Extrakt erstelle sind die Daten frisch von letzter Nacht.

Gruß
unixasket

Vielleicht wäre auch der Alpen-Extrakt passend: Passau bis Venedig und Genf bis Wien…

Klar wenn man jeden Tag die Europa ziehen will ist das schon heftig jedes mal 3h zu saugen!

Aber mit osmupdate find ich hält sich das in Grenzen! 1mal die Europa und dann nur noch für jeden Tag 40-50MB Diff (wenn man es übergenau will gibt da sogar Minuten-Diff’s!).

Wenn man damit nur Karten macht kann man auch Version und Autor rausschmeißen - spart dadurch nochmal Speicher.
Und innerhalb von 3min (Hinweis osmconvert verwendet nur einen Core!) einen X-beliebig großen Ausschnitt irgendwo von Europa zu bekommen komm ich mit einen Download nicht hin!

osmconvert und osmupdate verwendet weniger Resourcen als Splitter und mkgmap…

Nach meinen Erfahrungen sind deine angeführten Gründe nicht stichhaltig!

Ich habe grade mal osmupdate ausprobiert, allerdings nicht mit ganz Europa, sondern mit der Alps Karte. Aber irgendwie klappt das nicht. Ich habe als Parameter angegeben: --base-url=Index of /europe/alps-updates. da wird aber nichts gefunden.

Gruß
unixasket

Die URL-Quelle hab ich noch nicht verwendet ich verwendete normalerweise die Standard-Diff (Da mein Gebiet etwas größer ist als Europe [Canaren noch dabei usw…])!!

Vorausetztungen erfüllt? : osmconvert und wget müssen Systembekannt sein - dann:

osmupdate europe_old.pbf europe_new.pbf
Die Standard-Diff-Quelle ist osmupdate bekannt und muß nicht angegeben werden.

Weitere Parameter die ich da mitgeben würde:

-B=europe.poly (bzw. entsprechende Poly für dein Gebiet)
–day

=
osmupdate --day -B=europe.poly europe_old.pbf europe_new.pbf

Danke, das lief jetzt ohne Fehlermeldung. Allerdings ist die neue Datei etwas kleiner als die alte. Kann das sein?

Gruß
unixasket

Das beim ersten mal die pbf-Größe kleiner wird ist schon möglich.
Im pbf-Format gibt es nverschiedene Formatkonforme schreib Möglichkeiten.

osmconvert unterstütz glaub ich 2 --emulate-osmosis und --emulate-pbf2osm

Inwieweit die sich unterscheiden???

Zusätzlich kannst du beim osmupdate Aufruf Parameter verwenden die osmconvert verwendet intressant besonders wenn du nur Karten damit erstellt ist --drop-version --drop-author damit wird die pbf nochmal kleiner da diese Infos für karten nicht gebraucht werden. Nur als Hinweis wegen Speicherbedarf…

statistische Infos bekommst du mit:

osmconvert --out-statistics europe_old.pbf

(glaub ich ungeprüft)

Ich habe jetzt mal bei mir das wöchentliche Update für europe.osm.pbf gemacht. Es hat bei mir 53M zusätzlich auf die Rippen bekommen. Ich rufe das Ganze mit

osmupdate --base-url=download.geofabrik.de/europe-updates -v europe-latest.osm.pbf europe.osm.pbf
mv europe.osm.pbf europe-latest.osm.pbf

auf. Eigentlich wird die Datei bei mir auch immer größer und nie kleiner.

Ich verwende wie gesagt nicht Europa, sondern den Alpen Extrakt. Das es beim ersten mal durch Umformatierungen kleiner wird kann ich mir schon vorstellen. Ich warte mal bis morgen und mache dann noch mal ein Update. Wenn es dann nicht größer wird stimmt etwas nicht.

Gruß
unixasket