Wenn ich in Maperitive versuche, OSM-Daten mit der programmeigenen Funktion herunterzuladen, werden
über die XAPI veraltete Daten geladen
über die Overpass-API Daten mit Lücken geladen (einzelne Flächen innerhalb der BoundingBox sind einfach leer)
Alternativ habe ich versucht, die Daten mit JOSM herunterzuladen und dann in Maperitive zu importieren. Hier habe ich stets das Problem, dass z. B. Waldgebiete, die über die Grenzen des geladenen Gebietes hinausgehen, in JOSM “abgeschnitten” werden und in Maperitive dann komplett fehlen.
Irgendwie muss das doch zu machen sein. Das Gebiet ist auch nicht besonders groß, allerdings zu groß, um die Daten direkt von openstreetmap.org aus herunterzuladen. Die Grenzen sind 7.7804, 7.9265, 50.3858, 50.4717
Hat jemand eine Idee, was ich da noch machen kann?
Das Problem tritt bei Flächen vom Typ multipolygon mit mehreren outers auf, von denen einige außerhalb der Downloadgrenzen liegen, und die deshalb nicht komplett geladen werden und daher nicht darstellbar sind.
Man kann die Downloadgrenzen soweit ausdehnen, dass alle Multipolygone komplett erfasst werden, oder die runtergeladenen Daten aus Maperitive heraus speichern (save-source file=xxx.osm index=x) und in einem Editor öffnen und dann die fehlenden Abhängigkeiten nachladen, oder die quasilotte-Methode anwenden.
Das ist das Hauptproblem - da Maperitive konsequent keine Fläche zeichnet wenn diese nicht geschlossen (was ja bei einem fehlendem Outer der fallist).
Nach meinen Erfahrungen kann man die Grenzen nicht soweit ausdehnen das immer alles drinn ist.
Bei einem Test hatte ich erst bei einem Rand von 4 Grad alles dirn (entspräche 3.78 46.38 11.92 54.47)
Selbst bei einem Rand von 2 Grad fehlte nochwas siehe http://forum.openstreetmap.org/viewtopic.php?pid=316447#p316447.
Mit einem Editor nachladen geht natürlich aber bis ich damit fetig bin hab ich es 3mal Ausgeschnitten (die API’s sind ja auch nicht die schnellsten!)
Moin!
Wahrscheinlich kennst du dich mit osmconvert inzwischen besser aus als ich, auf jeden Fall benutzt du es häufiger.
Deine Befehlszeile wird wahrscheinlich funktionieren, aber drei Optionen sind überflüssig:
–drop-author: Diese Option wird von --drop-version mit eingeschlossen.
–emulate-osmosis: Wirkt nur bei .osm-Ausgaben (XML-Format).
–out-pbf: Einfacher ist es, -o= zu verwenden, dann pickt sich osmconvert das Dateiformat aus dem Dateinamen raus.
Mit osmosis kein Problem:
die Optionen completeWays=yes, completeRelations=yes, cascadingRelations=yes und clipIncompleteEntities=false sorgen dafür, dass beim Clippen nichts “verschütt” geht. (*)
Die Extrakte der Geofabrik sind so erstellt.
Du mußt “nur noch” dieses Verhalten den anderen Tools beibringen - oder osmosis verwenden
mit osmconvert --complex-ways … ist auch alles drin
@Marqs
Ist halt alles historisch so gewachsen und was geht warum sollte man das Ändern! Mal gucken ob weglassen Zeitvorteile bringt!
Und besser kenne ich osmconvert sicher nicht - allerhöchstens die Verküpfung mit anderen Programmen intensiver (mit einem Nachbarforumuser) betrieben.
Die Sache wird komlizierter, als ich dachte. osmconvert kann ich nicht verwenden, da ich auf einem Mac mit MacOS arbeite.
Dann muss ich also mal versuchen, ob osmosis läuft und ich mit der Kommandozeileneingabe klar komme. So wie ich das verstehe, kann ich doch bei der Geofabrik die OSM-Datei für Rheinland-Pfalz herunterladen und dann mit osmosis den rechteckigen Bereich, den ich brauche, ausschneiden. Richtig?
Mal ganz dumm gefragt: warum nicht? Ich kenne mich mit Macs nicht aus: möglicherweise steht ja einer der von osmconvert.c eingebundenen Header dort nicht zur Verfügung. Aber ansonsten braucht es nur einen C-Compiler und eine installierte zlib.
Das mit osmconvert scheint mir zu kompliziert. Ein Programm erst compilieren usw., da müsste ich mich stundenlang einarbeiten und dafür fehlt mit die Zeit.
Ich habe mir osmosis nun runtergeladen. Das ist doch ein JAVA-Programm, soweit ich das im WIKI sehe. Ich komme aber noch ganz klar damit, das Programm zu starten. Habe jetzt im Terminal-Fenster in den Ordner …/osmosis-latest/bin gewechselt und dort versucht, die Kommandozeile wie von wambacher beschrieben einzugeben. Das ergibt aber die Fehlermeldung “command not found”.
Was mache ich da falsch? Bin wohl von den GUIs anderer Programme etwas verwöhnt.
Die Kompilierung von osmconvert (eine einzige Datei) ist ein Einzeiler auf der Kommandozeile; “usw.” erübrigt sich. Die Frage ist halt nur, ob alle nötigen Header vorhanden sind - aber diese Frage beantwortet der Compiler ganz von alleine.
Auf einem *nix-artigen System müßte das Kommando in diesem Fall mit ./osmosis statt osmosis beginnen. Mac: keine Ahnung.
Ich hab’s hinbekommen. Osmosis ließ dann sich dann doch im Terminal-Fenster ausführen und wie es scheint, hat die erzeugte osm-Datei in Maperitive keine “Löcher”.