Der Fehler kommt, wenn die o5m-Datei 8.683.009.021 Bytes groß ist.
pbftoosm (ebenfalls eben selbst erstellt) gibt den gleichen Fehler aus. Zusätzlich noch:
Number of bytes read: 4557549184
Next bytes to parse: 78 9C AC BD 59 8F 24 49
Danke.
Damit sind wir sehr nahe an der 2^32-Bytes-Grenze dran… Ich kümmer mich drum, sobald ich eine 64-Bit-Version von Windows in den Fingern habe.
Hallo nochmal,
heute habe ich endlich Zugriff auf einen PC mit 64-Bit-Windows (Win7 Pro). Die Europa-Datei vom 07.06.2011 hatte ich mit aufgehoben und grad einen Test damit gefahren:
osmconvert europe.osm.pbf --out-o5m >europe.o5m
Lief ohne Probleme durch. Die Ausgabedatei ist exakt so groß wie die, die ich unter Linux (32 Bit) erstellt habe.
Woran könnte es in deinem Fall liegen? Doch ein Problem mit Dateien, die größer als 4 GB sind? Hast du die Ausgabedatei versehentlich auf eine FAT-Partition geschrieben? Bin da grad ratlos…
EDIT:
Welche Windows-Version genau verwendest du? Vielleicht klappts nur mit diesem speziellen Typ nicht. Dann werde ich da noch einmal nachforschen…
Nö…alles ntfs…ich arbeite normalerweise mit dem ganzen Planeten (aktualisieren mit osmosis und dann aufteilen mit dem splitter) und bisher noch keine Probleme gehabt.
EDIT: Habs eben nochmal mit der 0.1K probiert…selbes verhalten.
Hallo Henning, hab ein mögliches Problem entdeckt: lseek()/lseek64(). Das erklärt zwar nicht, warum es bei meinem Win7/64-Test geklappt hat und bei deinem nicht, aber vielleicht löst es das Problem: Version 0.1L
Schöne Grüße
Markus
Hallo, ich hab eben mal die Version 0.1N probiert mit selbigem Ergebnis. Soll ich dir mal meine exe zuschicken oder du lässt mir deine zukommen? Oder kann es daran nicht liegen?
Da bleibt dann vielleicht wirklich nur noch der Weg, direkt auf deinem Windows zu debuggen. Als Exe haben wir vermutlich eh immer die gleiche genommen, nämlich den Download von hier:
http://wiki.openstreetmap.org/wiki/DE:Osmfilter#Download
Du hast aber sowieso einen Weg, der bei dir ohne Probleme funktioniert: Osmosis / Splitter. Deswegen weiß ich nicht, ob sich der Aufwand dann lohnen wird…
Wie kann ich das debuggen? Der Zeitgewinn wäre ja schon beachtlich im Vergleich zu osmosis.
Hallo
darf ich mal naive dazwischenfragen? Ich kenne mich mit den OSM Strukturen nicht aus, aber ist die Aufgabe aus einem OSM File alle nodes
zB:
…
und …
rauszufiltern? Welche Zeiten sind da zu erwarten? Ich habe das mal für “rheinland-pfalz.osm” (724.671KB) versucht, da ich in einem anderen Zusammenhang mit xml teste. Ich extrahiere das in einen File mit 7,3 MB in ca. 30 sek.
Müssen da auch noch die nodes z.B: rausgezogen werden?
Frage nur aus Interesse um die Strukturen kennen zu lernen.
MfG
Achim
Welche Referens OSM zum testen?
Wie groß ist das Ergebnisfile?
Ich habe das mal mit BW getestet und auch die nodes extrahiert
Relationen:1994
Ways:5838
Node:10847817
Ergenisfile 1,6 GB ca. 4 min
−
Hi Achim,
eine osm-Datei besteht im wesentlichen nur aus
nodes
ways
relations
denn
osmfilter --drop-nodes --drop-ways --drop-relations mittelfranken.osm > mittelfranken_no_nodes_no_ways_no_relations.osm
cat mittelfranken_no_nodes_no_ways_no_relations.osm
<?xml version='1.0' encoding='UTF-8'?>
Mein Mittelfranken ist nicht ganz so groß wie Dein Rheinland-Pfalz,
471M mittelfranken.osm
nur nodes:
osmfilter --drop-ways --drop-relations mittelfranken.osm > mittelfranken_no_ways_no_relations.osm
333M mittelfranken_no_ways_no_relations.osm
keine nodes:
osmfilter --drop-nodes mittelfranken.osm > mittelfranken_no_nodes.osm
139M mittelfranken_no_nodes.osm
Ciao,
Frank
Was die Zeitfrage angeht:
time osmfilter --drop-nodes mittelfranken.osm > mittelfranken_no_nodes.osm
real 0m41.712s
user 0m19.617s
sys 0m2.112s
Das ist aber ein kleines netbook (mit verschlüsselter Platte), ein normaler Desktop-PC dürfte wohl doppelt/dreifach so schnell sein 
Ciao,
Frank
Ups, ich seh grad, der Wert bei “generator” ist falsch, ich hätte da beim Kopieren des Quellcodes aufpassen sollen. 
Werd das korrigieren.
Läuft wahrscheinlich viel schneller, wenn die Eingangsdatei nicht das Format .osm sondern .o5m hat.
Oder - wenn man die Datei nur als .pbf hat, dann entsprechend mit
osmconvert mittelfranken.pbf --drop-nodes >mittelfranken_no_nodes.osm
Hi Markus,
Ja, tut es
time osmfilter --drop-nodes mittelfranken.o5m > mittelfranken_no_nodes.osm
real 0m9.359s
user 0m6.444s
sys 0m1.232s
Ist nicht viel um (im Vergleich zum o5m):
time osmconvert mittelfranken.osm.pbf --drop-nodes > mittelfranken_no_nodes.osm
real 0m11.660s
user 0m6.528s
sys 0m0.932s
Ich bin davon ausgegangen, dass Achim kein rheinland-pfalz.osm.pbf (oder rheinland-pfalz.o5m) vorliegt, da er von einem “rheinland-pfalz.osm” schrieb.
Ciao,
Frank
Ich glaub, diese Frage hab ich übersehen…
Antwort: Ja. Die Ways enthalten keinerlei Koordinaten, das heißt, ein Way ist er dann komplett definiert, wenn du auch alle zugehörigen Nodes in der Datei hast. Die üblichen Filterprogramme sorgen dafür, dass zu jedem Way, den du extrahierst, auch alle Knoten mit eingeschlossen werden (das geht natürlich nicht, wenn du pauschal alle Knoten ausschließt, etwa mit “–drop-nodes”).
Relationen können andere Relationen, Ways und auch Nodes enthalten; hier sind die Abhängigkeiten also komplizierter. Aber auch hier kümmern sich die Filterprogramme darum, dass die jeweils untergeordneten Objekte auch mit in der Zieldatei sind.
Mein Gedanke war eher der, dass Achim, wenn er vor hat, mehrfach zu filtern, die .osm-Datei erstmal umwandeln könnte in ein Format, dass dazu besser geeignet ist. Ansonsten bringt das Umwandeln natürlich nichts, da hast du Recht. Grad, wenn man sich in die Dateistruktur reindenken will, ist .osm (XML) sowieso unschlagbar, weil man es direkt im Editor lesen kann.
Hallo
vielen Dank für die Infos! Zum Hintergrund: Ich beschäftige mich derzeit mit der Verarbeitung von XML Daten auf einem anderen Gebiet wie OSM. Ich erstelle dazu ein Programm in C# bzw. XML transformiert mit XSL. Ich bin dann auf diesen Thread gestossen und habe dazu die “OSM” Daten als Testdaten benutzt…
Sobald man die GANZEN Daten in den Speicher bekommt ist da ja alles kein grosses Problem. Aufwändiger wird es erst wenn man keine Grössenbeschränkung voraussetzt. Bei meinem Testfall mit Rheinland-pfalz.osm hat das mit den Grenzen ganz gut geklappt. Der Ergebnisfile ist in Maperitive lesbar und darstellbar. Ich habe jedoch ALLE nodes gezogen und nur die Relationen und Ways mit “”.
Ich habe das dann auch mit Baden-Württemberg versucht, das ist aber dann nicht mehr kontollierbar (für mich) da es nicht in Maperitive wegen der Größe geladen werden kann.
Das Rausfilten von zB: Restaurants und erstellen einer OpenenLayer gestützten HTML Datei ist nach dem Filtern mit XSLT auch kein großes Problem…
Grüsse und nochmals Danke
Achim
Hallo Achim,
also so ganz verstanden hab’s ich jetzt nicht, was Du da machst 
Rheinland-Pfalz hab’ ich nicht zur Hand, aber Baden-Wuerttemberg schon
Wenn ich nur die Grenzen (mit den dazu benötigten nodes) + zusätzlich alle Restaurants haben will, geh’ ich so vor:
osmconvert baden-wuerttemberg.osm.pbf --out-o5m > baden-wuerttemberg.o5m
time osmfilter baden-wuerttemberg.o5m --keep=“admin_level= amenity=restaurant” > baden-wuerttemberg_boundaries_restaurant.osm
real 0m39.426s
user 0m20.913s
sys 0m2.340s
Und das Ergebnis ist auch nicht so groß:
34M baden-wuerttemberg_boundaries_restaurant.osm
Ciao,
Frank
Hallo Frank,
ich glaube nicht das er das Ziel hat perfekte Daten aus den OSM Daten zu ziehen. Dafür könnte er nämlich die von dir vorgeschlagene Commandline nutzen.
Es geht ihm vielmehr darum mit XML Daten zu experimentieren. Dafür hat er ein eigenes Programm in C# geschrieben und wollte jetzt einen Benchmarktest gegen andere leistungsfähige Programme starten. Dabei ist er auf OSM gestoßen und hat sich dann damit befasst.
Er schreibt weiter so lange man die ganze Datei in den Speicher schiebt ist die Sache trivial. Erst wenn man mit unbegrenzten Größen operiert also Europa oder Plante vielleicht, dann wird die Sache komplex. In seiner Konfiguration kann er beispielsweise RP noch in den Speicher einlesen, aber BW schon nicht mehr. Oder das war nur die Qualitätskontrolle in Maperitive nach der Filterung.
Genau diese Qualitätskontrolle steht ja bei Osmconvert und o5mfilter noch aus.
Hallo
@viw genauso ist es! Ich habe “ohne” Logik sämliche node’s gezogen und nur die Ways und Relationen gefiltert, deshalb auch die langen Laufzeiten. Ich gehe von beliebig großen Datensourcen aus. Leider ist das Ergebnis nicht mehr so leicht überprüfbar, da die Ergebnisdateien zu groß für Standardtools sind. Da war mir das
mit Rheinland-Pfalz gerade recht (@Kellerma…ich habe da ALLE Nod’s gezogen). BW war aber dann für Maperitive zu groß um den korrekten XML Aufbau zu überprüfen. Das hat aber mit dem eigentlichen Thema nichts mehr zu tun. Mir geht es nicht darum die vorhandenen Tools zu verwenden, wie @view richtig bemerkt hat. Ich arbeite mich in die XML-Verarbeitung mit C# ein und habe dazu die OSM-Daten als Testdaten benutzt, weiter nichts.
Ich habe das mal mit BW getestet und auch die nodes extrahiert
Relationen:1994
Ways:5838
Node:10847817
Ergenisfile 1,6 GB ca. 4 min
Die Frage ist nicht nur die Laufzeit sondern welche Logik dahinter ist und wieviele Knoten gezogen werden! Ich habe da alle “node” ohne Logik gezogen und nur die Ways und Relationen gefiltert (einfache Logik). Die Nodes in Abhängigkeit von den Relationen und ways ist bei der sequentiellen Verarbeitung schon mehr Aufwand! Mein Problem ist eben nur: Wie kann ich diesen 1,6 GB File mit einem externen Tool prüfen? Da war Maperitive sehr gut geignet,…aber eben nur bis zu eine bestimmten Filegröße…schade…
In diesem Sinne
Achim
Hi,
ich dacht nur, da Du auch von OpenLayers sprachst.
Fuer die xml-Validitaet gibt es xml-parser resp. Validatoren und dass wie Sand am Meer.
Ob jetzt Maperitive dafuer besonders geeignet ist, entzieht sich meiner Kenntnis.
Da properitaer flog das Teil ziemlich schnell von meiner Platte.
Apropos FOSS, osmfilter (und auch osmconvert) sind OpenSource umd daher kannst Du dir genau anschauen, wie es Markus gemacht hat 
Ciao,
Frank
Hi @Frank
um das Thema in meine Richtung in diesem Thread abzuschließen und zur Ergänzung. Maperitive zeigt eben die Bezirke etc. und man kann schnell sehen ob der Filter prinzipiell funktioniert hat. Es geht nicht darum ob die XML Struktur “richtig” ist, da gibt es Validatoren wie Sand am mehr. Wie du richtig festgestellt hast.
OpenLayer kommt bei mir zum “grafischen” testen der POI’s zum Einsatz. Dein obiges Beispiel mit den Restaurants habe ich auch mal auf BW angewendet und bekomme eine ca. 5MB OSM Datei. Diese bereite ich mit einer XSLT Transformation in eine HTML Datei auf. Die Restaurants werden dann mit Hilfe von OpenLayer angezeigt und darunter die Restaurantinformation mit Link auf die Homepage. Die HTM Datei hat dann noch 1,5MB.
Vergleichbar mit einer Messwertreihe die man grafisch in einem X-Y Chart sehr schnell bewerten kann…
In diesem Sinne
Achim
Ps.: Nochmal Sorry, dass das vom Thread-Thema abweicht