ich denke es geht um Schreibfehler und Statistik.
Und neuen Trends, so gibt es jetzt neben proposed noch pre-proposed (mit und ohne Strich).
Chris
Prima, dann trage ich hier demnächst auch ein paar highway=dreamed_of_by_local_politicians bzw. highway=wanted_by_city_council_but_opposed_by_neighbouring_city usw. ein. Natürlich mit wanted_by_city_council_but_opposed_by_neighbouring_city=motorway_link etc.
Na wenigstens tauchen die dann nicht in der Mapnik-Karte auf 
Gruß,
ajoessen
ich versuche eine von !i! gewünschte Seite mit OSM Stats zu erstellen, also Wegelängen über die Zeit pro Land. Ohne Hilfe wird das mangels Programmierkenntnissen wohl ein ziemliches Gefummel…aber schauen wir mal.
Die Stats oben fand ich persönlich interessant…nur mal so zum anschauen… und wenn man will, kann man ja mit dem Tool seiner Wahl filtern und die Fehler beheben.
Interessant ist auch die Geschwindigkeit bzw der extreme Unterschied.
germany.osm.pbf mit osmosis in xml wandeln und in /dev/null schreiben, dauert:
real 15m15.705s
user 15m34.858s
sys 0m5.300s
etwas ähnliches mal mit osmconvert
real 9m7.306s
user 8m57.678s
sys 0m13.905s
Die komplette Berechnung mit dem osmium Framework
real 3m31.396s
user 3m29.937s
sys 0m1.448s
Das klingt spannend. Hast du mit allen drei Programmen das gleiche gemacht? Welches Betriebssystem war im Einsatz? Wie waren die Aufrufe? Hast du irgendwas selbst kompiliert?
Fürs erste sieht es nach Linux aus.
nette Sachen dabei:
highway=path;track;path;track;track;track
highway=not exist
highway=weighing_machine
highway=not_really_a_path
Ach so, also Statistik mit dem Nebeneffekt, dass man ungewöhnliche Werte sehen/finden kann.
Wer will kann die dann gezielt suchen und beheben, soweit das ohne Ortskenntnis (z.B. Tippfehler) oder mit Luftbild möglich ist.
PS: Danke, dass die Special Request Regions neu gerechnet wurden.
Edbert (EvanE)
Selber kompiliert ist osmium, das gibts nicht fertig. Aber mehr als make eintippen, muss man ja nicht 
BS
Linux suncobalt 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux
osmosis Aufruf
osmosis --read-pbf file=/home/wicking/osm/germany.osm.pbf --write-xml file=/dev/null
osmconvert (da hab ich auf die schnelle nicht direkt in /dev/null schreiben könnten)
./osmconvert32 /home/wicking/osm/germany.osm.pbf --out-osm | gzip -1 >/dev/null
osmium, das oben war eine echte Berechnung (die Weglängen)
~/osmium/examples/osmium_road_length ~/osmlength/pbffiles/germany.osm.pbf
eine Konvertierung dauert länger (kann auch an den unterschiedlichen HDDs liegen). Wenns wichtig ist, kann ich das mal komplett gleich durchlaufen lassen
@Edbert
Das Aktualisieren hat Wicking gemacht. Ist mir gar nicht aufgefallen
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.
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.
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.
Naja, eher ein Vergleich Äpfel mit Aprikosen
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.
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.
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
Ich hatte da mal ein einschneidendes Erlebnis mit Kernel-Updates
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
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.