–complete-ways
Was soll ich sagen, Osmosis kann das ja schon lange: Beim Anwenden von geografischen Grenzen bewirkt diese Option, Wege nicht an der Grenze abgeschnitten werden, sondern alle ihre Knoten behalten, auch die, die nicht innerhalb des gewählten Gebiets liegen. Je nachdem, wie man die Daten weiterverarbeiten will, kann --complete-ways nützlich sein.
Leider wird dadurch aber das Ausschneiden etwas langsamer, weil ein Teil der Daten zweimal gelesen werden muss (.o5m ist hier schneller als .pbf und .osm).
–all-to-nodes
Manche Anwendungen können mit ways und relations nicht viel anfangen, weil diese beiden Objekttypen selbst keine Koordinaten besitzen. Will man beispielsweise wissen, wo sich ein Polygon (z.B. ein Gebäude) befindet, muss man zuerst alle seine nodes untersuchen. Bei Relationen (z.B. Gebäude mit Innenhof) wirds noch komplizierter, weil diese Wege, Knoten und sogar andere Relationen enthalten können, die dann wiederum Wege, Knoten und Relationen enthalten.
Die Diskussionen um die Wheelmap haben gezeigt, dass die Lösung des Problems nicht immer ganz einfach ist.
Mit der neuen Option wandelt osmconvert alle Wege und alle Relationen in Knoten um. Aus dem Weg mit dem ID 123456 wird beispielsweise ein Knoten mit dem ID 1000000000123456. Dieser neue Knoten erhält alle Tags des Wegs. Längen- und Breitengrad des neuen Knotens ist der geografische Mittelpunkt des Wegs. Bei Relationen passiert das Gleiche, die neue ID beginnt dann mit 2.
Für Osmosis gibt es übrigens seit etwa einem halben Jahr eine ähnliche Option. Dort heißt sie “–areapoints”, wandelt aber nur geschlossene Wege (Polygone) um und berücksichtigt keine Relationen. Trotzdem eine sehr nützliche Sache für diejenigen, die nur Osmosis einsetzen.
Wäre es möglich, dass hier ein Speicherproblem für die 32 Bit Fraktion auftritt, wenn du derartige IDs einschleust? Insbesondere Unter Windows gibt es Postgis immer noch nur für 32Bit.
Ja, kann natürlich passieren. Grundsätzlich kannst du den Offset mit “–object-type-offset=” einstellen. Falls es trotzdem Probleme mit einem bestimmten Programm gibt, bau ich gern noch etwas ein.
Natürlich kann man auch auf 32-Bit-Systemen mit 64-Bit-Zahlen arbeiten (dann halt etwas langsamer). Wär ja auch schlimm gewesen, wenn man früher mit den 8-Bit-Prozessoren nur bis 256 rechnen hätte können.
Aber manche Programme sind nicht darauf ausgelegt, da hat viw sicher Recht.
Mir ist dazu noch eine Idee gekommen, die ich inzwischen eingebaut hab (ab Beta 0.5A):
Man kann den Offset mit einer “+1” am Ende vorgeben. Das veranlasst das Programm, die IDs für ways und relations fortlaufend zu zählen. Beispiel:
–object-type-offset=1900000000+1
Ways bekommen dann IDs mit 1900000000, 1900000001, 1900000002 usw., direkt anschließend die relations. Eines geht dann natürlich nicht: man kann keine Updates für ways und relations einspielen, da sie keine definierte ID mehr haben.
Hi
mal ne naive Frage zwischendurch: Warum setzt man da nicht ne Datenbank ein und nimmt zum Beispiel beiC# die bei zu Verfügung stehende ulong (bereich 0 bis 18.446.744.073.709.551.615). Ist das nur aus Performance-Gründen? Wäre etwas “langsamer” und unter Verwendung der entsprechenden (Standard)Datentypen nicht einfacher für Erweiterungen und zukünftige Pflege?
Das ist aber keinesfalls als Kritik zu sehen, sondern nur als persöhnliche Info!
Du meinst, wenn man da dann keine Updates verwenden kann? Manche Anwendungen importieren immer komplett neu. Die opengastromap.de macht das beispielsweise so. In dem Fall spielt das Update keine Rolle, weil der Komplettimport sehr schnell geht, wenn es nicht viele Daten sind.
Manche Datenbanken besitzen keine brauchbare GIS-Erweiterung (wie z.B. die der Wheelmap) oder man will sich nicht auf Datenbankebene mit den komplexen Datenstrukturen beschäftigen und rechnet schon vor dem Import alles schön “flach” (Openlinkmap). Das erhöht die Datenbankperformance.
Es geht um Anwendungen, die nicht ausreichend oder gar nicht mehr gepflegt werden. Natürlich würde heute keiner mehr etwas Neues entwickeln und nur 32-Bit-IDs zulassen.
Danke für den kleinen Einblick in C#. Ich hab das Microsoft-C# bisher noch nicht verwendet, osmconvert ist in C99 geschrieben. Letztlich sind die Datentypen aber die selben, sie heißen nur etwas anders: vorzeichenbehaftetes 64-Bit-Integer “int64_t”, ohne Vorzeichen “uint64_t”.
Mmh, wenn man keine ways oder rels nicht mehr updaten kann (oder will), dann stellt sich die Frage, ob überhaupt noch
die nodes updaten will. Dann könnte man sich die --object-type-offset=+1 gleich sparen und vom Programm nach der letzten Node-ID
gleich weitermachen lassen mit ways & rels.
Wenn ich das richtig sehe, dass wir bei den nodes jetzt bei 1.5 Mrd schon sind, wird’s mit 32 Bit aber auch nicht mehr allzu lange gehen.
Stimmt. Man könnte auch die Nodes “zusammenschieben”, also ID-Lücken nutzen. Grad bei Extrakten würde man damit auch in Zukunft immer unter 32 Bit bleiben.
Mal schauen, ob sowas irgendwann notwendig wird… Falls ja, lässt sich das ja relativ einfach programmieren.
Ich hoffe das noch die option --complete-relations angedacht ist!
Dürfte ja ähnlich gelagert wie --complete-ways sein!
Ohne dies wird man wohl kaum die MP-Problematik angehen können.
Ein längere Rechenzeit nehm ich dafür gern in kauf - wenn diese nicht grad exorbitant ansteigt.
Von derzeit ca. 4min fürs Ausschneiden einer bbox aus der europe.osm.pbf würd ich auch mit --complete-relations 15-20min in kauf nehmen - währe immer noch deutlich schneller als mit osmosis!
Hallo Dirk, ja, das geht natürlich, weil osmupdate die Option auch nur an osmconvert weiterreicht. Allerdings sollte die Option nur beim letzten Merge angewendet werden - wie auch -b= und -B=. Ich glaube, das weiß osmupdate noch nicht, ich werde gleich eine aktualisierte Version hochladen (0.2F).
EDIT: Muss mich wohl korrigieren. Wenn z.B. ein Weg komplett außerhalb liegt und zu einem Zeitpunkt x einer seiner Knoten in den Bereich hineinverschoben wird, versucht osmconvert zwar, die übrigen Knoten mit einzuschließen, aber die sind ja nicht in der Datei enthalten, weil sie schon vor langer Zeit ausgefiltert wurden.
OK, das kenn ich nur vom a2p-Plugin von Osmosis. Wusste nicht, dass osm2pgsql sowas auch anbietet. Wandelt osm2pgsql ways UND relations um? Wie geht es dann damit um, wenn die IDs von ways und relations zufällig gleich sind? Oder zählt es einfach von -1 schrittweise abwärts?
Dann kanns aber trotzdem wieder passieren, dass nicht alle Programme damit klarkommen, weil nicht alle negative IDs verarbeiten können.
osm2pgsql wandelt nur Routen-Relationen in zusätzliche Wege um. Dabei wird als WegID die negative RelationsID genommen. Die Knotenkoordinaten stehen bei der Postgres-Datenbank für jeden Weg in einem Linestring drin. Von daher eine etwas andere Problemstellung.
Es spricht aber mMn nichts dagegen, den negativen ID-Raum zu nutzen, wenn bei den postiven das Ende der Fahnenstange erreicht wird. ggf fortlaufend nummeriert.
ist da auch ne ausführbare EXE für Windows downloadbar?
Super Programm Danke
Achim
Ps: Bei dem MOBAC Autor habe ich angeregt einen Batchtfileaufruf einzubauen und diesem Aufruf die BoundingBox Parameter und den Zoomlevel mitgeben. Eine erste Testversion läuft bei mir. In MOBAC habe ich via BATCH ein “OSMCONVERT” eingebaut (GUI für OSMConvert …hahaha) welches in im Zusammenspiel mit Maperitive super funktioniert. Das Problem von den Randgebieten habe ich jetzt auch erkannt. Gibts da ne Lösung?
Interessant, war mir noch nicht aufgefallen. Hab grad selber mal geschaut, “select * from planet_osm_polygon where osm_id < 0 limit 10;” liefert tatsächlich negative IDs.
Stimmt. Gut wärs halt nur, wenn die IDs reproduzierbar sind. Wenn also, aus Relation 123 immer Node 1000123 wird usw. Dann klappen am Ende auch Updates.
Ich hab die Beta inzwischen als reguläre Version 0.5E übernommen, das heißt, du kannst die EXE jetzt ganz normal über die Wiki-Seite runterladen - oder hier direkt: http://m.m.i24.cc/osmconvert.exe
Super! Klingt nach einer guten Kombination.
Mit “Rangebiete” meinst du das Problem, auf das mich tippeltappel gestoßen hat? Eine Lösung gibt es noch nicht, aber ich mach mir Gedanken drüber. Es betrifft fast nur Flüsse und Wälder, oder? Und immer geht es um eine Multipolygon-Relation?
vielen Dank für die neue Version. Mit “–complete-ways” werden bei mir jetzt die Wälder am Rand "besser/vollständiger gerendert. Mein MOBAC hat jetzt einen Menüpunkt osmconvert und man kann in MOBAC eine Boundingbox grafisch selektieren und die entsprechende OSM Datei generieren. Das Ganze wird dann mit Maperitive weiterverarbeitet. Früher war mein Boundingsbox -b=8.00… sehr felerbehaftet und sieht jetzt so aus -b=%1,%3,%2,%4 wobei die Parameter von MOBAC kommen.
Natürlich berichte ich, wenn das vollständig eingebaut ist. Angenehme Sache!
