osmconvert: --complete-ways und --all-to-nodes

In der aktuellen osmconvert 05.E muß noch ein Bug drin sein!

Im vergleich zu der 04.N bekomme ich zwar gleichviele Nodes und ways aber bei den Realtionen fehlt ein Teil ?
Read 1961163 nodes, 324950 ways and 4722 relations in total mit der 04.N
Read 1961163 nodes, 324950 ways and 3477 relations in total mit der 05.E (ohne --complete-ways !!!)
Read 1963569 nodes, 320297 ways and 0 relations in total mit der 05.E (mit --complete-ways !!!) allerdings aus der germany.osm.pbf mit dem Stand 1.11 da die europe.osm.pbf mit der untrigen Fehlermeldung abbrach!

Es dürften wieder hauptsächlich Waldgebiete sein - es sind auch Relationen bedroffen die komplett innerhalb der bbox sind (im prinzip sind die fehlenden Realtionen gelichmässig verteilt!)

Wenn ich --complete-ways und die europe.osm.pbf verwende bekomme ich die Fehlermeldung

Error: counld not rewind file: G:\PBF\europe.osm.pbf

Hallo, danke für die Info!
Ich hab grad die beiden Versionen selbst getestet und dann die Ausgabe mit diff verglichen, es kam das Gleiche raus. Mit germany.pbf hätte ich es auch gern probiert, aber der Download läuft zurzeit irrsinnig langsam. Ich werds später nochmal versuchen.
Welchen Bereich genau hast du ausgeschnitten? Und wie hast du hinterher die Objekte gezählt?

Denn geauen Bereich kann ich erst heut Abend nachschauen - es ist der Großraum um Frankfurt.
Verglichen hab ich mit Maperitive bzw. dessen Ausgabe wie viele Nodes Way und Relationen eingelesen - ist zwar kein direkter Vergleich aber da Maperitive die Hauptanwendung für die Daten ist, doch irgendwie das Maß.

Moin! :slight_smile:
Ich hab die Version 0.5E erstmal zurückgerufen. Im Wiki ist nun als “reguläre Version” die 0.4N verlinkt. Die neuere ist über einen extra Link downloadbar.

Inzwischen hab ich rausgefunden, dass das Problem beim Lesen von PBFs auftaucht: beim Extrakt von Bayern aus germany.pbf fehlen genau 803 Relationen. Ursache scheint der zweite Aufruf von “pb_input(true);” (direkt nach “wo_flush();” zu sein. Wenn ich den rauswerfe, läuft das Programm korrekt. Das will ich aber erst noch ausführlich testen und mit der nächsten Programmergänzung freigeben.

Danke für deinen Tipp!

Klappt recht gut !

Nur schade das man in der Batch-Datei nur mit ganzen Zahlen rechnen kann!

–complete-ways und auch --complete-relationen lösen leider nicht das Problem mit nebeneinander liegen Kacheln die man jede für sich rendern muß und die Text haben der in die andere Kachel hineinragt (siehe Zoom 8 und Ludwigshafen und Mannheim - normal wird nur Ludwigshafen angezeigt aber wenn die Mannheimer Kachel gerendert wird ist ja Ludwigshafen nicht drinn - dann steht in der einen halb Ludwishafen und in der anderen halb Mannhein heul).

Ein Rand von bis zu 0,3 Grad (je nach Zoomstufe) ist bei mir dafür erforderlich, für eine ordenliche Schumerung ist 0,01 Grad sinnvoll um weiße Striche zu vermeiden.

Ob er sinnvoll ist weitere Variablen aus MOBAC herauszugeben die bbox-Zuschläge mit eingerechnet haben oder dies extern zu lösen?

Gibt es einfache Lösungen um die command.com zu ersetzen? ohne gleich groß was zu installieren und die Gleitkommarechnen kann?

Hab mir die xml umgeschrieben um die Variablen an MortScript zu übergeben und mit dieser dann eine batch zu erstellen - aber das ist wohl etwas umständlich meiner Meinung!

Wieso?

Bzw hast du mal Dezimalpunkt statt Komma ausprobiert?

Gruß,
ajoessen

Klar alles durch!

Etliche Stunden mit Google und Co rumgesucht und nicht anderes als command.con rechnet nur INT !

Einige Ersatzprogramme für command.com gefunden aber nicht wie ich die ohne Installation bzw. Mehrbetriebssystemrechner die zum laufen bekomme.

Ich will ja kein neues DOS bzw. Betriebssystem sondern wie seit XP das das DOS unter Windows läuft - also als normales Programm!

Hi

mal nebenbei eine Frage an die OSMConvert, OSMFilter und Maperitive Experten. Gibt es da irgendwo ne zentrale Stelle wo man eventuell Filter bzw. Beschreibung was und wie man Ballast von den OSM Files entfernen kann, so dass das für den Input für Maperative “optimal” klein wird.

Gibt es da, so wie früher bei Kosmos, eine Stelle wo man Maperitive Rules “austauschen” bzw. bereitstellen bzw. abrufen kann?

Leider bin ich da in der Aufbereitung noch nicht so tief drin. Ich möchte aber eventuell ein C# Programm erstellen bei dem man die Parameter für die jeweiligen Tools in einer GUI eingeben kann. Aber eventuell ist das ja schon Alles (Ausschneiden) in einer zukünftigen Maperitive Version drin. Diese soll ja für größere OSM Files eine DB nutzen.

MfG
Achim

Ps: Zum Ausschnittproblem ne Frage: Reicht es nicht einfach in MOBAC einen größeren/großzügigen Auschnitt zu wählen (geht ja jetzt einfach) und dann den Renderbereich (Geometry Bound/PrintingBounds) MAPERITIVE zu begrenzen? Ist da dann das Randproblem trotzdem da?

–complete-ways funktioniert wunderbar mit srtm-daten aus srtm2osm, keine artefakte mehr an den rändern. aber: bei mehr als ca. 2gb input steigt osmconvert aus (cannot rewind…)

Sieht nach einem Problem mit vorzeichenbehafter Integer32 Zahl als Pointer aus.

Edbert (EvanE)

was ähnliches hier gefunden: http://wiki.openstreetmap.org/wiki/Talk:Osmfilter#Error_filtering_europe_dump

ich nutze win7 64bit, 4 gb ram, daran sollte es also wohl nicht liegen

Dafür gibt es keine generell gültige Antwort.
Das Randproblem wird durch Multipolygone erzeugt, deren “Kreise” aus mehreren Wegen bestehen. Durch den Befehl --complete-ways werden nur die geschnittenen Wege komplettiert. Wenn diese nach ihrer Vervollständigung die geöffnete Fläche wieder schließen, ist das Problem gelöst. Fehlen jedoch Wege für die Umschließung einer Fläche, weil diese nicht angeschnitten und somit auch nicht komplettiert wurden, bleibt die Fläche offen.
Wählt man einen größeren Kartenausschnitt, hat man eventuell Glück und erwischt alle Wege irgendwie. Es reicht ja ein winziges Stück, weil die angeschnittenen Wege ja komplettiert werden können.

Wenn man die Relationen per Befehl komplettieren kann/könnte, bräuchte man nicht mit der Bounding-Box herumprobieren und könnte den Vorgang automatisieren.

Meiner Meinung nach ist es aber kein sinnvoller Weg, die Bildung der riesigen Multipolygone dadurch zu unterstützen, daß deren Download vereinfacht wird.
Monsterpolygone gehören sinnvoll aufgeteilt. Denn:

  1. Viele Mapper suchen nach einem Weg, sich ohne großen technischen Aufwand einen kleinen Ausschnitt aus der Datenbank auszuschneiden und dann von einer begrenzten Gegend eine schöne Karte zu rendern. Wenn nun wegen der geschilderten Problematik große Datenmengen herunter geladen werden müssen, nur weil man mit seinem Kartenausschnitt leider ein Monsterpolygon ankratzt, dessen Ausdehnung die der gewünschten Karte möglicherweise um ein mehrfaches überschreitet, dann ist das eine sehr unerfreuliche Situtation.

  2. Während in einem Programm wie Maperitive bei der Erzeugung der Kartenkacheln lediglich ein großes Bild in Kacheln zerschnitten wird, sind bei der Erzeugung von Vektorkartenkacheln ganz andere programmiertechnische Probleme zu lösen. Eine Kachel faßt nur eine bestimmte Menge von Daten. Das ausgewählte Gebiet muß daher ab einer bestimmten Datenmenge zerschnitten werden und dabei entstehen mit den durchtrennten Polygonen immer dann Probleme, wenn das Programm nicht erkennt, daß zwei unterschiedliche Wege, die sich außerhalb der Kachel nicht berühren, nun am Kachelrand entlang zu einem “Kreis” geschlossen werden müssen. Kreuzen mehrere Outer-Wege eines Polygons den Kachelrand, dürfte es ziemlich kompliziert werden, diese nach dem Schneiden richtig aneinander zu hängen. Selbst wenn es gelänge, bleibt ein unschöner Effekt: der Rechenvorgang wird sehr aufwändig. Und das hat Folgen …

Das war die lange Antwort.

Die kurze heißt einfach: Kommt drauf an. :wink:

Gruß
tippeltappel

Klar könnte ich einen größeren Bereich wählen!
Aber ich müsste dann nochmal den Bereich markieren denn ich dann auch haben will - ist also auch keine optimale Lösung [Ich Rendere immer komplette Kacheln die nebeneinander liegen und habe keine lust jedesmal wenn ich nee Karte will vorher zu rendern - das erstellen mit MOBAC selbst ist ja nur Minutensache].

Bräuchte auch 2 Batch-Dateien

  1. Um Osmconvert anzusteuern
  2. Um Maperiative

Bei Gleikommarechnen usw. besteht auch die Möglichkeit gezielter auf die Datenerstellung einzugehen

z.B ermittle alter des OSMextrakts (z.B. wenn älter als 7 Tage neu, nachschauen ob Quell-Datei aktuell) ansonsten neu erstellen, osmupdate vorher??

gibts für den Bereich schon die Relief und Schummerung ? wenn ja nehm die ansonsten erstellen und von Maperitive abspeichern…

da tut sich einiges an Workflow Optimierung auf!

Hi

ich habe das bisher so in MOBAC integriert:
in Mobac… \tools dir steht osconvert.bat mit folgendem Inhalt:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> osmconvert cmd.exe /c start d:\www\_MyMap\batch\mobac.bat MIN_LON MIN_LAT MAX_LON MAX_LAT MIN_ZOOM MAX_ZOOM MAPSOURCE_NAME MAPSOURCE_DISPLAYNAME NAME_EDITBOX true

das"d:\www_MyMap\batch\mobac.bat muß natürlich angepasst werden. Das steht bei mir in einer eigenen Dir Struktur

mobac.bat hat folgenden inhalt:

pushd d:\www_MyMap\batch
…\OsmConvert\osmconvert ^
–drop-author ^
–complete-ways ^
…\bpf\baden-wuerttemberg.osm.pbf ^
-b=%1,%2,%3,%4 > ^
…\osm%9.osm
exit

das schneidet den pbf File aus.

Das mit Maperitive mache ich in der Testphase noch interaktiv. Aber einen Batchfile kann man anlog erstellen.
Man Ruft maperative mit einem Scrirpt auf

zB: Maperitive scripts\xx.mscript

und läßt sich bei der Generierung unterhalten mit der Option -exa wird Maperitive am Ende beendet

wobei xx.mscript so aussehen könnte:

use-ruleset alias=hiking
load-source “D:\www_MyMap\out\bbox.osm”
generate-contours
generate-tiles minzoom=5 maxzoom=15

Das einbauen in MOBAC falls gewünscht, geht wie mit obigem osmconvert…

Wenn das offiziell in MOBAC drin ist mache ich da einen eigenen Thread auf. Das hat ja eigentlich nichts mit diesem Threadthema zu tun.

MfG
Achim

Ps: Nach dem Rendern der Tiles kann ich doch das Ergebnis in Mobac betrachten. Alle Ausschnitte werden doch additive bzw. überschrieben gesammelt. Der Input für MOBAC wird so konfiguriert in mapsources steht zB: WomisaMaperitiveBeta.xml mit dem Inhalt:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Map source name as it appears in the map sources list. --> 
<name>womisa Maperitive-Beta </name>

<!-- 
  Directory in which the existing atlas is located.
  Inside the specified folder the different zoom level directories have to present.
  
  Structure example: 0/0/0.png for the "world tile" on zoom level 0   
-->
<sourceFolder>D:\www\_GPS\Maperative\Beta\Maperitive-1.1.2001\Maperitive\Tiles</sourceFolder>

	
<backgroundColor>#000000</backgroundColor>

in MOBAC kannst du doch dann letzendlich deinen "kleineren gewollten Ausschnit wählen und deine ZielAtlas generieren. Also kannst du doch vorher wesentlich größere Ausschnitte wählen! Der Knüller ist ja wenn du die generierten Tiles als MapSource generiert hast kannst du ja leere Kacheln selektieren und dann mit dem Batch die Tiles generieren. Nach dem generieren der Tiles muß aber MOBAC noch (?) beendet und neu gestartet werden, dass die neuen Kacheln angezeigt werde…it’s easy!!!

…mmmmh hab mal mehrere Gebiete gerendert, aber an den Schnittstellen sieht das furchtbar aus…nicht wie erwartet. Kommt das vom ausschneiden oder von Maperitive?

Wie hängt man da ein Bild dran?

==> http://augilabs.de/osm/bild/Schnitzel.png

Hallo,

wenn ich mich mal wieder kurz in die Diskussion einklinken darf… :slight_smile:

Bezüglich des angesprochenen 2-GB-Problems, lasse ich grad einen Test laufen. Meine erste Vermutung ist, dass die beim Erstellen des Programms hinzugelinkte zlib keine 64-Bit-Offsets unterstützt. Ich geh der Sache nach.

Version 0.5F (Beta!) hat nun eine neue Option bekommen: –complex-ways
Damit könnte das Multipolygon-Problem weitgehend gelöst sein. Bitte nicht wundern, mit dieser Option dauert es doppelt so lange, einen Bereich auszuschneiden. Im Fall einer PBF-Eingabedatei dauert es fast dreimal so lange.

Quellcode: m.m.i24.cc/osmconvert_new.c
Windows-Exe: m.m.i24.cc/osmconvert_new.exe

Hallo Markus,

das ist doch DEIN Thread und das MOBAC Thema ist zwischengefunkt und hat eigentlich da nichts zu suchen! Also sorry!

MfG
Achim

Hallo Achim,
nix da, mir gehören keine Threads, das Forum ist für alle da. Ich hatte meinen Einwand nicht ernst gemeint, nicht einmal ironisch. :slight_smile:
Und MOBAC hat ja auch mit dem Thema zu tun - finde ich.

Hat inzwischen noch irgendwer ein Problem mit der 2-GB-Grenze? Auf meiner 32-Bit-Kiste lief das Programm mit dem europe.pbf ohne Murren durch. Falls es bei irgendwem nicht klappt, wär ich an einer Testausgabe interessiert: Bitte Version 0.5H verwenden und beim Start als ersten Parameter -v=2 angeben. Wichtig wäre für mich die Zeile “zlib flags” (hier erklärt: http://zlib.net/manual.html ). Danke!

osmcovert.exe vom 15.11., 290.507 bytes, gelaufen auf win7 home premium 64bit, 4gb ram


test 1 - complete-ways läuft durch

file: 2.061.337.558 bytes

–statistics:

osmconvert Parameter: --statistics
osmconvert Warning: wrong sequence at way 1000000000
osmconvert Warning: next object is node 1000000003
osmconvert Warning: wrong sequence at way 1000000001
osmconvert Warning: next object is node 1000000033
osmconvert Warning: wrong sequence at way 1000000002
osmconvert Warning: next object is node 1000000042
lon min: 86.0000833
lon max: 89.0000833
lat min: 26.0001833
lat max: 28.0001813
nodes: 19888319
ways: 360952
relations: 0
node id min: 1000000000
node id max: 1019888318
way id min: 1000000000
way id max: 1000360951
osmconvert Error: write error.
osmconvert: Last processed: way 1000360951.
osmconvert Exit: 92

-B, --completeways:

osmconvert Parameter: -B=test.poly

  • 0 865655385,279600165,888849331,279168973
  • 1 861970673,263160995,865655385,279600165
  • 2 861970673,263160995,881381210,263080146
  • 3 878815071,270033107,881381210,263080146
  • 4 878815071,270033107,888849331,279168973
    Border polygons: 5. Now sorting.

0 861970673,263160995,865655385,279600165
1 861970673,263160995,881381210,263080146
2 865655385,279600165,888849331,279168973
3 878815071,270033107,888849331,279168973
4 878815071,270033107,881381210,263080146
End of border initialization.
osmconvert Parameter: --complete-ways
osmconvert Warning: wrong sequence at way 1000000000
osmconvert Warning: next object is node 1000000003
osmconvert Warning: wrong sequence at way 1000000001
osmconvert Warning: next object is node 1000000033
osmconvert Warning: wrong sequence at way 1000000002
osmconvert Warning: next object is node 1000000042
osmconvert: Last processed: way 1000360951.
osmconvert Exit: 92


test 2 - complete-ways läuft nicht durch

file: 2.502.583.962 bytes

–statistics:

osmconvert Parameter: --statistics
osmconvert Warning: wrong sequence at way 1000000000
osmconvert Warning: next object is node 1000000005
osmconvert Warning: wrong sequence at way 1000000001
osmconvert Warning: next object is node 1000000022
osmconvert Warning: wrong sequence at way 1000000002
osmconvert Warning: next object is node 1000000029
lon min: 85.0000833
lon max: 89.0000833
lat min: 26.0001833
lat max: 28.0001833
nodes: 24079510
ways: 480902
relations: 0
node id min: 1000000000
node id max: 1024079509
way id min: 1000000000
way id max: 1000480901
osmconvert Error: write error.
osmconvert: Last processed: way 1000480901.
osmconvert Exit: 92

-B, --completeways:

osmconvert Parameter: -B=test.poly

  • 0 865655385,279600165,888849331,279168973
  • 1 861970673,263160995,865655385,279600165
  • 2 861970673,263160995,881381210,263080146
  • 3 878815071,270033107,881381210,263080146
  • 4 878815071,270033107,888849331,279168973
    Border polygons: 5. Now sorting.

0 861970673,263160995,865655385,279600165
1 861970673,263160995,881381210,263080146
2 865655385,279600165,888849331,279168973
3 878815071,270033107,888849331,279168973
4 878815071,270033107,881381210,263080146
End of border initialization.
osmconvert Parameter: --complete-ways
osmconvert Error: could not rewind file: test2.osm

osmconvert Exit: 28


test 2 - ohne complete-ways, läuft durch

file: 2.502.583.962 bytes

–statistics:

osmconvert Parameter: --statistics
osmconvert Warning: wrong sequence at way 1000000000
osmconvert Warning: next object is node 1000000005
osmconvert Warning: wrong sequence at way 1000000001
osmconvert Warning: next object is node 1000000022
osmconvert Warning: wrong sequence at way 1000000002
osmconvert Warning: next object is node 1000000029
lon min: 85.0000833
lon max: 89.0000833
lat min: 26.0001833
lat max: 28.0001833
nodes: 24079510
ways: 480902
relations: 0
node id min: 1000000000
node id max: 1024079509
way id min: 1000000000
way id max: 1000480901
osmconvert Error: write error.
osmconvert: Last processed: way 1000480901.
osmconvert Exit: 92

-B

osmconvert Parameter: -B=test.poly

  • 0 865655385,279600165,888849331,279168973
  • 1 861970673,263160995,865655385,279600165
  • 2 861970673,263160995,881381210,263080146
  • 3 878815071,270033107,881381210,263080146
  • 4 878815071,270033107,888849331,279168973
    Border polygons: 5. Now sorting.

0 861970673,263160995,865655385,279600165
1 861970673,263160995,881381210,263080146
2 865655385,279600165,888849331,279168973
3 878815071,270033107,888849331,279168973
4 878815071,270033107,881381210,263080146
End of border initialization.
osmconvert Warning: wrong sequence at way 1000000000
osmconvert Warning: next object is node 1000000005
osmconvert Warning: wrong sequence at way 1000000001
osmconvert Warning: next object is node 1000000022
osmconvert Warning: wrong sequence at way 1000000002
osmconvert Warning: next object is node 1000000029
osmconvert: Last processed: way 1000480901.
osmconvert Exit: 92

Wenn die exe vom 15.11. ist, dann ist aber nicht Version 0.5H, oder? :wink:

0.5E

Wo krieg ich die H her?