[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

[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 Teilnehmer(n) gefällt dieser Beitrag

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.

2 Teilnehmer(n) gefällt dieser Beitrag

mbe57, ChristianK

[ChristianK]

Hallo Bernhard,

Gibt es ev. eine neuere Version von deinem ogr2osm – ich stelle gerade den Prozess etwas um und das ginge dann in einem Aufwaschen.

Danke im voraus
und LG
Christian

[bm.ffb]

Hallo Christian,
ich verwende im Prinzip immer noch genau die gleiche Version von ogr2osm. Nur den default-Wert des Parameter „maxNodesPerWay“ habe ich inzwischen auf 200000 gesetzt (war 100000). Und die letzte logging Zeile habe ich auskommentiert.
Ich hänge meine aktuell genutzte Version noch einmal an.
LG
Bernard

ogr2osm-1

1 Teilnehmer(n) gefällt dieser Beitrag

ChristianK

[ChristianK]

Kann man den etree.Elements für „nd ref“ hintendran ein \n spendieren ?
Also hier:

            for node in way.points:
                nd = etree.Element('nd',{'ref':str(node.id)})
                xmlobject.append(nd)
 
            tag = etree.Element('tag', {'k':'natural', 'v':'nosea'})
            xmlobject.append(tag)
            tag = etree.Element('tag', {'k':'layer', 'v':'-4'})
            xmlobject.append(tag)

Ich bin in pyhton nicht besondes fit…

[bm.ffb]

Hallo Christian,
ich bin auch kein Python „Experte“, aber mit ein bisschen Hilfe von KI habe ich das Script so verändert, dass es folgende „schöne“ Ausgabe im „*_land1.osm“ File macht (aus einer ganz kleinen Test-Karte):

{<osm version="0.6" generator="ogr2osm">
<node id="-10000000002" timestamp="1969-12-31T23:59:59Z" version="1" lat="47.756699999999995" lon="11.4476"/>
<node id="-10000000003" timestamp="1969-12-31T23:59:59Z" version="1" lat="47.756699999999995" lon="11.7656"/>
<node id="-10000000004" timestamp="1969-12-31T23:59:59Z" version="1" lat="47.5912" lon="11.7656"/>
<node id="-10000000005" timestamp="1969-12-31T23:59:59Z" version="1" lat="47.5912" lon="11.4476"/>
<way id="-10000000001" timestamp="1969-12-31T23:59:59Z" version="1">
    <nd ref="-10000000002"/>
    <nd ref="-10000000003"/>
    <nd ref="-10000000004"/>
    <nd ref="-10000000005"/>
    <nd ref="-10000000002"/>
    <tag k="natural" v="nosea"/>
    <tag k="layer" v="-4"/>
</way>
</osm>}

Der entsprechende neue Teil im Skript sieht nun so aus:

{        for way in ways:
            xmlattrs = {'id':str(way.id), 'timestamp':'1969-12-31T23:59:59Z', 'version':'1'}
            xmlattrs.update(attributes)
            xmlobject = etree.Element('way', xmlattrs)
            xmlobject.text = '\n    '

            for node in way.points:
                nd = etree.Element('nd',{'ref':str(node.id)})
                nd.tail='\n    '
                xmlobject.append(nd)

            # BEGIN:OpenOutdoorMap: tags for land polygons
            tag = etree.Element('tag', {'k':'natural', 'v':'nosea'})
            tag.tail='\n    '
            xmlobject.append(tag)
            tag = etree.Element('tag', {'k':'layer', 'v':'-4'})
            tag.tail='\n'
            xmlobject.append(tag)
            # END:OpenOutdoorMap}

Hoffe, ich habe deine Idee richtig verstanden.
Allerdings wird bei mir im anschließenden Schritt (sea und land wird mit osmosis kombiniert) ein File generiert, der bereits vorher eine korrekt .xml Struktur angezeigt hat.
Grüße
Bernard

• Diese Antwort wurde vor vor 2 Wochen, 1 Tag von bm.ffb bearbeitet.

1 Teilnehmer(n) gefällt dieser Beitrag

ChristianK

[ChristianK]

Ja – hast‘ recht- geht auch noch im nachhinein:
mit osmosis einen einfachen lauf mit –sort-0.6 und es wird ebenfalls schön formatiert

Beste Dank
Christian

1 Teilnehmer(n) gefällt dieser Beitrag

bm.ffb

[Autor]

Beiträge