[bm.ffb]

An die Experten:
Ich habe ein Windows-Batch-Skript für die Erstellung von mapsforge-basierten Karten (z. B. für Locus) entwickelt und dieses hier beschrieben und veröffentlicht:
https://www.maiwolf.de/openoutdoormap/
Dazu passend gibt es auch ein Karten-Thema für Locus:
https://www.maiwolf.de/locus/

Aktuell habe ich aber bei einigen Kartenbereichen Probleme bei der Erstellung der Land/Meer Grenzen. Ich verwende dazu als Basis die Landpolygone von hier:
https://osmdata.openstreetmap.de/data/land-polygons.html (in der Version “Format: Shapefile, Projection: WGS84”). Diese werden bei mir mit der Funktion “ogr2ogr” (GDAL) auf den betreffenden Kartenbereich zugeschnitten. Das funktioniert gut und zuverlässig und die Ergebnisse kann man z.B. hier kontrollieren: https://mapshaper.org
Im nächsten Schritt muss die entstandene “shp” Datei für die Weiterverarbeitung dann in eine “osm” Datei konvertiert werden. Dafür nutze ich eine (leicht abgewandelte) Version des Python-Skripts “shape2osm.py” (Quelle: https://github.com/mapsforge/mapsforge-creator/blob/master/shape2osm.py). Meine Version ist im Anhang.

Dabei stelle ich aktuell bei einigen Kartenprojekten fest, dass bestimmte Landpolygone dabei “verloren” gehen.
Beispiel 1:
Hier eine Karte von Nord-Norwegen (Bereich Senja Insel): Die shp-Datei sieht wie erwartet aus, bei der osm-Datei fehlt aber dann das Polygon der Insel! (Kontrolle in JOSM, Screenshots im Anhang).
Bespiel 2:
Bereich Ostsee-Fünen. Wieder sieht die shp-Datei in Ordnung aus, in der osm-Datei fehlen einzelne Polygone! (Kontrolle in JOSM, Screenshots im Anhang).

Andere Bereiche, z. B. Inseln und Festland im Norden von Kroatien, funktionieren einwandfrei.

Ich habe leider noch keine Ursache für die Probleme gefunden. Vielleicht hat hier jemand eine Idee.
Die OAM Nord-Norwegen Karte sieht korrekt aus. Gibt es dabei für die Landpolygone ein spezielles Verfahren? Sind vielleicht in den von mir gezeigten Beispielen Fehler in den Landpolygonen?

Grüße
Bernard

• This topic was modified 1 month ago by bm.ffb.

[ChristianK]

Hallo Bernhard,

Ich verwende die aufbereiteten Shapes von Jochen Topf https://osmdata.openstreetmap.de/.
Die shapes aus den originalen Coastlines sind zu fehlerhaft für Mapsforge

wget –no-check-certificate https://osmdata.openstreetmap.de/download/land-polygons-split-4326.zip

Im Anhang findest du mein modifiziertes shape2osm3.py

Aufruf:

python3 shape2osm3.py -l poly_output land_polygons.shp

Wichtig ist die Land/Meerflächen 0,5 Grad rundum grösser auszuschneiden (ogr2ogr) als die Kartengrenzen sonst gibts immer überflutete Flächen.
MapsforgeWriter schneidet das Ganze dann bei der Kartenerstellung dann ohnehin an den BBOX-Grenzen

LG
Christian

1 user thanked author for this post.

bm.ffb

[bm.ffb]

Hallo Christian,
danke für die Info und das Skript.
Zur Datengrundlage: Ich verwende die identischen Shapes von Jochen (aktuelle Version neu geladen).
Zum Skript: Ich habe es verglichen und finde nur wenige (sehr kleine) Unterschiede, die nach meiner Auffassung aber keinen Unterschied machen (z. B. die Start-ID usw.).
Zum Ergebnis: Egal mit welchem Skript (eure oder meine oder sogar die komplett originale Version), ich erhalte für meinen Test-Bereich immer das gleiche Bild: Es fehlt die Darstellung des Bereiches der Senja Insel. In der ausgeschnittenen .shp-Datei (Bereich: -clipsrc 17.4 69 18.4 69.4) ist er aber enthalten.

Dein Vorschlag, den mit oge2ogr auszuschneidenden Bereich um je 0,5 Grad zu erweitern, um auf der sicheren Seite zu sein, macht Sinn.
Ich habe das für den oben beschriebenen Bereich durchgespielt (Bereich: -clipsrc 16.9 68.5 18.9 69.9) und komme zu einem interessanten Ergebnis: Dieses Mal ist in der .osm-Datei der Bereich der Senja Insel wie erwartet, dafür fehlt ein Stück des norwegischen Festlandes (siehe Anhang). Die Karte würde somit hier auch falsch gerendert werden. Auch hier ist der zugeschnittene Shape File korrekt.

Für mich ist es somit immer noch ein Problem des shape2osm Skripts, denn egal, welcher Ausschnitt aus welcher Eingangsdatei ausgeschnittenen wurde, bei der Konvertierung von .shp in .osm sollten keine Daten verloren gehen.
Bin ich hier auf einen Zufallsfehler gestoßen (bei “zu” kleinem Kartenausschnitt)? Und sollte ich also besser einfach größere Karten bauen?
Grüße
Bernard

[ChristianK]

Gib 1° rundum dazu dann passt es.
ich habe eben meine Scripts überprüft..

Wenn du ein zuverlässiges shp2osm auf die Beine stellen kannst wäre ich dir dankbar.

[bm.ffb]

Gib 1° rundum dazu dann passt es.
ich habe eben meine Scripts überprüft..

Ich habe dein Skript mit einem um 1° Grad erweiterten Bereich (für Beispiel 1 oben) in der ausgeschnittenen .shp Datei getestet: Nun wird in der .osm-Datei zwar der gewünschte Bereich korrekt dargestellt (wenn man ihn am Ende mit mapsforge bbox entsprechend zuschneidet), dafür fehlen aber wieder “Kacheln” an den Rändern (Bilder im Anhang). Für mich funktioniert einfach die shp-zu-osm Umwandlung nicht korrekt und zuverlässig.

ABER: Ich habe folgende Lösung des Problems gefunden:
Nach einem Hinweis von Klaus (von der Freizeitkarte, https://www.freizeitkarte-osm.de/android/de/index.html), habe ich mich mit dem Skript “ogr2osm.py” befasst. Nach einer entsprechenden Anpassung (und Vereinfachung) funktioniert es bisher mit allen meinen Test-Bereichen problemlos. Die entstandene .osm-Datei enthält genau den vorher mit ogr2ogr ausgeschnittenen Bereich der .shp-Datei. Und: Das Skript kann ohne Probleme von einem Windows Batch-Skript aufgerufen werden. Ich werde also eher dieses Skript verwenden.
Eine Vorab-Version mit ein paar Hinweisen hänge ich an. Vielleicht ist das auch für die OpenAndroMaps Kartenerstellung interessant.

• This reply was modified 3 weeks, 6 days ago by bm.ffb.

1 user thanked author for this post.

ChristianK

[Author]

Posts