Ja, leider 
Die Frage ist ja, ob ein zerschnittener Weg aus den beiden OSM-files richtig zusammengesetzt wird. Die Extrakte haben ja keine Information darüber, was ihnen fehlt, und vor allem an welcher Stelle. Bei nem Wald-Multipolygon kanns auch schon mal mehrfach über die Extraktgrenze gehen.
Gruß,
ajoessen
Versuchs mal mit wget. Eventuell kickt dein Browser den Download zu schnell raus, wenn die Daten nur tropfenweise kommen.
gruß,
ajoessen
Genau so ist es - und darum dürfte es nach den Angaben im Wiki nicht funktionieren.
Laut Doku dort enthält ein .osc Objekte. Wenn die Applikation zusätzlich (und undokumentiert) auch verarbeitet, dann klappt das, ansonsten sieht sie ein normales .osm nur eine leere Datei.
Wenn das mechanisch funktioniert, ist der zweite Faktor die Art des Extraktes. Enthalten die Extrakte alle Objekte, die aus dem Ausschnitt herausragen, vollständig, dann kann ein Zusammensetzen erfolgreich sein. Werden überstehende Punkte abgeschnitten, dann ist es unmöglich, das wieder sinnvoll zusammenzubauen. Das hängt von der Einstellung von osmosis ab, die beim Extrahieren verwendet wurde.
bye
Nop
@ Nop
Ok. Das Gelingen der Aktion hängt also als erstes davon ab, mit welchen Optionen Frederic oder ein anderer Anbieter von Extrakten die planet-Ausschnitte erstellt.
Wenn die Extrakte nun grundsätzlich so gestaltet werden, daß jedes mit einem Rand von z.B. +1km ausgegeben wird, gäbe es in Summe eine Überlappung von 2 km. Vorausgesetzt das Mergen der doppelt vorhandenen Objekte funktioniert im Prinzip wie bei JOSM, müßte dann das Zusammenbauen der Extrakte möglich sein.
Wenn dem dann tatsächlich so ist, könnte man die bereits irgendwo geäußerte Idee, Planet-Extrakte regelmäßig zu kacheln, weiter denken.
Mal unberücksichtigt, welche Größe (20x20km - zu viel Aufwand beim Zuschneiden / 50x50km immer noch viel Aufwand aber für den Klein-Kartenbauer eine schöne Größe …) sinnvoll wäre, müßte man ausprobieren, wie weit die Überlappung sein muß, damit kein Datenschrott entsteht. Vielleicht reicht ja eine 1km-Zone oder sogar weniger. Ich rate mal: je weniger Überlappung, je weniger Berechnungszeit. Oder ist das Blödsinn, weil auf jeden Fall die gesamte Kachel “durchgeguckt” wird bzw. werden muß?
Wenn nun kleine Planet-Kacheln erhältlich wären, könnte man theoretisch auch JOSM “mißbrauchen”, um sich einen kleinen Kachelteppich zu knüpfen. Wenn man sich durch ein ausgedehntes Map-Gebiet arbeitet, macht man das über XAPI oder API ja automatisch - zumindest beim ersten Mal. Wenn das Downloadsammelsurium abgespeichert ist, braucht man ja nur noch die Updates, die dann in derselben Reihenfolge wie die ursprünglichen Uploads “einsortiert” werden. Wenn man nun ein Programm mit den Zusammenfügungsfunktionen von JOSM kreieren könnte, das auf zZt nicht vorhandene kachelförmige Extrakte zugreifen könne, …
Tja, leider hab ich keine Ahnung, ob und wie so etwas geht.
Ja, das leuchtet ein. Ich frag mich halt, ob sich überlappende Bereiche anhand der doppelt vorhandenen IDs zusammengepaßt werden könnten.
Gruß
tt
Es hilft nichts, einen Rand stehen zu lassen - der würde ja selbst wieder unvollständige Objekt am Rand enthalten. Es ist nur wichtig, daß jeder Linienzug entweder vollständig mit allen Punkten oder gar nicht enthalten ist, daß sozusagen “ausgefranst” und nicht entlang der Kante geschnitten wird. So wie ein Editor wie JOSM die Objekte in einer Bounding Box holt.
bye
Nop
@ Nop
Ok Dann also nicht +1km sondern +Fransen
Ich wollte natürlich wissen, was passiert, wenn man rechteckige Ausschnitte ohne Fransen verbindet.
Drum habe ich mit JOSM folgendes probiert:
Ich lade zwei verschiedene OSM-Dateien in zwei JOSM-Datenebenen. Die beiden Dateien überlappen sich mit ausgefransten Rändern.
Dann scheide ich mittels markieren / copy / paste aus jedem der beiden Dateien ein Rechteck aus und setze es jeweils in eine neue Datenebene. Diese Ausschnitte sind nicht ausgefranst, die über den Rand ragenden Objekte somit unvollständig.
Nun verbinde ich die beiden Ebenen zu einer. Ergebnis: die sich überlagernden Objekte verschmelzen. Es entstehen keine doppelten Linien oder Punkte. ABER: es entstehen eine Menge unverbundene Knoten ohne physische Merkmale. Ihnen sind die Verbindungslinien verloren gegangen. Ein Teil der Linien ist aber erhalten geblieben. Nach welchem Prinzip Linien verloren gehen oder auch nicht, versuchte ich nicht zu ergründen. Sieht aber ganz danach aus, daß die Linien verloren gingen, die durch den Rechteckausschnitt gekappt wurden.
Den Schrott hab ich dann gelöscht.
Nun die beiden Ebenen mit den originalen ausgefransten Dateien verschmolzen.
Das sieht auf den ersten Blick gut aus.
Erhebt sich dann aber folgende Frage:
Was passiert mit großen, nicht vollständig geladenen Relationen?
Aber das verfolge ich jetzt mal nicht weiter.
Gruß
tt
Theorie, Theorie. Bla, bla. 
Warum ladet Ihr nicht einfach mal schnell eine OSM-Datei in einem Texteditor (beispielsweise so ein kleines Ding wie Monaco)? Dann seht ihr, was da drin steht. Es ist überhaupt nicht magisch. Eigentlich völliger Klartext, den jeder verstehen kann. Wirklich!
Und zweitens: Ich habe doch oben geschrieben, dass ich BaWü und Bayern mit osmchange verbunden habe. Und dass ich damit ganz normal routen kann. Von Bayern nach BaWü und umgekehrt. ⇒ Es geht.
@tippeltappel: Es gibt eine Windowsversion von osmchange. Du kannst also mal Deinen kleinen Rechner aufheizen (dürfte gar nicht lange dauren, bei der geringen Datenmenge). Ich schätze das dauert 10 bis 15 Minuten.
Allerdings gibt es pbftoosm wirklich nicht für Windows. Achso. Das meintest Du wohl. 
Du kannst aber probeweise auch bz2-Extrakte statt pbf-Extrakte verwenden. bzip2 gibt es für Windows (ist z.B. bei 7zip oder Rar enthalten, glaube ich). Allerdings gibt es bei Windows keine Named-Pipes, weshalb Du viel Festplattenplatz brauchen wirst.
Hallo miteinander, jetzt muss ich mich hier doch mal einschalten. 
Du machst Sachen! Ist das denn erlaubt?
Auf die Idee bin ich noch gar nicht gekommen, dafür war osmchange gar nicht gedacht. Aber wenns funktioniert… und das muss es eigentlich! osmchange ist sehr einfach programmiert. Es frisst alles, prüft so gut wie nichts.
Immer dann, wenn zwei oder mehr Eingabedateien ein Objekt (Node, Way oder Relation) mit dem gleichen ID enthalten, wird das Objekt auf der zuletzt genannten Datei verwendet. Das ist die Datei, die dem Programm osmchange beim Aufruf als rechteste übergeben wurde.
Die Anweisungen “Create” und “Modify” (gibt es in .osc-Dateien) werden von osmchange ignoriert - sie sind eh unnötig. Nur die Anweisung “Delete” wird beachtet, in diesem Fall wird das betreffende Objekt gelöscht.
Sehr interessante Frage!
Das kommt wirklich drauf an, wie die Extrakte bei Geofabrik erstellt werden. Wenn bei grenzüberschreitenden Wegen nur die Nodes gelöscht werden, die außerhalb liegen, aber die betreffenden Referenzen in den Weg-Objekten erhalten bleiben, dann klappts. Werden hingegen auch die (dann ins Leere laufenden) Referenzen gelöscht, dann gehts nicht.
Wenn ich z.B. mit pbftoosm Europa in kleine Stücke zerteile, kann ich über den Parameter --drop-brokenrefs angeben, ob diese Referenzen auch entfallen sollen.
Bräuchte man in den .osm-Dateien ja nur mal zu Fuß anschauen: Einen Weg oder einen See auswählen, der über die Grenze geht und dann das XML-Objekt mit osm.org/browse/way/xxxx vergleichen. Natürlich auch schauen, ob die betreffenden Nodes in der Datei sind. Vielleicht mach ich das bei Gelegenheit.
Ja! Man kann das Zeug wirklich lesen - und von Hand editieren. Ich nehm für solche Testzwecke meistens das Bundesland Bremen, ist auch nicht zu groß.
pbftoosm kann unter Windows mit MinGW übersetzt werden. Falls jemand diesen Compiler unter Windows installiert hat, möge er das bitte tun und die Exe dann allen zur Verfügung stellen. Ich kanns leider nicht, denn MinGW unter Linux hat Probleme mit dem Verlinken der zlib.
Schöne Nacht euch!
Kleiner Nachtrag:
Hab grad niederbayern.osm.pbf runtergeladen und einen Wald genauer angeschaut, der größtenteils in Österreich liegt, aber die Grenze zu Niederbayern schneidet. Der betreffende Weg - einschließlich aller Punkte (auch der österreichischen) in der Datei enthalten. Eigentlich zu viel des Guten, aber fürs einfache Mergen mit osmchange natürlich eher ein Vorteil als ein Nachteil.
Also: wicking hat Recht, das Mergen sollte mit den derzeitig von Geofabrik zum Download angebotenen Extrakten ohne Probleme mit osmchange klappen.
Was mir noch dabei aufgefallen ist: Bei Relationen verhält es sich ein bisschen anders. Dort sind häufig die Ralations-Objekte komplett, aber die referenzierten Wege fehlen. Vermutlich, weil sie außerhalb der Grenzen liegen. Das bedeutet aber, dass die Relationsobjekte nicht verändert werden, dass also ungültige Referenzen nicht gelöscht werden. Das ist ebenfalls gut so! Denn auch dann klappt das Mergen mit osmchange.
Falls es jemanden interessiert, im Detail:
wget download.geofabrik.de/osm/europe/germany/bayern/niederbayern.osm.pbf
wget m.m.i24.cc/pbftoosm32
./pbftoosm32 -i=niederbayern.osm.pbf -b=0,0,80,80 >n.osm
./pbftoosm32 -i=niederbayern.osm.pbf -b=0,0,80,80 --drop-brokenrefs >nn.osm
diff n.osm nn.osm |head -3
3783292,3783471d3783291
<
<
grep -m 1 “node id="60645425"” n.osm
Kann ich leider nicht bestätigen. Bei meinem Versuch saarland.osm und lorraine.osm zu verbinden traten die gleichen Fehler auf wie beim mergen mit osmosis, nämlich unterbrochene Wege. Das Routing schlägt fehl. Das mergen der deutschen Bundesländer funktioniert. Das hatte aber schon immer mit osmosis geklappt.
Speedpilgrim
Hallo,
Einen direkten Download-Link für die Windows-Version von “pbftoosm” und eine Anleitung wie es jeder selber bauen kann gibt es unter
http://forum.openstreetmap.org/viewtopic.php?pid=162140#p162140
Schöne Grüße
PA94
Hallo Hetzi,
habe gerade eine Karte aus Deinen Daten generiert. Kann es sein, dass hier im Grenzgebiet zu CZ nur ein relativ schmaler Streifen “Hinterland” in den Daten existiert?
Hier der Link: http://www.openstreetmap.org/?lat=50.09&lon=12.396&zoom=11&layers=M
Wäre es möglich, den Streifen noch ein wenig nach Osten hin zu erweitern?
Ansonsten - Danke für Deine Arbeit!
softcake
Stimmt, in dem Bereich ist der Polygonzug auf ca. 5km an der Grenze dran.
Wenn ich nächste Woche dazu komme werde ich nochmal einen neuen etwas erweiterten Polygonzug um .de machen und mit dem dann generieren.
Das Grundproblem wird aber wohl immer bleiben, irgendwo wird auch dann eine Kante sein, wo jemand doch noch 5 oder 10km weiter drauf haben möchte …
Markus
Ok, vielen Dank!
softcake
Seit letzter Woche habe ich den Polygonzug für .de nun umgestellt. Hat auch in der ersten Version etwas Probleme bereitet, da dem Splitter die 2GB an Speicher ausgegangen sind die er am 32bit Linux bekommen kann. Die neue Splitter-Version scheint da etwas an Speicher zu sparen, zumindest klappt es damit vorerst. (Version r171, alt war bei mir r123) Ist aber bei dem Wachstum von OSM mit den Luftbildern wohl nur eine Frage der Zeit bis .de auf 32bit Systemen zu teilen sein wird …
Zusätzlich generiere ich jetzt auch noch ein Italien .img. Mit den selben Styles wie die bisherigen Karten.
Markus
Hallo allerseits,
ich lese schon eine ganze Weile hier mit und bereite seit ca. 6 Monaten die Karten für meinen etrex selbst aus OSM-Daten. Dabei habe ich gestern zum ersten Mal den Datensatz Germany+ ausprobiert. Das ist genau das, was ich brauche, Danke!
Leider expandiert sich der momentane Datensatz zu über 26GB auf der Platte und auch die Bearbeitung im Splitter dauert quälend lange. Wäre es nicht möglich, diesen Datensatz im *.osm.pbf-Format zur Verfügung zu stellen? Die Verarbeitung und auch die Serverlast würden dadurch deutlich zurückgehen.
Ansonsten vielen Dank für die Mühe und weiter so!
Gruß, Uli
Nutze den Germany+ auch regelmäßig. Vielen Dank auch von mir!
pbf wäre schon praktisch.
Gruß, softcake
Hallo nochmal,
mir ist gerade etwas Seltsames aufgefallen. Wenn ich den Germany+50-Datensatz benutze, ist die deutsche Staatsgrenze in der Nordsee unterbrochen und einige ostfriesische Inseln sind nicht mehr vorhanden. Zunächst dachte ich, es wäre ein Problem des floodblockers, aber wenn ich den regulären Germany-Ausschnitt der Geofabrik nehme, sind die Inseln da und die Grenze in der Nordsee ist auch korrekt. 
Anbei noch ein Screenshot von Germany+50 aus QLandkarte: http://imageshack.us/photo/my-images/687/unbenannt2nm.jpg/
Seit ich die generate-sea Option mit dem coastlinefile nutze (http://www.fabianowski.eu/osm/coastlines/coastlines_europe-latest.osm.pbf), gibt es kein Problem mit dem Deutschlandextrakt der Geofabrik mehr.
Der Download des Europa Extraktes mit anschließendem Ausschneiden Deutschlands per osmosis ist damit passé.
Josef
