Wegelängen (highway=...) in DE

Ich reserviere mir für heute abend mal folgende Korrekturen:
residental->residential (Hier kann ich nur eine Relation in Russland finden?)
cicleway->cycleway DONE
Fußweg->footway (overpass API kommt mit Umlaut nicht zurecht?)
grade5->track+tracktype=grade5 DONE
grade3->track+tracktype=grade3 DONE
grade1->track+tracktype=grade1 DONE
abendoned->abandoned DONE

Nein wichtig ist es nicht. Für mich ist nur interressant ob ein Programm schneller bestimmte Aufgaben erledigen kann als andere. Und da osmconvert von seinem Autor auf Schnelligkeit getrimmt wurde, hat mich das Ergebnis sehr verwundert. Bei mir dauert ein Umwandeln von europa mit osmconvert nach o5m knapp 6 Minuten.
Ein Umwandeln in XML ist aber sehr viel zeitaufwendiger. Weil viel mehr Daten erzeugt werden müssen.

Naja, von einem Vergleich kann man da nicht wirklich sprechen:

  • Osmium (ist natürlich auch von Haus aus flott) wurde auf deinem PC für 64 Bit übersetzt und ist deswegen auf diesen optimiert.

  • Von osmconvert nimmst du eine nicht optimierte Version. Noch dazu nimmst du die 32-Bit-version und lässt sie auf einem 64-Bit-System laufen. Weiter hängst du hinten einen Packer an, der für den Müll packt und nochmal einiges an Zeit frisst.

  • Im Fall von Osmosis und osmconvert erzeugst du (für den Mülleimer) zig GB große XML-Dateien während du bei Osmium praktisch nur liest und zählst.

P.S.:
Eigentlich gings hier um die Wegestatistik, deswegen dazu auch kurz ein Satz. :slight_smile:
Ich find sie sehr interessant! Es ist auch ein typisches Beispiel dafür, wofür sich Osmium sehr gut eignet, weil man dort bausteinartig selbst Analysetools basteln kann.

So direkt vergleichbar ist das zwischen osmconvert und osmium nicht!
Die 64 Bit-Version von osmconvert ist etwa doppelt so schnell und dann wird das noch an gzip weitergereicht war ja auch Zeit frist!

Mir persönlich sind solche Zeitbereiche fast egal ob 5 min oder 10 min.
Was anders ist wenn osmsis 1,5 - 3h an einem Ausschnitt der europe rumrödelt und noch nicht mal pipe was bringt das mehere Auschnitt geleichzeitig fertig werden sollen (jedenfalls auf meinem Win7 ! - soll angeblich nur 30% länger dafür viele Auschnitte - nö 4 mal solang und immer noch net fertig!=abbruch)

Genau daran liegts. Ich hab grad mal selber getestet - bin ja neugierig. :slight_smile:
Verwendet habe ich einen 64-Bit-Linux-Rechner, das Programm habe ich mit der üblichen Optimierung übersetzt (Option “-O3”).


$ time ./osmconvert germany.pbf --out-osm >/dev/null

real    1m39.356s

Ist gar nicht mal so langsam, trotz dass einige GB XML-Code generiert werden. Es gibt übrigens auch die Option “–out-none”, dann werden gar keine Daten geschrieben und man spart sich “/dev/null”. Das wäre aber ein unfairer Vorteil für osmconvert, denn die Osmium-Anwendung macht ja etwas mit den gelesenen Daten.

Realistischer ist ein Vergleich mit der osmconvert-Statistikfunktion, denn die tut auch nicht viel anderes als die Osmium-Anwendung, nämlich alle Daten zu lesen und nach verschiedenen Kriterien auszuwerten.


$ time ./osmconvert germany.pbf --out-statistics
timestamp min: 2005-07-05T02:14:17Z
timestamp max: 2011-11-21T19:59:55Z
lon min: -20.0712330
lon max: 25.2241302
lat min: 43.4945365
lat max: 60.2200233
nodes: 86720924
ways: 12750288
relations: 199905
node id min: 1
node id max: 1511888560
way id min: 92
way id max: 137876472
relation id min: 330
relation id max: 1857338

real    0m23.058s

Gehen wir noch einen Schritt weiter, denn intern gepackte .pbf-Dateien sind nicht wirklich geeignet für solche Auswertungen. Sinnvollerweise würde man eine solche gepackte PBF-Datei in eine ungepackte umwandeln oder das in diesem Fall platzsparendere Format o5m verwenden. Also, erstmal ein passenderes Format wählen:


$ time ./osmconvert germany.pbf -o=germany.o5m

real    0m43.959s

Und jetzt das Ganze nochmal laufen lassen:


$ time ./osmconvert germany.o5m --out-statistics
timestamp min: 2005-07-05T02:14:17Z
timestamp max: 2011-11-21T19:59:55Z
lon min: -20.0712330
lon max: 25.2241302
lat min: 43.4945365
lat max: 60.2200233
nodes: 86720924
ways: 12750288
relations: 199905
node id min: 1
node id max: 1511888560
way id min: 92
way id max: 137876472
relation id min: 330
relation id max: 1857338

real    0m13.700s

So, jetzt ist es aber wirklich schnell. :slight_smile:

Naja, eher ein Vergleich Äpfel mit Aprikosen :wink:

Wenn, dann müste man zuminderst eine Ausgabe generieren, die der Intention der Ursprungsaufgabe näher kommt, z. B.


osmcovert mittelfranken.osm.pbf --out-o5m > mittelfranken.o5m
osmfilter mittelfranken.o5m --keep="highway" --drop-nodes --drop-relations | grep "k=\"highway\"" | sed 's/^[ \t]*<tag k="highway" v="//;s/".*//' | sort -n | uniq -c | sort -n > alle_strassen.txt

Dann kann man zumiderst mit der Ausgabe etwas anfangen, sprich nach Fehler/Auffälligkeiten suchen.

Einverstanden. :slight_smile:
Ich versuchs mal Apfel-intern, sagen wir, es ist dann ein Vergleich zwischen “Golden Delicious” und “Granny Smith”:


$ time ./osmfilter germany.o5m --drop-nodes --drop-relations --out-count=highway
    1426976    track
    1367527    residential
     693176    service
     615269    footway
     398333    path
     238062    unclassified
     192312    secondary
     175365    tertiary
      88747    cycleway
      83890    steps
      82573    primary
(...)
          1    traboule
          1    track and path
          1    track; cycleway
          1    track; disused
          1    track; footway; track
          1    track;path
          1    track;service
          1    tram
          1    weighing_machine

real    0m11.254s

Der einzige Unterschied, der jetzt noch bleibt, ist die Längenberechnung. Die kostet Rechenzeit - je nachdem, wie genau man sie ausführt (mit Berücksichtigung der Erdkrümmung oder ohne, als Näherung oder exakt, usw.). Allerdings hält sich diese Rechenzeit bei weniger als 13 Mio. ways auch in Grenzen.

Aber wir sollten besser den Obstladen wieder beiseite räumen und Platz für die Diskussion über die Weglängen-Statistik lassen. :wink:
Vielleicht kann man diese Statistik für regionale Vollständigkeitsuntersuchungen verwenden?

Und zum Thema Osmium: Ich halte es für einen genialen Baukasten, aus dem man sich relativ leicht genau das bauen kann, was man braucht. Osmium ist bezüglich der Geschwindigkeit sicher nicht optimal, braucht es aber auch nicht sein, denn der Schwerpunkt liegt ganz woanders.

Eigentlich schon. Allerdings ist bei mir schon beim Apache kaputtes UTF8 angekommen:
[22/Nov/2011:15:27:42 +0100] query string: /api/xapi?[highway=Fu%E2%96%80weg], user agent: Wget/1.12 (cygwin)
[22/Nov/2011:15:29:23 +0100] query string: /api/xapi?
[highway=Fu%E2%94%9C%C6%92weg], user agent: Wget/1.12 (cygwin)

Das müsste eigentlich
/api/xapi?*[highway=Fu%C3%9Fweg]
heißen. Keine Ahnung, was da bei Cygwin passiert. Da die obigen gültige (aber eben in UTF8 anders belegte) Zeichenketten sind, kann ich das auf Server-Seite auch nicht mehr korrigieren.

spricht hier jemand fliessend html? Ich bräuchte eine Seite in 3 Bausteinen.

Baustein 1
-Überschrift: OSM Highway Length in country/region

  • irgendwie noch geschickt “in km”
  • Tabellekopf mit den Spalten “Date” sowie genau andersrum (von hinten nach vorne) services, tertiary_link, platform, secondary_link, raceway, primary_link, trunk_link, steps, construction, proposed, bridleway, pedestrian, motorway_link, trunk, road, living_street, motorway, cycleway, primary, footway, service, secondary, path, tertiary, unclassified, residential, track
    ^^ist vielleicht etwas viel. Ich würd vielleicht die *-link, platform und raceway weglassen wenns blöd aussieht

Baustein 2

  • Den String, den ich unter den Baustein 1 drunterschreiben muss, wenn ich die aktuellen (monatlichen) Werte anfügen will

Baustein 3

  • den Abschluss der html Seite

Ich will es dann so automatisieren, dass
1.) Berechnung → Baustein 1 + Baustein 2 + Baustein 3 → upload als country.html
2.) Baustein 1 neu = Baustein 1 alt + Baustein 2

Ganz OT:

Ah, Debian 6 mit fehlenden Kernelupdates :wink:

Ich hatte da mal ein einschneidendes Erlebnis mit Kernel-Updates :wink:

Mein letzter Post hat sich erledigt. Ich habs selber hinbekommen. So in etwa soll es später aussehen.
http://length.osm4people.org/length.html

Wenn jemand ein Verbesserungsvorschlag hat, freue ich mich auf diesen Zusammen mit den Umsetzungshinweisen :wink:

Mir gefällt die Idee. Wie ist das geplant? Je Monat eine Zeile, so dass man die Entwicklung sehen kann?
Später lassen sich daraus Grafiken machen, aber das wär Fleißarbeit.

Was mir grad noch aufgefallen ist: die Zahlen würd ich rechtsbündig schreiben. Sind aber noch Ersatzwerte, oder (überall “704.892”)?
Dass sie eine Tausendertrennung haben, find ich gut.

Die Namen auch nicht?

Wäre auszuprobieren :wink:

Gruß,
ajoessen

Hey vielen Dank erstmal Suncobalt :slight_smile: Jemand anderes war auch schon so nett die Auswertung für Belgien zu machen, die mich interessiert hat. Das ist eigentlich eine nette Kennzahl, wenn ich es auch nicht einfach darauf runterbrechen würde.

Beim ersten Versuch hab ich das “ß” ganz normal in den Command eingegeben, beim zweiten Versuch händisch in “ß” gewandelt.
Vielleicht spielt auch noch 'ne Rolle, dass Win-CMD standardmäßig CP437 und nicht iso nutzt.

ja, für alle Länder, die bei odbl.de sind (nicht die specials) UND die nicht erst mit einem Polygon zurecht geschnitten werden müssen, soll es Daten für je Nov 2006, 2007, 2008, 2009, 2010 und ab Nov 2011 dann monatlich eine neue Zeile unten dran geben. Das wären nach momentanen Stand
africa.osm.pbf canary_islands.osm.pbf france.osm.pbf ireland.osm.pbf netherlands.osm.pbf slovakia.osm.pbf
albania.osm.pbf china.osm.pbf gaza.osm.pbf israel_and_palestine.osm.pbf norway.osm.pbf slovenia.osm.pbf
asia.osm.pbf croatia.osm.pbf germany.osm.pbf italy.osm.pbf philippines.osm.pbf south-america.osm.pbf
australia-oceania.osm.pbf czech_republic.osm.pbf great_britain.osm.pbf kosovo.osm.pbf spain.osm.pbf
austria.osm.pbf denmark.osm.pbf greece.osm.pbf latvia.osm.pbf planet-latest.osm.pbf sweden.osm.pbf
belarus.osm.pbf estonia.osm.pbf haiti-and-domrep.osm.pbf lithuania.osm.pbf poland.osm.pbf switzerland.osm.pbf
belgium.osm.pbf ethiopia.osm.pbf hungary.osm.pbf luxembourg.osm.pbf portugal.osm.pbf turkey.osm.pbf
europe.osm.pbf iceland.osm.pbf monaco.osm.pbf romania.osm.pbf turkmenistan.osm.pbf
bosnia-herzegovina.osm.pbf faroe_islands.osm.pbf india.osm.pbf montenegro.osm.pbf russia-european-part.osm.pbf ukraine.osm.pbf
bulgaria.osm.pbf finland.osm.pbf iraq.osm.pbf morocco.osm.pbf serbia.osm.pbf

Ja, die Werte sind Dummy-Werte um den html String darzustellen, zu dem die Werte hinzugefügt werden sollen. Mit dem Rechtsbündig muss ich mal schauen. Ich sehe gerade, dass das Total noch fehlt.

So, habs fertig. Wird spanned, was alles wegfällt
http://length.osm4people.org/germany.html

Ist in etwas so wie ich es erwartet habe. Primary und Motorway ändern sich kaum noch in DE, Zuwächse gibt es vor allem bei Track, Path und Services und ein wenig bei Residential

Eine index.html hab ich noch nicht, aber directory browsing ist aktiviert
http://length.osm4people.org/

Interessant finde ich birdelway auf http://length.osm4people.org/china.html : die Länge ist fallend.

Nun in einigen Regionen wird bridleway gerne als Zufahrtweg zu Bauernhöfen verwendet, obwohl ich da eher track oder service verwenden würde. Vielecht sind es entsprechende Korrekturen.