Grenzen aus osmfilter

Wenn es DIr wichtig ist, pbftoosm, o5mfilter, osmfilter oder andere moderne Digne zu nutzen, habe ich keine Antwort. Aber mit einem halbwegs aktuellen Osmosis geht das direkt vom PBF so:

osmosis␣--read-pbf␣quelldatei.osm.pbf␣--tf␣accept-relations␣boundary=administrative␣--used-way␣--used-node␣--wx␣relation-boundaries.osm
osmosis␣--read-pbf␣quelldatei.osm.pbf␣--tf␣accept-ways␣boundary=administrative␣--used-node␣--wx␣relation-ways.osm

Damit hast Du zwei Dateien, eine mit den Relationen (und allem, was dazugehoert) und eine mit den Ways. Du kannst auch beides in einem Schritt erzeugen lassen (Stichwort --tee). Viele Ways werden in beiden Dateien enthalten sein; Du kannst beide Dateien wieder zu einer zusammensetzen lassen und dabei Dubletten entfernen (Stichwort --merge). Das allerdings muss tatsaechlich in einem separaten Schritt erzeugen, denn das Wiederzusammenfuegen von zwei mit --tee gesplitteten Streams sorgt bei Osmosis fuer ein Problem, da haengt es sich auf.

Bye
Frederik

Hallo Frederik,
ich wollte mal einen Vergleich machen, ob es mit osmosis oder mit obigen Tools schneller geht. Der Weg über osmosis ist mir bekannt und läuft auch, dauert halt nur etwas.

aighes wrote:

Hallo,
wie stelle ich es am geschicktesten an, alle Grenzen aus einer pbf-Datei mit osmfilter zu extrahieren.

Schritt 1 wäre mit pbftoosm ein osm-xml-File zu erzeugen

Im 2. Schritt wollte ich dann mit osmfilter filtern. Als Ergebnis brauche ich alle Relationen mit boundary=administrative und alle ways mit selbigem Tag in einer osm-xml oder pbf-Datei.

Oder wäre es effektiver das pbf in ein o5m zu wandeln und mit 05mfilter zu bearbeiten und dann wieder nach osm-xml zu konvertieren?

Hallo!

Der Standardweg wär mit dem Alleskönner Osmosis, da hat Frederik völlig recht. Über die Alternative könnte es schneller gehen, verglichen hab ich das allerdings noch nicht.

Das Einzige, wozu o5mfilter zu doof ist, ist eine PBF-Datei zu schreiben. Alles andere sollte ohne Probleme gehen. Als Eingabeformat für o5mfilter ist .osm (XML) zwar möglich, aber .o5m lässt sich viel schneller verarbeiten (auch schneller als .pbf). Mein Vorschlag wäre dieses:

osmconvert␣germany.osm.pbf␣--out-o5m␣>germany.o5m
o5mfilter␣germany.o5m␣--keep="boundary=administrative"␣>grenzen.osm

Wenn du das Filtern auf bestimmte Admin-Levels beschränken willst (ist eventuell sinnvoll), dann könnte das Filterkommando so aussehen:

o5mfilter␣germany.o5m␣--keep="all␣boundary=administrative␣admin_level=2␣=3␣=4"␣>grenzen.osm

Ich hoffe, das klappt so. Vielleicht probier ich es gleich mal selber...

Hallo Marqqs!
Behält o5mfilter mit --keep="boundary=administrative" auch die Grenzen, die nur als Relation in den Daten schlummern und die zu den Relationen gehörenden Weg? Dann werde ich das gleich mal versuchen.

aighes wrote:

Hallo Marqqs!
Behält o5mfilter mit --keep="boundary=administrative" auch die Grenzen, die nur als Relation in den Daten schlummern und die zu den Relationen gehörenden Weg? Dann werde ich das gleich mal versuchen.

Ja, tut es. Auch die Nodes, die zu diesen Wegen gehören, sind dann im Ergebnis.

Streng genommen wären im Ergebnis sogar andere Nodes, die diesen Tag selber besitzen, aber da dürfte es kaum welche geben. Wenn du aber solche Nodes ausschließen willst, kannst du die Filter für die Objekttypen gezielt vorgeben. Für Nodes also einen leeren Filter, dann sind sie nur dann im Ergebnis, wenn sie zu einem betroffenen Weg gehören.

--keep-nodes=␣--keep-ways-relations="boundary=administrative"

Meine alte Mühle hat eine ganze Weile gerechnet. Fairerweise müsstest du bei der Alternative mit o5mfilter die Zeit für die Datenumwandlung von .pbf nach .o5m hinzurechnen, denn .o5m ist bis jetzt noch ein eher wenig verwendetes Format. Außer, du willst die Basis mehrfach verwenden und nach unterschiedlichen Kriterien filtern. Hier die Ergebnisse (Ubuntu 10.04, 32 Bit, Intel Atom).

$␣time␣./osmconvert␣germany.osm.pbf␣--out-o5m␣>germany.o5m

real␣␣␣␣4m8.948s
user␣␣␣␣3m56.455s
sys␣␣␣␣0m10.353s

$␣time␣./o5mfilter␣germany.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative"␣>grenzen.osm

real␣␣␣␣2m43.116s
user␣␣␣␣2m17.365s
sys␣␣␣␣0m7.792s

Die Ergebnisdatei "grenzen.osm" ist bei mir 270.262.836 Bytes groß. Sie lässt sich mit JOSM öffnen, dauert halt ein bisschen.

Bei mir waren beide Programme nach 2min durch. Danke für deine Hilfe!

aighes wrote:

Bei mir waren beide Programme nach 2min durch. Danke für deine Hilfe!

Uff, verdammt schnell. Zeigt deutlich, dass meine alte EeeBox nicht grad ideal für solche Datenkonvertierungen geeignet ist. :-)

aighes wrote:

Bei mir waren beide Programme nach 2min durch. Danke für deine Hilfe!

Und wie sieht Osmosis im Vergleich dazu aus? Und sind die Daten vollständig? Das wären jetzt Entscheidungshilfen für andere Nutzer. Ich habe ja bereits positive Erfahrungen damit gemacht.

viw wrote:

aighes wrote:

Bei mir waren beide Programme nach 2min durch. Danke für deine Hilfe!

Und wie sieht Osmosis im Vergleich dazu aus? Und sind die Daten vollständig? Das wären jetzt Entscheidungshilfen für andere Nutzer. Ich habe ja bereits positive Erfahrungen damit gemacht.

Würde mich auch interessieren. Vollständigkeit ist letztlich ja wichtiger als Geschwindigkeit. Zwei Problempunkte:

• Osmosis: Die Option cascadingRelations=yes ist wichtig, weil sonst Unterrelationsn fehlen können.
• o5mfilter: Das Programm ist recht neu, so dass ich da lieber zweimal hinschauen würde. Bugs sind wahrscheinlicher als bei Osmosis.

Vielleicht könnte man o5mfilter mit der Option --emulate-osmosis laufen lassen und das Ergebnis dann per diff vergleichen. Mit dieser Option schreibt o5mfilter die Daten in dem Format, das auch Osmosis verwendet (Leerzeichen statt Tabs, XML-Reihenfolge innerhalb der Header-Tags usw.). Sollte es jedenfalls. :-)

Wenn ich den osmconverter auf europe.osm.pbf loslasse bekomme ich den Fehler: decompression failed: -5

Win7 64bit

Hast du eine Erklärung dafür?

Schau mal hier ganz unten: http://forum.openstreetmap.org/viewtopi … =12419&p=6

aighes wrote:

Wenn ich den osmconverter auf europe.osm.pbf loslasse bekomme ich den Fehler: decompression failed: -5
Win7 64bit

Hallo Henning,

die Fehlermeldung kommt aus zlib. Der Ausgabepuffer ist angeblich zu klein. Da er mit 32 MB dimensioniert ist, hält sich das gelesene PBF nicht an die Spezifikationen. Oder – was viel wahrscheinlicher ist: da ist ein Bug im Programm. Oder... es gibt wieder ein Problem mit der Windowsversion und der 2-GB-Grenze für Dateien. Sollte aber gefixt sein.

Kannst du bitte sagen, welche Programmversion du benutzt? Und, ist es die europe.osm.pbf-Version von heute? Ich geh der Sache dann auf den Grund.

Markus

Hallo Markus,
ich hab Version 0.1C für Windows genutzt. Das Problem hatte ich mit der europe.osm.pbf von der GeoFabrik von gestern (-5) und heute (-3).

Hallo - hab das Problem immer noch nicht erwischt.
Mit Version 0.0E unter Ubuntu (32 Bit) läuft alles glatt. Gleiches gilt für die Windows-Version unter Wine.
Ich bereite grad einen Test für 32-Bit-Windows vor. 64-Bit-Windows hab ich im Moment nicht greifbar.

Hast du eigentlich die osmconvert.exe runtergeladen oder selber mit MinGW übersetzt?

Ich hab mir die fertige exe geladen. Kann ich die 0.0E irgendwo herunterladen, dann probiere ich die nochmal aus.

EDIT: Mit der 0.1F gibts das gleiche Problem.

aighes wrote:

Ich hab mir die fertige exe geladen. Kann ich die 0.0E irgendwo herunterladen, dann probiere ich die nochmal aus.

EDIT: Mit der 0.1F gibts das gleiche Problem.

Wenns dir möglich ist, übersetz bitte mal neu mit MinGW unter Win64.
Ich hab grad unter Win32 (XP Pro) getestet, da läufts einwandfrei. Bin jetzt auf der Suche nach einer Win64-Installation. Sobald mir eine unter die Finger kommt, werd ich testen.

Ich hab eben 0.1H selber compiliert (wie hier beschrieben), der Fehler besteht weiterhin. Kann ich sonst noch etwas testen bzw. dir behilflich sein?

aighes wrote:

Ich hab eben 0.1H selber compiliert (wie hier beschrieben), der Fehler besteht weiterhin. Kann ich sonst noch etwas testen bzw. dir behilflich sein?

DANKE!
Aber ich wüsste jetzt nicht wie. :-( Außer, du willst dich wirklich in den Quellcode reinwühlen.
Vielleicht hab ich übermorgen die Gelegenheit, mit Win64 zu testen.

Interessant wäre noch zu erfahren, ob es bei pbftoosm zur gleichen Fehlermeldung kommt. Oder ob die Meldung bei ca. 2 oder 4 GB Dateiposition auftritt. Aber das ist dann schon wieder Forschungsarbeit. :-) Ich kümmer mich am besten mal um eine 64-Bit-Version.

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.

aighes wrote:

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?

aighes wrote:

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:O … r#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:
<way id="28744257" version="2" changeset="11996" uid="6269" user="Mueck" timestamp="2008-12-01T14:58:00Z">
<nd ref="292983601"/>
<nd ref="292971752"/>
<tag k="admin_level" v="10"/>
<tag k="boundary" v="administrative"/>
<tag k="name" v="Mitte"/>
<tag k="source" v="Statistikstelle Stadt Koblenz"/>
</way>
...
und ...
<relation id="1251073" version="1" changeset="6252811" uid="6270" user="mikes" timestamp="2010-11-01T09:38:24Z">
<member type="way" ref="58436410" role="outer"/>
<member type="way" ref="58436356" role="outer"/>
<member type="way" ref="58436367" role="outer"/>
<member type="way" ref="58436404" role="outer"/>
<member type="way" ref="58741496" role="outer"/>
<member type="way" ref="58741540" role="outer"/>
<tag k="admin_level" v="8"/>
<tag k="boundary" v="administrative"/>
<tag k="de:amtlicher_gemeindeschluessel" v="07340020"/>
<tag k="name" v="Hinterweidenthal"/>
<tag k="source" v="http://de.wikipedia.org/wiki/Datei:Verbandsgemeinden_in_PS.svg"/>
<tag k="type" v="multipolygon"/>
</relation>

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:<nd ref="323719360"/> 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'?>
<osm version="0.6" generator="osmconvert 1.0">
</osm>

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

kellerma wrote:

<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="osmconvert 1.0">
</osm>

Ups, ich seh grad, der Wert bei "generator" ist falsch, ich hätte da beim Kopieren des Quellcodes aufpassen sollen. :-) Werd das korrigieren.

kellerma wrote:

real 0m41.712s

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,

Marqqs wrote:

kellerma wrote:

real 0m41.712s

Läuft wahrscheinlich viel schneller, wenn die Eingangsdatei nicht das Format .osm sondern .o5m hat.

Ja, tut es
time osmfilter --drop-nodes mittelfranken.o5m > mittelfranken_no_nodes.osm

real 0m9.359s
user 0m6.444s
sys 0m1.232s

Marqqs wrote:

Oder - wenn man die Datei nur als .pbf hat, dann entsprechend mit

osmconvert␣mittelfranken.pbf␣--drop-nodes␣>mittelfranken_no_nodes.osm

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

womisa wrote:

Müssen da auch noch die nodes z.B:<nd ref="323719360"/> rausgezogen werden?
Frage nur aus Interesse um die Strukturen kennen zu lernen.

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.

kellerma wrote:

Ich bin davon ausgegangen, dass Achim kein rheinland-pfalz.osm.pbf (oder rheinland-pfalz.o5m) vorliegt, da er von einem "rheinland-pfalz.osm" schrieb.

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 "<tag k="boundary" v="administrative"/>".
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

kellerma wrote:

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

Hi Achim,

hier nochmals Zahlen von meinem kleinen netbook (1 GB RAM, 64 Bit, Debian 6):

time osmfilter --drop-ways --drop-relations baden-wuerttemberg.osm > baden-wuerttemberg_nodes.osm
Speicherzugriffsfehler

real 0m3.233s
user 0m0.000s
sys 0m0.600s

Oopsi 🙂

time osmconvert --drop-ways --drop-relations baden-wuerttemberg.osm > baden-wuerttemberg_nodes.osm

real 4m33.827s
user 2m10.724s
sys 0m19.701s

2,3G baden-wuerttemberg.osm
1,6G baden-wuerttemberg_nodes.osm

Ciao,
Frank

EDIT:
time osmfilter32 --drop-ways --drop-relations baden-wuerttemberg.osm > baden-wuerttemberg_nodes.osm

real 5m16.819s
user 2m39.970s
sys 0m18.329s

Böses, böses 64 Bit 😉

kellerma wrote:

EDIT:
time osmfilter32 --drop-ways --drop-relations baden-wuerttemberg.osm > baden-wuerttemberg_nodes.osm

real 5m16.819s
user 2m39.970s
sys 0m18.329s

Böses, böses 64 Bit 😉

So, hab mir per
gcc -m32 -o osmfilter32 osmfilter.c
'ne 32Bit-Variane selbst erzeugt, gleicher Fehler 🙁
Liegt wohl nicht am 64 Bit, eher am Debian <-> Ubuntu Unterschied.

Witzigerweise funktioniert ein "osmconvert32" aus "gcc -m32 osmconvert.c -o osmconvert32 -lz".

Ciao,
Frank

Zu den ganzen Benchmarks wäre vielleicht das hier interessant: https://days2011.scala-lang.org/sites/d … -Hundt.pdf
Insbesondere der teil mit der Optimierung des 32 Bit Java. Vielleicht ließe sich so ja auch Osmosis noch etwas kitzeln.

Schön, nur darf man nicht vergessen, dass aufgrund der Datenmenge man gewaltigen I/O hat.
Meine (verschlüsselte) Festplatte braucht schon für das Anlegen einer "leeren" 1,6 GB Datei mehr als eine Minute,

time dd if=/dev/zero of=blub bs=M count=1600
1600+0 Datensätze ein
1600+0 Datensätze aus
1677721600 Bytes (1,7 GB) kopiert, 67,2015 s, 25,0 MB/s

real 1m10.118s
user 0m0.012s
sys 0m14.729s

und "zuvor" wollen die 2,3 GB erst mal eingelesen sein.

Ciao,
Frank

kellerma wrote:

time osmfilter --drop-ways --drop-relations baden-wuerttemberg.osm > baden-wuerttemberg_nodes.osm
Speicherzugriffsfehler

Hallo Frank,
Weißt du, wo der Fehler aufgetreten ist? Kannst du eventuell mal mit dem Debugger schauen? Falls du keinen grafischen installiert hast, kann ich "nemiver" ganz besonders empfehlen.

Was mir noch eingefallen ist, vielleicht gibts immer noch Probleme mit der 4-GB-Grenze... Magst du mal eine Änderung versuchen?

Von:

#if␣__WIN32__
#define␣NL␣"\r\n"␣␣//␣use␣CR/LF␣as␣new-line␣sequence
#define␣off_t␣off64_t
#define␣lseek␣lseek64
#else
#define␣NL␣"\n"␣␣//␣use␣LF␣as␣new-line␣sequence
#define␣O_BINARY␣0
#endif

nach:

#define␣off_t␣off64_t
#define␣lseek␣lseek64
#if␣__WIN32__
#define␣NL␣"\r\n"␣␣//␣use␣CR/LF␣as␣new-line␣sequence
#else
#define␣NL␣"\n"␣␣//␣use␣LF␣as␣new-line␣sequence
#define␣O_BINARY␣0
#endif

-

Hallo Markus,

ulimit -c unlimited

gcc osmfilter.c -o osmfilter_debug -g -m32

./osmfilter_debug --drop-ways --drop-relations baden-wuerttemberg.osm > baden-wuerttemberg_nodes.osm
Speicherzugriffsfehler (Speicherabzug geschrieben)

gdb osmfilter_debug core
<snip>
Reading symbols from /home/user/tmp/osmfilter_debug...done.

warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
Reading symbols from /lib32/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib32/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./osmfilter_debug --drop-ways --drop-relations baden-wuerttemberg.osm'.
Program terminated with signal 11, Segmentation fault.

1. 0 0x08050ad7 in oo__findbb () at osmfilter.c:4000
   

4000 c= *bufsp;
(gdb) bt

1. 0 0x08050ad7 in oo__findbb () at osmfilter.c:4000
   
2. 1 0x080514ce in oo_main () at osmfilter.c:4340
   
3. 2 0x08054402 in main (argc=0, argv=0xffe26250) at osmfilter.c:5180
   

(gdb)

Ciao,
Frank

kellerma wrote:

1. 0 0x08050ad7 in oo__findbb () at osmfilter.c:4000
   

4000 c= *bufsp;

Sorry, mein Fehler.
Ich hatte die Erkennung für Bounding Boxes verbessert und einen Fehler eingebaut. :-( Korrigiert in Version 1.0C.

Danke fürs aufspüren! :-)

Hallo Markus,

prima, osmfilter wie auch osmfilter32 funzen jetzt auch unter Debian 🙂

Danke fürs fixen.

Ciao,
Frank

Hallo
Ich hab das neuste osmosis unter Ubuntu 11.10
Das hier geht nicht ?

osmosis germany.osm.pbf --keep="boundary=administrative" >grenzen.osm

Es sollen alle admin level drin sein bis 12 ?

ich möchte selbst eine aktuelle Datei mit bounds erstellen um sie dann ich mkgmap zu nutzen?
Ich hoffe ich bin hier richtig

Der andere Befehl
marko@marko-desktop:~/Dokumente/osmosis$ osmconvert germany.osm.pbf --out-o5m >germany.o5m
osmconvert: Befehl nicht gefunden.
marko@marko-desktop:~/Dokumente/osmosis$

Da geht auch was nicht ?
Beste Grüße

Hast du es denn mal mit dem hier besprochenen Programm osmfilter versucht? Deine Befehlszeilen sind ja allesamt für osmosis oder osmconvert. Wobei das Programm osmconvert im Verzeichnis von Osmosis sicher nicht bekannt ist wie die Fehlermeldung auch zeigt.

Falls es Dich interessiert. Hier steht wie ich es mache und wenn Du es nicht unbedingt selbst filtern willst, kannst Du Dir die aktuellen Bounds wöchentlich runterladen
http://mkgmap.osm4people.org/

Win32netsky wrote:

Hallo
Ich hab das neuste osmosis unter Ubuntu 11.10
Da geht auch was nicht ?
Beste Grüße

Klar geht das nicht:
osmfilter&osmconvert sind eigenständige (C-)Programme und haben mit dem (java-)osmosis nüchts zu tun.
Ausser den ersten 3 Buchstaben 😉

http://www.navmaps.eu/index.php/developers/bound

wäre auch eine Quelle für bounds 😉

Hallo
Danke für die Infos
die von Navmaps habe ich vom 21 Januar
Das sind ca. 2 GB groß

Ich lad mal die 225 MB ich denke mal Deutschland.

Ich dachte das das hier für osmosis war ?

Was bräuchte ich denn?
Mit der osmconvert Linux 32 bib kann ich nichts anfangen ( wählen sie eine Anwendung aus ? )

Gibt es wo eine Seite wo man das nachlesen kann wie die europa bound erstellt werden ( halbwegs verständlich )
ich würde das gerne für meine LKW Karte selbst machen wollen.
Beste Grüße

http://wiki.openstreetmap.org/wiki/Mkgm … ress_index

Ich versteh nur nicht, warum du dir die Arbeit machen möchtest....die fertige Datei (world) hat 275mb

Hallo
Ja dann werd ich wohl warten bist die mal erneuert wird
Beste Grüße

Win32netsky wrote:

Hallo
Ja dann werd ich wohl warten bist die mal erneuert wird
Beste Grüße

Müsste bald kommen. Habe gestern für den Betreiber von Navmaps noch die Grenze von Bosnien repariert. Das ist dann heute in dem Extrakt

Hallo
Deine Grenzen sind Europa. bis zu welchen admin Level gehen die ?
Ich teste heute mal Deine.

Ich mache gerade routable Karten für die LKW.
Ich möchte noch D-DK usw. da bin ich grad dabei.
Beste Grüße

Win32netsky wrote:

Hallo
Deine Grenzen sind Europa. bis zu welchen admin Level gehen die ?
Ich teste heute mal Deine.

Ich mache gerade routable Karten für die LKW.
Ich möchte noch D-DK usw. da bin ich grad dabei.
Beste Grüße

Ich filtere kein Admin-Level raus.

/usr/local/bin/osmfilter64␣europe.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative␣=postal_code␣postal_code="␣␣>europe-boundaries.osm

Es müssten also alle drin sein. Wie weit runter mkgmap beim Auswerten geht, weiß ich nicht. Morgen oder übermorgen gibts neue....nur falls Du warten willst.

SunCobalt wrote:

Es müssten also alle drin sein. Wie weit runter mkgmap beim Auswerten geht, weiß ich nicht.

Das legst Du in Deinem Style selber fest, mkgmap weiss genau genommen gar nichts über admin_level.

Thorsten

hallo
In meinem Style habe ich bis 12 alle drin
Gut Danke

Meine Karte mach ich auch wöchentlich oder 14 tägig wie ich dazu komme.

werde die mir wöchentlich laden
Beste Grüße

Bist du dir sicher, dass es sinnvoll ist, bis 12 zu gehen?
Evtl. postest du ja mal den betreffenden Ausschnitt deines Style-Files.

Hallo
Ich hab das bis nummer 10 drin

mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }

Trinum ist drin in der Suche aber Thurau nicht ? ( Verdammt ich hab mir schon alles angesehen Trinum und Thurau etwas muss fehlen ?)
Daher wollte ich eigene bounds haben die wegen der Tests immer aktuell sind ?
Beste Grüße

müsstest in 4 Stunden aktuelle Bounds auf meiner Seite sehen.

Mir ist aber schleierhaft, warum es bei Dir am Selbererstellen scheitert. Auf meiner Seite stehen die 3 Befehle ganz genau geschrieben. Auf der Wiki-Seite stehs noch ausführlicher.

Hallo
Ich hab Ubuntu
Ja ich kann die Datei in Downloads runterladen und dann liegt das die osmconvert32 ? Mit den Befehlen kann ich nichts anfangen da dasa mit Doppelklick nicht öffnet?
Ich hab die Datei mal in ein Verzeichnis osmconvert verschoben.
Hier mal das Terminal

marko@marko-desktop:~$␣cd␣Dokumente/osmconvert
marko@marko-desktop:~/Dokumente/osmconvert$␣osmconvert32␣germany.osm.pbf␣--out-o5m␣>germany.o5m
osmconvert32:␣Befehl␣nicht␣gefunden.
marko@marko-desktop:~/Dokumente/osmconvert$

Meine Befehl

java␣-Xmx2000m␣-jar␣mkgmap.jar␣--remove-short-arcs␣--preserve-element-order␣--bounds=bounds␣--index␣--levels=0:24,1:22,2:21,3:19,4:18,5:16␣--route␣--latin1␣--code-page=1250␣--add-pois-to-lines␣--add-pois-to-areas␣--style-file=lkw␣--location-autofill=1␣--gmapsupp␣--location-autofill:bounds␣--family-id=4␣--product-id=45␣--family-name=LKW-Karte-vom-23.02.2012␣--net␣-c␣template.args␣lkw.TYP

Beste Grüße

Win32netsky wrote:

Ich hab Ubuntu Ja ich kann die Datei in Downloads runterladen und dann liegt das die osmconvert32 ? ...

Ich hab die Datei mal in ein Verzeichnis osmconvert verschoben. Hier mal das Terminal

...desktop:~$␣cd␣Dokumente/osmconvert
...desktop:~/Dokumente/osmconvert$␣osmconvert32␣germany.osm.pbf␣--out-o5m␣>germany.o5m
osmconvert32:␣Befehl␣nicht␣gefunden.

Soweit ganz in Ordnung. Probiere mal ./osmconvert32 ... aus.
Manchmal zickt das Terminal, wenn man das nicht macht.

Erklärung:
./ ist eine Kurzform für deinen aktuellen Pfad.
Damit ergibt "./osmconvert32" einen kompletten Pfadnamen
und damit wird das Programm dann auch gefunden.

PS: Ist im Mac-Terminal genauso.

Edbert (EvanE)

Hallo

Also Thurau ist noch nicht da mit den neuen bounds

Der einzige Unterschied ist Trinum hat eine Seite der Grenze vebindung mit admin level 6 Sachsen-Anhalt ?
Eventuell kann mal jemand sagen warum Thurau nicht auftaucht, obwohl ich alles wie bei Trinum gemacht habe.

Habe heute noch mal was geändert mal sehen ob es das war muss nun auf neue bounds warten?

./osmconvert32␣germany.osm.pbf␣--out-o5m␣>germany.o5m

Jetzt tut das Terminal was mal warten

So ich hab jetzt eine germany.o5m Datei im Verzeichnis osmoconvert 1,9GB groß ?
Hier ging was.

osmfilter64 hab ich runtergeladen und ausführbar gemacht wie mit osmconvert und im selben Ordner

das tut nichts ?

marko@marko-desktop:~$␣cd␣Dokumente/osmconvert
marko@marko-desktop:~/Dokumente/osmconvert$␣osmfilter64␣germany.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative␣=postal_code␣postal_code=␣>germany-boundaries.osm
>

./osmfilter32␣germany.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative␣=postal_code␣postal_code=␣>germany-boundaries.osm

auch mit 32 nichts ?
Beste Grüße

Win32netsky wrote:

osmfilter64 hab ich runtergeladen und ausführbar gemacht wie mit osmconvert und im selben Ordner

das tut nichts ?

marko@marko-desktop:~$␣cd␣Dokumente/osmconvert
marko@marko-desktop:~/Dokumente/osmconvert$␣osmfilter64␣germany.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative␣=postal_code␣postal_code=␣>germany-boundaries.osm
>

./osmfilter32␣germany.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative␣=postal_code␣postal_code=␣>germany-boundaries.osm

auch mit 32 nichts ?
Beste Grüße

Liegt vielleicht am letzten "=" welches eigentlich ein " sein sollte. Außerdem kann es auch nicht schaden wenn du osmfilter64 wieder das ./ voranstellst. Nur zur Sicherheit.

viw wrote:

Win32netsky wrote:

osmfilter64 hab ich runtergeladen und ausführbar gemacht wie mit osmconvert und im selben Ordner

das tut nichts ?

marko@marko-desktop:~$␣cd␣Dokumente/osmconvert
marko@marko-desktop:~/Dokumente/osmconvert$␣osmfilter64␣germany.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative␣=postal_code␣postal_code=␣>germany-boundaries.osm
>

./osmfilter32␣germany.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative␣=postal_code␣postal_code=␣>germany-boundaries.osm

auch mit 32 nichts ?
Beste Grüße

Liegt vielleicht am letzten "=" welches eigentlich ein " sein sollte. Außerdem kann es auch nicht schaden wenn du osmfilter64 wieder das ./ voranstellst. Nur zur Sicherheit.

nee, es fehlt ein " nach dem letzten =. Mein Fehler. Sorry

Hallo
Ja mit

./osmfilter32␣germany.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative␣=postal_code␣postal_code=">germany-boundaries.osm

geht was die germany hat 550 MB

damit gehts

java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=␣germany-boundaries.osm

Und ich bekomme ganz viel Fehler kann man die vernachläsigen?

SCHWERWIEGEND␣(BoundaryPreparer):␣Boundary␣file␣␣not␣found.
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lissabonner␣Straße,␣http://www.openstreetmap.org/browse/way/86543743)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.10828&mlon=8.64429&zoom=17

usw.

Nur wo sind die bounds dann in welchen Verzeichnis ?

tut sich was
Mal abwarten
Beste Grüße

Win32netsky wrote:

java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=␣germany-boundaries.osm

Du solltest vielleicht noch angeben wo er sie hinschreiben soll.

Und ich bekomme ganz viel Fehler kann man die vernachläsigen?

Hängt vom Fehler ab.

SCHWERWIEGEND␣(BoundaryPreparer):␣Boundary␣file␣␣not␣found.

Den garantiert nicht. Sonst kannst Du Dir das ganze gleich sparen.

Thorsten

Hallo
Sowas dachte ich schon
Damit erstellt mkgmap eine Datei bounds? Aber leer

java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=␣germany-boundaries.osm␣>bounds

Das läuft im Terminal durch

SCHWERWIEGEND␣(BoundarySaver):␣Cannot␣save␣boundary:␣java.io.FileNotFoundException:␣bounds/bounds_2250000_550000.bnd␣(Not␣a␣directory)

Beste Grüße

kukuk wrote:

Win32netsky wrote:

java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=␣germany-boundaries.osm

Du solltest vielleicht noch angeben wo er sie hinschreiben soll.

es wird doch automatisch ein "bounds" Verzeichnis angelegt. Ich habe kein ">" hinten dran und es geht

Hallo
Ja es läuft aber im Verzeichnis mkgmap wird kein Verzeichnis bounds angelegt ?

Das der Start

java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=␣germany-boundaries.osm

Das ist aus dem Terminal

marko@marko-desktop:~$␣cd␣Dokumente/mkgmap
marko@marko-desktop:~/Dokumente/mkgmap$␣java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=␣germany-boundaries.osm
SCHWERWIEGEND␣(BoundaryPreparer):␣Boundary␣file␣␣not␣found.
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lissabonner␣Straße,␣http://www.openstreetmap.org/browse/way/86543743)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.10828&mlon=8.64429&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Olpe,␣http://www.openstreetmap.org/browse/way/23368384)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.51264&mlon=7.47081&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/45064342)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.54870&mlon=13.41632&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Maadeland,␣http://www.openstreetmap.org/browse/way/23385800)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=54.49472&mlon=9.03475&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/30406777)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.96086&mlon=7.76736&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/30406608)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.96086&mlon=7.76733&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/30406609)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.96086&mlon=7.76736&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Albert-Schweitzer-Straße,␣http://www.openstreetmap.org/browse/way/151237804)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.45407&mlon=13.62165&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/110429730)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.76448&mlon=12.74822&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/26980754)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.94644&mlon=7.75748&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Kemnastraße,␣http://www.openstreetmap.org/browse/way/27820982)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.47779&mlon=7.10736&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Kapfenberger␣Straße,␣http://www.openstreetmap.org/browse/way/25879846)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.90262&mlon=6.80749&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Harpener␣Hellweg,␣http://www.openstreetmap.org/browse/way/92459211)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.49352&mlon=7.25621&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Althoffstraße,␣http://www.openstreetmap.org/browse/way/24381674)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.45296&mlon=8.82069&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lehgasse,␣http://www.openstreetmap.org/browse/way/25795369)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=48.15887&mlon=7.79570&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Am␣Stirkenbend,␣http://www.openstreetmap.org/browse/way/32456595)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.20234&mlon=6.55538&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Mittelweg,␣http://www.openstreetmap.org/browse/way/30243917)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.85305&mlon=8.33993&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Talstraße,␣http://www.openstreetmap.org/browse/way/4631716)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.55619&mlon=13.42579&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Hubertusring,␣http://www.openstreetmap.org/browse/way/24578679)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.33043&mlon=8.01968&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(L20␣Bocholder␣Straße,␣http://www.openstreetmap.org/browse/way/45881269)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.46359&mlon=6.94915&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Kantstraße,␣http://www.openstreetmap.org/browse/way/70872095)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.03650&mlon=10.26344&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Bei␣der␣Klauskapelle,␣http://www.openstreetmap.org/browse/way/35105445)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=49.98281&mlon=10.11452&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(SWs30␣An␣der␣Turngemeinde,␣http://www.openstreetmap.org/browse/way/133324287)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.06131&mlon=10.23179&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Kemnastraße,␣http://www.openstreetmap.org/browse/way/36966307)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.47779&mlon=7.10736&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Freiberger␣Straße,␣http://www.openstreetmap.org/browse/way/60670328)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.02991&mlon=13.30663&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Goethestraße,␣http://www.openstreetmap.org/browse/way/29095677)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.13354&mlon=11.61839&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Niendorfer␣Weg,␣http://www.openstreetmap.org/browse/way/47939159)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.61015&mlon=9.96874&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/127232302)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.44972&mlon=13.51187&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/127232295)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.44980&mlon=13.51213&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Dieffenbachstraße,␣http://www.openstreetmap.org/browse/way/4686365)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.49433&mlon=13.41070&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Obere␣Straße,␣http://www.openstreetmap.org/browse/way/127245451)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.92121&mlon=9.22987&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(K35␣Konrad-Adenauer-Straße,␣http://www.openstreetmap.org/browse/way/37959662)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.17874&mlon=6.54723&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(L20␣Bocholder␣Straße,␣http://www.openstreetmap.org/browse/way/45963278)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.46359&mlon=6.94915&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Oswald-Markert-Ring,␣http://www.openstreetmap.org/browse/way/35784121)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.09495&mlon=10.20199&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/137878677)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.95826&mlon=7.80450&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/28170464)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.19386&mlon=8.79584&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Deelwisch,␣http://www.openstreetmap.org/browse/way/146702819)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.60223&mlon=9.94093&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Berliner␣Straße,␣http://www.openstreetmap.org/browse/way/23099192)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.59078&mlon=13.28241&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(B5,␣http://www.openstreetmap.org/browse/way/56054014)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=54.46824&mlon=9.07589&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Schmidhofener␣Straße,␣http://www.openstreetmap.org/browse/way/31114362)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.88159&mlon=7.68172&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Am␣Wallhof,␣http://www.openstreetmap.org/browse/way/9245664)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.50534&mlon=9.45882&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/33642102)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.96315&mlon=7.78132&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Sommerbuckweg,␣http://www.openstreetmap.org/browse/way/28114880)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=48.00626&mlon=7.89677&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Großlangheimer␣Straße,␣http://www.openstreetmap.org/browse/way/104515015)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=49.72953&mlon=10.24387&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Kieler␣Straße,␣http://www.openstreetmap.org/browse/way/23162998)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.52071&mlon=8.11246&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/50306627)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.93590&mlon=7.74163&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/27224273)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.93571&mlon=7.74225&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Kurt-Schumacher-Allee,␣http://www.openstreetmap.org/browse/way/29192157)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.43689&mlon=9.74777&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(L441␣Frankenstraße,␣http://www.openstreetmap.org/browse/way/34666912)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.42855&mlon=7.05468&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Goethestraße,␣http://www.openstreetmap.org/browse/way/97576229)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.13354&mlon=11.61839&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(L244␣Herzog-Adolf-Straße,␣http://www.openstreetmap.org/browse/way/110262419)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=54.47416&mlon=9.05512&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Bernhard-Härtel-Straße,␣http://www.openstreetmap.org/browse/way/33186368)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.88032&mlon=11.43810&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/29974722)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.76433&mlon=12.74828&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Holsteiner␣Straße,␣http://www.openstreetmap.org/browse/way/61560233)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.07085&mlon=13.66075&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(K44␣Bremer␣Straße,␣http://www.openstreetmap.org/browse/way/30981585)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.32607&mlon=9.84334&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Stettiner␣Weg,␣http://www.openstreetmap.org/browse/way/60302328)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.37869&mlon=9.78858&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lange␣Reihe,␣http://www.openstreetmap.org/browse/way/54800477)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.55775&mlon=10.01183&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Universitätsstraße,␣http://www.openstreetmap.org/browse/way/87026586)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.80700&mlon=8.76870&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Bahnhofstraße,␣http://www.openstreetmap.org/browse/way/59280406)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.59376&mlon=8.88185&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(L215␣Christian-Steger-Straße,␣http://www.openstreetmap.org/browse/way/77866677)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.47142&mlon=6.85967&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Märkische␣Allee,␣http://www.openstreetmap.org/browse/way/28237116)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.53291&mlon=13.53767&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Brunnenweg,␣http://www.openstreetmap.org/browse/way/5383864)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.92616&mlon=9.23783&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Rosental,␣http://www.openstreetmap.org/browse/way/104357478)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.51406&mlon=7.46890&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(L534␣Viktoriastraße,␣http://www.openstreetmap.org/browse/way/41185804)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.28876&mlon=8.93362&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Friedrich-Ebert-Straße,␣http://www.openstreetmap.org/browse/way/4409615)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.36420&mlon=7.21398&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Unterm␣Willem,␣http://www.openstreetmap.org/browse/way/33270880)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.24499&mlon=8.91362&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Betenstraße,␣http://www.openstreetmap.org/browse/way/8455846)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.51292&mlon=7.46706&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(L773␣Ahlsener␣Straße,␣http://www.openstreetmap.org/browse/way/122930192)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.28662&mlon=8.64030&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Hohenzollernpassage,␣http://www.openstreetmap.org/browse/way/60180901)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.20373&mlon=8.79700&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Nordendstraße,␣http://www.openstreetmap.org/browse/way/38304189)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.58887&mlon=13.38819&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Raffelberger␣Straße,␣http://www.openstreetmap.org/browse/way/4994424)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.44421&mlon=6.97544&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Peter-Hille-Straße,␣http://www.openstreetmap.org/browse/way/25408839)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.45407&mlon=13.62165&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lübsche␣Straße,␣http://www.openstreetmap.org/browse/way/144909790)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.89421&mlon=11.43863&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/142702442)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.88265&mlon=7.67653&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lange␣Reihe,␣http://www.openstreetmap.org/browse/way/23049818)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.55646&mlon=10.01013&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lange␣Reihe,␣http://www.openstreetmap.org/browse/way/23049818)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.55646&mlon=10.01013&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Alexanderstraße,␣http://www.openstreetmap.org/browse/way/34346543)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.55623&mlon=10.02146&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Königsweg,␣http://www.openstreetmap.org/browse/way/5064115)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.39903&mlon=13.14548&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Uhlandstraße,␣http://www.openstreetmap.org/browse/way/22965435)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.58617&mlon=13.38969&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Holzheienstraße,␣http://www.openstreetmap.org/browse/way/26425621)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.97371&mlon=11.02244&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Friedrich-Engels-Straße,␣http://www.openstreetmap.org/browse/way/24930947)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.58524&mlon=13.39021&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Friedrich-Engels-Straße,␣http://www.openstreetmap.org/browse/way/24930947)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.58617&mlon=13.38969&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Friedrich-Engels-Straße,␣http://www.openstreetmap.org/browse/way/24930947)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.58887&mlon=13.38819&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(L168␣Oyterdamm,␣http://www.openstreetmap.org/browse/way/83822230)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.05886&mlon=9.00802&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Wiesenstraße,␣http://www.openstreetmap.org/browse/way/66159175)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.21128&mlon=8.73113&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Segnitzstraße,␣http://www.openstreetmap.org/browse/way/22948675)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.05431&mlon=10.24447&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Nettelbeckstraße,␣http://www.openstreetmap.org/browse/way/23948016)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.53457&mlon=6.84785&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Dr.-Schultz-Straße,␣http://www.openstreetmap.org/browse/way/77167042)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.90262&mlon=6.80749&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Bolivarstraße,␣http://www.openstreetmap.org/browse/way/5106249)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.09334&mlon=13.72186&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Bolivarstraße,␣http://www.openstreetmap.org/browse/way/5106249)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.09295&mlon=13.72160&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Am␣Bürgerpark,␣http://www.openstreetmap.org/browse/way/5108501)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.92977&mlon=9.23193&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(St2271␣Schweinfurter␣Straße,␣http://www.openstreetmap.org/browse/way/51317883)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.00356&mlon=10.24248&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Unterm␣Brink,␣http://www.openstreetmap.org/browse/way/18506887)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.20272&mlon=8.85927&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Babbenhausener␣Straße,␣http://www.openstreetmap.org/browse/way/36486276)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.19875&mlon=8.84696&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Friedrichstraße,␣http://www.openstreetmap.org/browse/way/30720544)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.52340&mlon=13.38772&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Biershöhe,␣http://www.openstreetmap.org/browse/way/38416239)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.18012&mlon=8.93888&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(B3␣Basler␣Straße,␣http://www.openstreetmap.org/browse/way/51162028)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.96086&mlon=7.76736&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(B3␣Basler␣Straße,␣http://www.openstreetmap.org/browse/way/51162144)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.96084&mlon=7.76742&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Konrad-Adenauer-Straße,␣http://www.openstreetmap.org/browse/way/44385389)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.06277&mlon=10.24896&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Mausefalle,␣http://www.openstreetmap.org/browse/way/18443215)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.11485&mlon=8.67128&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/35586529)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.42869&mlon=8.46007&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Birkenweg,␣http://www.openstreetmap.org/browse/way/38477194)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.92238&mlon=8.20082&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Arenbergstraße,␣http://www.openstreetmap.org/browse/way/45419661)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.66145&mlon=7.07176&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Nordendstraße,␣http://www.openstreetmap.org/browse/way/35573921)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.58887&mlon=13.38819&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Große␣Straße,␣http://www.openstreetmap.org/browse/way/22823258)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=53.36678&mlon=7.20549&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/84944127)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.54656&mlon=13.22451&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Kemnastraße,␣http://www.openstreetmap.org/browse/way/141415796)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.47779&mlon=7.10736&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(L551␣Herner␣Straße,␣http://www.openstreetmap.org/browse/way/93952301)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.48766&mlon=7.21407&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Hardterbroicher␣Allee,␣http://www.openstreetmap.org/browse/way/17370409)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.18603&mlon=6.46018&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Spandauer␣Damm,␣http://www.openstreetmap.org/browse/way/32977541)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.52433&mlon=13.24831&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Triftenstraße,␣http://www.openstreetmap.org/browse/way/34117109)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.19688&mlon=8.81653&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Garnisonskirchplatz,␣http://www.openstreetmap.org/browse/way/46517262)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.52216&mlon=13.40197&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(An␣der␣Stertwelle,␣http://www.openstreetmap.org/browse/way/22767216)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.24909&mlon=8.50797&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Wesselswerth,␣http://www.openstreetmap.org/browse/way/54108589)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.38651&mlon=7.00226&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Nollgasse,␣http://www.openstreetmap.org/browse/way/26619472)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=50.50921&mlon=8.73117&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Anbaustraße,␣http://www.openstreetmap.org/browse/way/43026329)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.20230&mlon=13.72720&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Spenger␣Straße,␣http://www.openstreetmap.org/browse/way/22777080)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.18251&mlon=8.46926&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Friedrich-Engels-Straße,␣http://www.openstreetmap.org/browse/way/4765086)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.58887&mlon=13.38819&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Eichenstraße,␣http://www.openstreetmap.org/browse/way/4777284)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.58524&mlon=13.39021&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Uhlandstraße,␣http://www.openstreetmap.org/browse/way/4777316)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.58617&mlon=13.38969&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Fährstraße,␣http://www.openstreetmap.org/browse/way/25572963)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.16912&mlon=8.87045&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(K16␣Harrienstedt,␣http://www.openstreetmap.org/browse/way/40848061)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.43596&mlon=8.93555&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Hannenplatz,␣http://www.openstreetmap.org/browse/way/26675570)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.19084&mlon=6.51290&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Knappenweg,␣http://www.openstreetmap.org/browse/way/27563054)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.31973&mlon=9.65052&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Knappenweg,␣http://www.openstreetmap.org/browse/way/27563058)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.32116&mlon=9.65063&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Eiswerderstraße,␣http://www.openstreetmap.org/browse/way/150206506)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.54879&mlon=13.22284&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lattensiek,␣http://www.openstreetmap.org/browse/way/34149016)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.26679&mlon=8.75522&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Ortdieck,␣http://www.openstreetmap.org/browse/way/25522349)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.57176&mlon=7.47120&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(K26␣Bäderstraße,␣http://www.openstreetmap.org/browse/way/85289461)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.23478&mlon=8.60513&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Kirchstraße,␣http://www.openstreetmap.org/browse/way/24898223)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.96088&mlon=7.76736&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Bottroper␣Ring,␣http://www.openstreetmap.org/browse/way/29448833)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.41646&mlon=10.74139&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Leineleweg,␣http://www.openstreetmap.org/browse/way/25538421)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=47.96315&mlon=7.78132&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Am␣Klößberg,␣http://www.openstreetmap.org/browse/way/25457600)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=49.98784&mlon=10.24784&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Nordhof,␣http://www.openstreetmap.org/browse/way/82323734)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.50079&mlon=8.98506&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lanzerather␣Feldstraße,␣http://www.openstreetmap.org/browse/way/27681113)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.18041&mlon=6.64647&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(http://www.openstreetmap.org/browse/way/31614910)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=48.15385&mlon=7.78609&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Liefergasse,␣http://www.openstreetmap.org/browse/way/144140055)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=51.22768&mlon=6.77339&zoom=17
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Osterbachweg,␣http://www.openstreetmap.org/browse/way/4977566)␣contains␣zero␣length␣arc␣at␣http://www.openstreetmap.org/?mlat=52.19933&mlon=8.78608&zoom=17
There␣is␣not␣enough␣room␣in␣a␣single␣garmin␣map␣for␣all␣the␣input␣data
The␣.osm␣file␣should␣be␣split␣into␣smaller␣pieces␣first.
marko@marko-desktop:~/Dokumente/mkgmap$

Beste Grüße

Das Leerzeichen vor germany muss wech. 😎

Win32netsky wrote:

Hallo
Ja es läuft aber im Verzeichnis mkgmap wird kein Verzeichnis bounds angelegt ?

Das der Start

java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=␣germany-boundaries.osm

Das ist aus dem Terminal

marko@marko-desktop:~$␣cd␣Dokumente/mkgmap
marko@marko-desktop:~/Dokumente/mkgmap$␣java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=␣germany-boundaries.osm
SCHWERWIEGEND␣(BoundaryPreparer):␣Boundary␣file␣␣not␣found.
SCHWERWIEGEND␣(RoadNetwork):␣germany-boundaries.osm:␣Road␣(Lissabonner␣Straße,␣http://www.openstreetmap.org/browse/way/86543743)␣contains␣zero␣length␣arc␣at

Setz mal --remove-short-arcs, dann fliegen die meisten Fehlermeldungen raus.

Gruß,
ajoessen

hier mein Skript, was wöchentlich läuft und auch funktioniert

#!/bin/bash

#␣cleaning␣up␣bounds␣directory
cd␣/home/thomas/mkgmap/bounds␣&&␣for␣i␣in␣*␣;␣do␣rm␣$i␣;␣done

#cleaning␣up␣old␣input␣and␣temporary␣results
cd␣/home/thomas/mkgmap/
rm␣bounds.zip
rm␣europe.osm.pbf
rm␣europe.o5m
rm␣europe-boundaries.osm

#␣getting␣new␣europe␣data
wget␣http://ftp5.gwdg.de/pub/misc/openstreetmap/download.geofabrik.de/europe.osm.pbf

#␣converting␣to␣o5m␣to␣increase␣speed
/home/thomas/mkgmap/osmconvert32␣europe.osm.pbf␣--out-o5m␣>europe.o5m

#filter␣boundaries
/usr/local/bin/osmfilter64␣europe.o5m␣--keep-nodes=␣--keep-ways-relations="boundary=administrative␣=postal_code␣postal_code="␣␣>europe-boundaries.osm

#␣creating␣input␣for␣Garmin␣map␣generation
java␣-jar␣/home/thomas/mkgmap/mkgmap-r2165/mkgmap.jar␣--max-jobs=2␣--createboundsfile=europe-boundaries.osm

+␣zipping␣results
zip␣-r␣bounds.zip␣./bounds

SunCobalt wrote:

hier mein Skript, was wöchentlich läuft und auch funktioniert

(...)

#␣cleaning␣up␣bounds␣directory
cd␣/home/thomas/mkgmap/bounds
for␣i␣in␣*␣;␣do␣rm␣$i␣;␣done

(...)

Kleine Anmerkung:
Die fehlende Überprüfung ob der Wechsel in das Verzeichnis möglich war, kann übel enden.
Denn wenn der Wechsel in das Verzeichnis nicht möglich war, wird das Skript versuchen Dateien im aktuellen Verzeichnis zu löschen und nicht vorher abbrechen.

Gruß,
Mondschein

Win32netsky wrote:

Hallo
Ja es läuft aber im Verzeichnis mkgmap wird kein Verzeichnis bounds angelegt ?

leg mal von Hand eins an.

Hallo
@Chris66

Ich arbeite jetzt die Tips mal ab

Hier mein Test hier geht was bounds wird erstellt

marko@marko-desktop:~$␣cd␣Dokumente/mkgmap
marko@marko-desktop:~/Dokumente/mkgmap$␣java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=germany-boundaries.osm
SCHWERWIEGEND␣(BoundarySaver):␣Calculate␣bbox␣to␣(47.206878662109375,5.364418029785156)␣to␣(54.717063903808594,15.020370483398438)

Es läuft noch

hat hiermit beendet

marko@marko-desktop:~$␣cd␣Dokumente/mkgmap
marko@marko-desktop:~/Dokumente/mkgmap$␣java␣-Xmx2000m␣-jar␣mkgmap.jar␣--max-jobs=2␣--createboundsfile=germany-boundaries.osm
SCHWERWIEGEND␣(BoundarySaver):␣Calculate␣bbox␣to␣(47.206878662109375,5.364418029785156)␣to␣(54.717063903808594,15.020370483398438)
SCHWERWIEGEND␣(BoundarySaver):␣Calculate␣bbox␣to␣(47.206878662109375,5.364418029785156)␣to␣(54.717063903808594,15.020370483398438)
marko@marko-desktop:~/Dokumente/mkgmap$

Hat ein bound erstellt mit ca 65 MB
Ich denke mal deas das reell ist?

Beste Grüße

Mondschein wrote:

SunCobalt wrote:

hier mein Skript, was wöchentlich läuft und auch funktioniert

(...)

#␣cleaning␣up␣bounds␣directory
cd␣/home/thomas/mkgmap/bounds
for␣i␣in␣*␣;␣do␣rm␣$i␣;␣done

(...)

Kleine Anmerkung:
Die fehlende Überprüfung ob der Wechsel in das Verzeichnis möglich war, kann übel enden.
Denn wenn der Wechsel in das Verzeichnis nicht möglich war, wird das Skript versuchen Dateien im aktuellen Verzeichnis zu löschen und nicht vorher abbrechen.

Theoretisch richtig, praktisch nicht ganz so tragisch:

• Es werden nirgends im Skript Returnwerte überprüft, warum jetzt einmal so zimperlich sein 😉
  
• Es handelt sich wohl um einen Homecomputer und wird so wohl selten (NFS-)mounts haben, möglichlicherweise gar nur eine Partition (modulo /boot), so dass der "cd" immer funktionokelt.
  
• Falls nicht: Er schreibt "wöchentlich", wird wohl ein cronjob sein, und dann ist das Ausgangsverzeichnis $HOME
  
• Und wenn $HOME sauber gepflegt ist (ähnlich wie das Wurzelvezichnis "/") gibt es nur Verzeichnisse und Dot(Konfig)dateien (".irgendwas") und daher wird nix gelöscht
  

BTW:
rm /home/thomas/mkgmap/bounds/*
Warum so kompliziert 😉

kellerma wrote:

Theoretisch richtig, praktisch nicht ganz so tragisch:

Wenn jemand einfach das Skript aus dem Forum kopiert und dieses ausführt, ohne das nötige Verzeichnis mit entsprechenden Rechten zu erstellen, dann kann es durchaus passieren, dass danach die eine oder andere Datei weg ist, evtl. auch das Skript selbst. 😉

kellerma wrote:

• Es werden nirgends im Skript Returnwerte überprüft, warum jetzt einmal so zimperlich sein 😉
  

Ein "&&" kann aber viel Ärger ersparen. 🙂

Gruß,
Mondschein

kellerma wrote:

BTW:
rm /home/thomas/mkgmap/bounds/*
Warum so kompliziert 😉

weil mkgmap mal ne Macke hatte und mehr Dateinen angelegt hatte, als rm löschen kann. Und ich starte das Skript von Hand, nicht per Cron. Soviel kann daher nicht passieren.

Okay, okay. Wenn das irgendjemand ohne das Verzeichnis startet, kanns natürlich ins Auge gehen. Ich habs daher oben mal angepasst. Wobei ich eigentlich der Meinung bin, dass man sich für ein Projekt sowieso immer ein neues Verzeichnis anlegt und das nicht in ~ macht

Hallo
So jetzt läuft alles
Habe das in meine Baustelle Mkgmap eingfügt.
Über meine Wiki Seite
Beste Grüße