-
Beiträge
-
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
BernardHallo Bernhard,
Ich verwende die aufbereiteten Shapes von Jochen Topf https://osmdata.openstreetmap.de/.
Die shapes aus den originalen Coastlines sind zu fehlerhaft für Mapsforgewget –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-GrenzenLG
Christian1 Teilnehmer(n) gefällt dieser Beitrag
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
BernardGib 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.
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
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
ChristianHallo 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
Bernard1 Teilnehmer(n) gefällt dieser Beitrag
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…
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
Bernard1 Teilnehmer(n) gefällt dieser Beitrag
Ja – hast‘ recht- geht auch noch im nachhinein:
mit osmosis einen einfachen lauf mit –sort-0.6 und es wird ebenfalls schön formatiertBeste Dank
Christian1 Teilnehmer(n) gefällt dieser Beitrag
„maxNodesPerWay“ habe ich inzwischen auf 200000 gesetzt
Könnte es sein das das Script keine Relationen mit geteileten outers beherrscht und daher bei 99000 NodesperWay fehlerhafte Ergebnisse liefert? = Komplizierte Küstenlinien absaufen?
Zumindest sieht das bei meinen Karten so aus… ?200.000 Nodes per Way wiederum gibt die rote Karte bei manchen OSM-Tools.
LG, Christian
Hallo Christian,
da bin ich eher überfragt. Ich verwende das Skript mit 200.000 Nodes als MaxZahl und habe bisher keine Probleme festgestellt.
Vom Code her wird für mein Verständnis diese Anzahl auch verwende, um längere Ways von Relations zu teilen.
Hast du mal ein Beispiel für eine „absaufende“ Küstenlinie?
Und welche OSM-Tools machen bei dir mit 200.000 Nodes Probleme?
Bei mir läuft die Kartenerstellung gerade ohne Probleme (habe gerade eine von Griechenland gebaut und da gibt es wahrlich viele Küstenlinien).
Grüße
BernardHallo Bernard,
Osmosis oder Osmconvert hat (auf Kubuntu) gejammert.
Komischerweise macht Ubuntu in WSL unter Win10 das nicht.Mit dem Limit auf 200.000 Nodes per Way sei Vorsichtig – für
Greece reicht das zwar mit max 119639 Nodes per Way
in Sweden sind das aber 260.311 Nodes max. per way.
Chrile_Argentina = 236453Ich häng dir hier ein Perl_Script an mit dem du das selber checken kannst.
Den Namen der zu prüfenden Datei musst du im Script anpassen.
Sonst einfach in das Kartenverzeichnis kopieren und starten.LG Christian
use strict; #my $infile = shift; #mapname my $infile = "bg_land"; my $inextension = "osm"; my $outextension = "csv"; my $infilestring = $infile . "." . $inextension; my $outfilestring = $infile . "." . $outextension; print "\n", $infilestring, "\n"; print $outfilestring, "\n"; my $mem_count=0; my $mem_max_count=0; my $cnt=0; my $id = 0; my $fh; my $line; #my @speicher = (); my $t; my $member; open( fh, $infilestring ) or die $!; open( fh_out, ">", $outfilestring ) or die $!; while ( $line = <fh> ) { if ( $line =~ /^\s*<way id=["']([+-]?\d+)["']/ ) { #print $1 . " "; $id = abs($1); #print $id . "\n"; $cnt++; #print fh_out $id,";"; } elsif ( $line =~ /^*<nd ref=["']/ ) { $mem_count++; } elsif ( $line =~ /^\s*<\/way/ ) { if ($mem_count > $mem_max_count) { $mem_max_count=$mem_count; #print "\r"; print $mem_max_count . "\n"; } if ($mem_count > 9000){ print fh_out $id,";"; print fh_out $mem_count,"\n"; #$member=(join ':',$mem_count,$id); #push (@speicher, $member ); } $mem_count=0; } } close(fh); close(fh_out);1 Teilnehmer(n) gefällt dieser Beitrag
Ich habe dieses ZählScript nun als Standard in meinen Prozess eingebaut und beobachte das mal mit dem alten shape2osm.
ogr2osm kann zwar eigentlich per parameter polygone aufteilen nur Mapsforge ist sehr heikel was solche polys betrifft. Im Falle von ogr2osm saufen diese polygone dann gerne ab.
Setze mal das Limit auf 1000 nodes per way .
Eigentlich sollte das funktionieren, tut es aber nicht.Die momentane Lösung wäre das Limit auf 300.000 nodes per way zu setzen, damit sollte Scandinavien und Südamerika auch gehen.
LG, Christian
1 Teilnehmer(n) gefällt dieser Beitrag
- Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.