Arbeit mit planetfiles aus der Zeit vor der API 0.6

projecter63 · 2017-04-30 18:53:39

Moin,

warum überhaupt so'n Kram ?
Wir haben hier in Lübeck bald den 100. Stammtisch und wollen diesen nutzen, um mal wieder mit dem Thema OSM auf die Öffentlickeit und die Presse zuzugehen. Da ich Ende letzten Jahres eine große Karte vom Lübecker Stadtgebiet gerendert habe (M 1:15.000 in der Abmessung ca. 2 x 1 m), kam die Idee auf, den Stand der OSM-Daten zum Zeitpunkt des 1. Stammtisches mit den gleichen Renderregeln als vergleichbare Karte zu erstellen, um die lokale Entwicklung von OSM in der Zeitspanne unseres Stammtisches aufzuzeigen.

Also habe ich mir den alten Planeten geladen (zu Probezwecken gleich den von vor zehn Jahren, da dieser "schön klein" ist - planet-070613.osm.bz2) und mit der Bastelei angefangen:
1) Dieser Planet stammt noch aus der api 0.3-Zeit; ich habe ihn erstmal mit 04to05.pl ins api 0.5-Format gehebelt und
2) mit

sed 's/visible="1"/uid="1" user="1" visible="true" version="1" changeset="1"/g'

die fehlenden Attribute nachgeschoben.
3) Mit vi die ersten beiden Headerzeilen geändert und die dritte Zeile (<bounds .../> ergänzt. Nun schaut das schonmal nach api 0.6 aus.
Aber es gibt Fehler in den Ursprungsdaten; so habe ich
4) leere values (v="") durch Rauswerten der gesamten Zeile gekillt,
5) leere refs (ref="") mit einem existierenden 'Dummy-Wert gefüllt (dem eines existierenden Knotens außerhalb des zu rendernden Gebietes) und
6) leere roles (role="") durch Entfernen der gesamten role unschädlich gemacht.

Aber jetzt gibts noch'n fiesen Fehler, an dem ich gerade scheitere:
7) Es gibt <ways ...> ohne ursprüngliches visible="1"-Attribut; damit funzt die Ersetzung aus 2) nicht.

Im Ergebnis komme ich in der nicht gepackten osm-Datei bis Zeilennummer ca. 56.6 Mio von insgesamt 110.8 Mio Zeilen.
Klemme ich das </osm>-Tag ans Ende der mit osmosis extrahierten bbox

--bounding-box top=54.0 left=10.5 bottom=53.7 right=11.0

und rendere das dann mit Maperitive, sehe ich schon mal ein gutes Stück des Lübecker Stadtgebiet, aber noch recht löcherig - logisch, osmosis (V 0.40.1) reißt ja am ersten Fehler vom Typ 7) die Hufe hoch.

Jetzt frage ich mich:
Ist der Weg, alte Planeten zu nutzen, tatsächlich derartig steinig oder sehe ich nur den Wald vor lauter Bäumen nicht?
Und wer weiß, wieviele Fehlertypen da noch so auftauchen in den verbleibenden gut 54 Mio Datenzeilen .

Gibt es also einen einfachen Weg, aus einem geladenen planetfile eine bbox herauszuschneiden, auch wenn dieses aus der Zeit vor api 0.5 stammt?

Die Daten brauche ich natürlich so, dass Maperitive diese auch rendern kann. Osmosis V0.35 liest ja wohl noch api 0.5-Daten, läßt mich dann aber wohl auch auf dem alten Format sitzen - dann wäre Freund Maperitive "Neese". Außerdem schätze ich mal, dass Osmosis V0.35 auch an dem in 7) geschilderten Fehlertyp scheitert ...
Randinfo: ich arbeite mit Linux/Ubuntu.

Leicht zermürbte Grüße von
Rainer

wambacher · 2017-04-30 19:12:20

-snip-

Last edited by wambacher (2017-04-30 19:12:38)

pitscheplatsch · 2017-04-30 19:14:09

Hi,

warum nicht das full-history-dump benutzen? [1]
Unter Processing solltest du ein paar Anregungen finden.

Alternativ den OpenStreetMap History Renderer verwenden? [2]
Weiß allerdings gerade nicht, ob dieser noch nutzbar ist.
Am Projekt ist länger wohl nichts mehr passiert.

Weitere Alternative: iOSMAnalyzer, wenn du ein paar Stats über Lübeck haben möchtest [3].

Hoffe das hilft dir weiter.
Viele Grüße
Pascal

[1] http://wiki.openstreetmap.org/wiki/Planet.osm/full
[2] https://github.com/MaZderMind/osm-history-renderer
[3] https://github.com/zehpunktbarron/iOSMAnalyzer

wambacher · 2017-04-30 19:14:17

projecter63 wrote:

Gibt es also einen einfachen Weg, aus einem geladenen planetfile eine bbox herauszuschneiden, auch wenn dieses aus der Zeit vor api 0.5 stammt?

Da du das jetzt im 0.5-Format hast, nimm ein altes Osmosis: https://wiki.openstreetmap.org/wiki/Osm … .5_support

Gruss
walter

Last edited by wambacher (2017-04-30 19:15:03)

mmd · 2017-04-30 19:45:36

pitscheplatsch wrote:

warum nicht das full-history-dump benutzen? [1]

Größtes Problem dabei: im Full History Dump fehlen (ersatzlos!) alle Objektversionen, die einer Redaction zum Opfer gefallen sind. Wenn ihr viele ODbL-Ablehner hattet, kann das den Spaß mit den Daten gehörig vermiesen.

Last edited by mmd (2017-04-30 19:55:23)

pitscheplatsch · 2017-05-01 10:59:15

Hi,

mmd wrote:

pitscheplatsch wrote:
warum nicht das full-history-dump benutzen? [1]
Größtes Problem dabei: im Full History Dump fehlen (ersatzlos!) alle Objektversionen, die einer Redaction zum Opfer gefallen sind. Wenn ihr viele ODbL-Ablehner hattet, kann das den Spaß mit den Daten gehörig vermiesen.

guter Punkt, aber will man(n) diese Daten überhaupt visualisieren, die mal in OSM drin waren, und jetzt nicht mehr?
Mir persönlich wäre es in dem beschriebenen Fall vom TE nicht so wichtig.

Viele Grüße
Pascal

SammysHP · 2017-05-01 11:27:28

Aber selbstverständlich will man das! Schließlich geht es darum, den damaligen Zustand zu zeigen und dazu gehören auch inzwischen gelöschte Objekte.

pitscheplatsch · 2017-05-01 13:32:41

SammysHP wrote:

Aber selbstverständlich will man das! Schließlich geht es darum, den damaligen Zustand zu zeigen und dazu gehören auch inzwischen gelöschte Objekte.

Ist das für die erwähnte "Öffentlickeit und die Presse" wirklich wichtig? Willst du dann dem Reporter erklären, äh, sorry, wir haben die Lizenz gewechselt, daher wurden viele bereits erfasste Daten wieder gelöscht und die sind jetzt nicht mehr da oder vlt. doch?
Auch wenn dieser Fall vermutlich nicht eintrifft, weil evtl. alles dies was verloren gegangen ist, wieder neu gemappt wurde.

Wie gesagt, mMn ist dies speziell in diesem Fall hier egal.
Ansonsten stimme ich dir zu, dass für uns hier im Projekt natürlich alle Daten betrachtet werden soll(t)en.

Just my 2 Cents.

mmd · 2017-05-01 13:39:20

pitscheplatsch wrote:

Wie gesagt, mMn ist dies speziell in diesem Fall hier egal.

Ich weiß nicht genau, wie die ODbL-Ablehner Situation in Lübeck war. Im schlimmsten Fall sieht 2007 mit dem Full History File wie ein wüster Flickenteppich aus und nicht wie etwas das durch organisch gewachsenes Mappen entstanden wäre.

pitscheplatsch · 2017-05-01 13:45:06

Hi,

projecter63 wrote:

Die Daten brauche ich natürlich so, dass Maperitive diese auch rendern kann. Osmosis V0.35 liest ja wohl noch api 0.5-Daten, läßt mich dann aber wohl auch auf dem alten Format sitzen - dann wäre Freund Maperitive "Neese". Außerdem schätze ich mal, dass Osmosis V0.35 auch an dem in 7) geschilderten Fehlertyp scheitert ...

Wenn der TE wirklich mit alten Dumps und den unterschiedlichen API Versionen weiterarbeiten möchte,
sollte ihm auch dieser Link aus OSM Help weiterhelfen: "Convert XML Format: 0.5-->0.6 (osmosis)"
https://help.openstreetmap.org/question … 06-osmosis

Viele Grüße
Pascal

projecter63 · 2017-05-01 18:22:37

N'Abend,

Danke für die Hinweise; zwei Spuren werden ich aufnehmen:

1) Die aus #10 führt zu zu Osmosis V0.35 und folgender Aussage:

I used osmosis 0.35 to migrate from 0.5 to 0.6: osmosis --read-xml-0.5 enableDateParsing=no file="input_0.5.osm" --migrate --write-xml file="output_0.6.osm"
After that I was able to extract my AOI with osmosis 0.47.

(mit AOI = Area Of Interest - schätze ich). Wenn das funktioniert, wäre ich durch ...

2) Aus Interesse und weil es uns weitere Möglichkeiten hinsichtlich unseres 100. Stammtisches böte:

Wenn ich mit dem full history dump arbeiten wollte (#3, [1]), dazu die 57 GB herunterlade und unter Einsatz einer nicht unerheblichen Zeit hoher CPU-Auslastung aus dem multi-stream-file ein single-stream-file erzeuge, habe ich dann mit OSMOSIS eine reale Chance, mein AOI zu beliebigen Zeitpunkten herauszuschneiden ?? Hat das schon mal jemand erfolgreich geschafft ?? Die Aussage

Osmosis does not have explicit support for this type of file but some Osmosis operations seem to work with it.

kommt etwas "wischiwaschi" rüber ... Wenn das klappt, wäre es toll ich ich wäre dabei ...

Oder muss ich dazu am Ende Osmium bemühen, dessen umfangreiche Installation/Kompilierung sich für mich als nach Tagen zu bemessen anhört und etwas overdosed für meinen/unseren Anwendungsfall scheint.

Grüße aus Lübeck
Rainer

mmd · 2017-05-01 18:27:02

projecter63 wrote:

Wenn ich mit dem full history dump arbeiten wollte (#3, [1]), dazu die 57 GB herunterlade und unter Einsatz einer nicht unerheblichen Zeit hoher CPU-Auslastung aus dem multi-stream-file ein single-stream-file erzeuge, habe ich dann mit OSMOSIS eine reale Chance, mein AOI zu beliebigen Zeitpunkten herauszuschneiden ??

Dieses ganze multi-stream -> single-stream Tamtam kann man sich m.E. komplett schenken, wenn man mit PBF arbeitet. Generell mein Tipp zum Ausschneiden von Full History Files wäre das Osmium Tool: http://osmcode.org/osmium-tool/manual.h … tory-files. Funktioniert wie auf der Seite beschrieben und ist sehr flott.

projecter63 wrote:

Oder muss ich dazu am Ende Osmium bemühen, dessen umfangreiche Installation/Kompilierung sich für mich als nach Tagen zu bemessen anhört und etwas overdosed für meinen/unseren Anwendungsfall scheint.

So schlimm ist das wirklich nicht.

Last edited by mmd (2017-05-01 21:59:24)

wambacher · 2017-05-01 18:34:51

projecter63 wrote:

N'Abend,
Danke für die Hinweise; zwei Spuren werden ich aufnehmen:

Und warum nicht #4? Ein Test damit sollte am einfachsten und schnellsten sein.

Gruss
walter

Last edited by wambacher (2017-05-01 18:35:31)

projecter63 · 2017-05-01 19:30:21

N'Abend,

Und warum nicht #4? ...

Dass Osmosis 0.35 die api 0.5-Daten lesen kann, war mir schon eingangs klar (hab ich ja in #1 geschrieben), dass es die [file="output_0.6.osm"]-Option dort gibt, ist mir neu, habe ich erst in #10 kapiert und dann in #11 verschriftlicht.

Aber natürlich auch gern ein "Danke" an wambacher - ich hab's nur in #4 noch nicht geblickt ...

Grüße Rainer

projecter63 · 2017-05-03 23:45:22

N'Abend,

wie kann man denn am besten zwei Osmosis-Versionen (eine neuere 0.40 und die alte 0.35) parallel auf einem Rechner betreiben, ohne diese wechselseitig immer wieder neu zu installieren ?? Gibt's dazu ein howto?
(Ich nutze Linux Mint 17.3 Rosa.)

N8 Rainer

wambacher · 2017-05-04 00:01:06

ich mach das so:

Zuerst lege ich die Versionen in unterschiedliche Verzeichnisse. Und dann suche ich mir das passende raus:

#!/bin/bash
#
OSMOSIS=/opt/install/osm/osmosis/osmosis_0.45/bin/osmosis
...
$OSMOSIS \
          --read-replication-interval \
          --simc \
          --lpc interval=300 \
          --write-xml-change test.osc

Die Optionen für osmosis musst du natürlich anpassen.

Gruss
walter

Last edited by wambacher (2017-05-04 00:01:51)

projecter63 · 2017-05-04 20:14:38

jau, funktioniert

Danke Rainer

Announcement

#1 2017-04-30 18:53:39

Arbeit mit planetfiles aus der Zeit vor der API 0.6

#2 2017-04-30 19:12:20

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#3 2017-04-30 19:14:09

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#4 2017-04-30 19:14:17

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#5 2017-04-30 19:45:36

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#6 2017-05-01 10:59:15

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#7 2017-05-01 11:27:28

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#8 2017-05-01 13:32:41

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#9 2017-05-01 13:39:20

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#10 2017-05-01 13:45:06

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#11 2017-05-01 18:22:37

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#12 2017-05-01 18:27:02

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#13 2017-05-01 18:34:51

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#14 2017-05-01 19:30:21

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#15 2017-05-03 23:45:22

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#16 2017-05-04 00:01:06

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

#17 2017-05-04 20:14:38

Re: Arbeit mit planetfiles aus der Zeit vor der API 0.6

Board footer