lokalen Datenbankauszug (pbf) weiter pflegen

de_muur · January 6, 2012, 6:32am

Moin,

ich wuerde gerne fuer meine Region einen Datenbankauszug von der OSM-Weiterentwicklung abkoppeln. Fuer meine Zwecke reichen die vorhandenen Daten, da koennen Ergaenzungen durch andere Mapper erstmal nur stoeren. Auf der anderen Seite wuerde ich die Daten auch ein bisschen auslichten wollen, was in der OSM-Datenbank ja eher nicht erwuenscht ist.

Meine Frage ist nun, wie ich sowas technisch am Besten angehe.

Ausgangspunkt soll ein pbf-Extrakt von der Geofabrik sein, und editieren moechte ich am liebsten mit JOSM.

Verstehen aktuelle JOSM-Versionen pbf-Dateien oder muss ich vor dem Editieren die erst zu osm-Dateien konvertieren?
Wenn ich hin und her konvertieren muss, womit mache ich das am Besten?
Und wie pflege ich die mit JOSM erzeugten Aenderungen am besten wieder in die urspruengliche Datei ein?

Hat sich schon mal jemand mit diesem Thema beschaeftigt und kann mir da weiter helfen?

Gruss
Torsten

chris66 · January 6, 2012, 8:25am

Kommt erstmal auf die Größe des Ausschnitts an.

Ab einer gewissen Größe wirst Du vermutlich einen lokalen API Server aufsetzen müssen.

aighes · January 6, 2012, 8:40am

Mit Plugin kann josm zumindest pbf-Dateien öffnen. Speichern geht aber nur in xml.

Ein weiteres Problem ist, dass josm gelöschte Objekte nur mit einem meta-Tag visible=false kennzeichnet, kaum ein Auswerteprogramm ignoriert diese Daten aber. Wenn ich mich recht erinnere hat ein osmosis-Durchlauf die Daten gelöscht.

de_muur · January 6, 2012, 9:15am

osmosis scheint das richtige Stichwort zu sein. Anscheinend kann das im Wesentlichen, was ich machen moechte. Da werde ich wohl mal mit einem ueberschaubaren Beispiel rumprobieren.

Vielen Dank
Torsten

aighes · January 6, 2012, 9:27am

Achso…wenn du nur allgemein Filtern möchtest, kannst du dir auch osmfilter anschauen. Sobald du aber mit josm Daten wieder hinzufügen möchtest oder selektiv löschen möchtest, musst du nach einem Speichern immer osmosis durchlaufen lassen. Ansonsten bekommen die Folgeprogramme in der Regel Husten.

de_muur · January 6, 2012, 10:22am

Das ist genau das, was mir vorschwebt.

Soweit ich das bisher gesehen habe, sollte sich das mit JOSM und osmosis gut realisieren lassen, auch wenn man vielleicht besser auf xml-Dateien arbeitet als auf pbf-Dateien.

Ein Problem koennte noch dadurch entstehen, dass nach mehrfachen Ergaenzungen eventuell die IDs nicht mehr eindeutig sind. Das muss ich mal ausprobieren.

Gruss
Torsten

Marqqs · January 6, 2012, 7:01pm

Bei geänderten Objekten sollten von JOSM keine neuen IDs generiert werden, aber bei neuen schon, und zwar negative. Wie Osmosis damit umgeht weiß ich nicht. osmconvert hätte damit jedenfalls erst einmal ein Problem, weil JOSM bei jeder Edit-Session wieder bei -1 beginnt, es gibt also Kollisionen.

Falls du es mit Osmosis am Ende gar nicht hinkriegst, sag Bescheid, vielleicht finden wir einen Trick, mit dem es dann mit osmconvert klappt.

woodpeck · January 6, 2012, 8:24pm

Wenn Du immer die aktuelle Version “Deiner” Daten mit JOSM laedst, dann zaehlt JOSM artig im negativen Bereich weiter nach unten. Lediglich das Vermischen verschiedener JOSM-SItzungen wuerde Kollisionen geben.

Falls Du dann doch mal an den Punkt kommst, wo Du lieber eine “echte” lokale OSM-Datenbank haettest, gibt es fertige VM-Images mit Rails und Postgres und allem drauf, die Du praktisch nur noch starten musst:

http://matt.dev.openstreetmap.org/OpenStreetMap%20Rails%20Development.ova

Bye
Frederik

Lübeck · January 6, 2012, 10:09pm

hi !

auch auf die Gefahr hin das de_muur dieses Posting von mir wütend lesen wird aber ich muss es einfach mal loswerden.

Er erwartet das wir ihm bei der Weiterpflege “seiner” Daten behilflich sind - er aber auf der anderen Seite sich der Lizenzzustimmg verweigert und damit in Kauf nimmt das die Arbeit der Kollegen verloren gehen. Ist das der kollegiale Weg ???

Schade nur das ich ihn heute auch mit einer persönlichen eMail nicht habe umstimmen können.

Gruß Jan

kellerma · January 6, 2012, 10:31pm

Wenn er OSM komplett abgeschrieben hätte, würde er sich überhaupt nicht mehr mit OSM-Daten beschäftigen.
Wer weiß, vielleicht kommt ein Ablehner auch wieder zurück, vielliecht nicht heute oder morgen oder am 2. April, vielleicht im einem Jahr.

Never say never again

Lübeck · January 6, 2012, 10:43pm

hi !

aber dann sind die Daten aller voraussicht raus und de_muur hat in unserer Gegend sehr viele Grundlegende und wichtige Arbeiten gemacht.

Nach der ausführlichen Begründung von ihm vermute ich das er es ernst meint und nicht zu dieser Sorte Mapper gehört die die Welt ins Remappen zwingt - nur um ihre “Macht” zu zeigen und innerlich schon den Haken umgestellt hat. Sich nur cool vorkommen wollen - die gibt es nämlich auch.

Ich würde mich sehr freuen, wenn er doch noch vor dem 31.3.2011 - 23:59:59 den Haken umsetzen würde!

Gruß Jan

aighes · January 7, 2012, 1:39am

Wo steht das? Meinem empfinden nach, hat de_muur eine normale Frage gestellt. Keiner ist gezwungen, darauf zu antworten. Keiner muss helfen.

EvanE · January 7, 2012, 1:41am

Hallo Jan

Ich finde wir sollten hier nicht über die Entscheidungen einzelner Mapper diskutieren.
Auch wenn du in diesem Fall vielleicht durch die Ablehnung stark betroffen bist.

Er hat in vielen Diskussionen dargelegt, warum er die ODBL für seinen Anwendungsfall für unpassend hält.
Und dabei sollten wir es bewenden lassen.

Edbert (EvanE)

wambacher · January 7, 2012, 2:16am

Schau dir nur den “Aufmacher” des Threads an. Mit ein wenig Hintergrundwissen aus alten Lizenzdiskussionen ist doch alles klar.

Marqqs · January 7, 2012, 11:27am

Bitte nicht aufregen.

Wenn de_muur sich aus irgendeinem Grund gegen die neue Lizenz entscheidet, dann ist das sein gutes Recht, wir sollten das (und müssen das) akzeptieren. Es ist in meinen Augen völlig ok, wenn jemand nach Abwägung des Für und Wider zu dem Schluss kommt, sich gegen die Umlizenzierung seiner Daten zu entscheiden. Ich glaube nicht, dass ihm diese Entscheidung leicht fällt, zumal er ja dann selber mit ansehen muss, dass viele seiner Daten im Projekt nicht weiterverwendet werden.

Auch ich halte die neue Lizenz nicht für das Optimum. Nach längerer Überlegung bin ich aber zu einem anderen Schluss gekommen als de_muur. Er wird mir das genauso wenig vorwerfen.

Es geht hier aber gar nicht um eine Lizenzdiskussion, sondern um eine rein technische Frage. Natürlich können auf diese Weise Daten mit viel Aufwand auf der Grundlage von cc-by-sa weitergepflegt werden, aber man kann eine solche Toolchain auch für ganz andere Ziele nutzen, beispielsweise um eine neue Verkehrsführung zu Planen und beispielhaft auf einer Karte darzustellen - und das ganz ohne einen eigenen OSM-Server.

Schon allein deshalb halte ich de_muurs Frage für hilfreich, und ich überlege, ob ich osmconvert so ergänze, dass man damit per JOSM erstellte Objekte an eine bestehende OSM-Datei mit regulärer ID anfügen kann. Vielleicht gibt es dazu aber sowieso schon Scripte oder eine Funktion in Osmosis, die das erledigt? Weiß jemand etwas?

de_muur · January 7, 2012, 1:02pm

Aus diesem Grund habe ich meine urspruengliche Frage auch soweit wie moeglich technisch formuliert, um nicht in eine Diskussion ueber die Zielsetzung abzugleiten. Die ist bei mir uebrigens (noch) nicht die Lizenzfrage, die betrachte ich bislang als selbstgemachtes Leiden der OSMF. In meinen Augen gilt es in der OSM-Welt wichtigere Probleme zu loesen, z.B. warum die OSM-Garmin-Karten immer schlechter werden, obwohl sich das Konvertierungsprogramm staendig weiter entwickelt.

Ausserdem hat OSM in meinen Augen schon laengst ein Niveau erreicht, wo man sich fuer die Nutzung der Daten von den taeglichen Datenbankauszuegen loesen und stattdessen auf eine Art Stable-Releases aufsetzen sollte. Was hilft es, wenn ich einen erkannten Fehler in den Daten behebe, mir aber in der naechsten Version dafuer 10 neue einhandel, die parallel durch die Ergaenzungen anderer Mapper enstanden sind? Und wenn man mit Stable-Releases arbeitet, heisst das ja auch nicht, dass man sich komplett von der Datenbank abkoppeln will. Es spricht ja nichts dagegen, dass man den Fehler parallel in dem eingefrorenen Datenbestand und in der aktuellen Datenbank korregiert. Man muss sich halt dafuer erstmal entsprechende Verfahren erarbeiten.

Gruss
Torsten

aighes · January 7, 2012, 1:36pm

@Marqs: Ich hatte sowas mal recht stümperhaft für xml-Daten geschrieben.

Der Algorithmus sah ungefähr so aus:
Such maximale Way-ID und Node-ID
Dann Such Node-ID und Node-Ref
→ Wenn negativ, dann multipliziere mit -1 und addiere maximale Node-ID drauf
Dann Such Way-ID
→ Wenn negativ, dann multipliziere mit -1 und addiere maximale Way-ID drauf

Ich hab das für Seepolygone benötigt, wo keine Relationen vorkommen. Da das ganze (Seepolygone) nicht mehr nötig ist, seid mkgmap diese automatisch generieren kann ist das ganze wieder in die Tonne gewandert.

chris66 · January 7, 2012, 2:54pm

Mmmh, ist mir noch nicht aufgefallen. Hast Du eine spezielle Karte im Sinn?

gute Idee, weiss aber auch nicht wie man das geschickt aufsetzen könnte, so dass beide DB-Versionen einigermaßen
synchron bleiben.

de_muur · January 8, 2012, 1:01pm

Moin,

ich habe mal meine JOSM-Version aktualisisert und mit osmconvert ein paar Versuche gemacht.

Ausgangspunkt ist die unten aufgefuehrte Beispieldatei test.osm (zwei residential-Strassen, jeder Node ist ein bollard).

Diese habe ich nun mit JOSM bearbeitet und als test_mod.osm abgespeichert.

Node 23 mit name=deleted versehen und dann geloescht.
Node 33 mit name=moved versehen und dann die Position geaendert
Node 34 mit name=changed tag versehen und dann barrier=bollard entfernt und dafuer highway=traffuc_signals gesetzt
eine neue Strasse bestehend aus zwei neuen Konten hinzugefuegt
die Strasse mit name=neue strasse und highway=residential versehen
die neuen Knoten mit name=neuer punkt 1 und name=neuer punkt 2 versehen

Wie man in der unten aufgefuehrten Datei test_mod.osm sehen kann, hat JOSM fuer die neuen Knoten die IDs -122 und -121 und fuer die neue Strasse die ID -123 vergeben. (Ich hatte JOSM noch von ein paar vorherigen Tests geoeffnet, das scheint sich auf die IDs auszuwirken.)

Alle bearbeiteten Daten sind mit action=modify gekennzeichnet, der geloeschte Node ist mit action=delete gekennzeichnet.

Jetzt habe ich osmconvert auf die JOSM ausgabe losgelassen:
osmconvert.exe test_mod.osm >test_mod2.osm

Wie man in der unten aufgefuehrten test_mod_2.osm sehen kann, hat osmconvert

das mit action=delete markierte Element entfernt
die action=modify Markierungen entfernt
die iDs unveraendert gelassen.

Als letztes habe ich nun per osmconvert mal diff-Dateien zwischen den verschiedenen Versionen erzeugen lassen:
osmconvert.exe test.osm test_mod.osm --diff >test_mod_dif.osc
osmconvert.exe test.osm test_mod2.osm --diff >test_mod2_dif.osc

Wie man in den unten aufgefuehrten test_mod_dif.osc und test_mod2_dif.osc sehen kann, ist dabei folgendes herausgekommen:

die action=delete Markierung in der JOSM Ausgabe test_mod.osm wird nicht als Aenderung erkannt
nachdem der als geleoscht markierte Node per osmconvert aus der Datei entfernt worden ist, taucht die Aenderung auch in der Diff-Datei auf
die neu erzeugten Elemente werden beide Mal richtig erkannt
die veraenderten Nodes (sowohl die Koordinaten-Aenderung als auch die Tag-Aenderung) werden beide Mal nicht als Aenderung erkannt

Ich muss sagen, der letzte Punkt hat mich doch ziemlich unangenehm ueberrascht.

Gruss
Torsten

test.osm: