Bedarf in Extrakt DE + 50 km

Hallo softcake

Um JAVA mehr Speicher zu geben, muss du eventuell die Auslagerungsdatei vergrößern. Damit sollte JAVA dann mehr als 50% des realen Hauptspeichers erhalten können.
So war das zumindest bei meinem virtuellen WinXP mit 1,25 GB Speicher. Nach Vergrößerung der Auslagerungsdatei konnte ich JAVA/JOSM dann 800+MB zuteilen. (900MB ging nicht mehr)

Edbert (EvanE)

Hallo Marqqs,

Bei mir tut’s unter MinGW einfach ein:


gcc -c pbftoosm.c

und ein anschliessendes


gcc -o pbftoosm pbftoosm.o -lz

Ergebnis: pbftoosm.exe mit 114.358 Bytes.

Allerdings musste ich “pbftoosm.c” vorher noch folgendermassen patchen, damit es das pdf-File binär öffnet:


1042a1043,1045
> #ifdef _WIN32
>     read__fd= open(filename,O_RDONLY|O_BINARY);
> #else
1043a1047
> #endif
3243a3248,3251
> #ifdef _WIN32
>   setmode(fileno(stdout), O_BINARY);
>   setmode(fileno(stdin), O_BINARY);
> #endif

(Mail mit Patch an Autor geht gleich raus…)

Viel Erfolg und schöne Grüße

PA94

Hallo Markus

Bedarf hätte ich eher an einem fertigen AIO Germany+ Image.
Wobei mein Bedarf auch davon abhängt, was ich in absehbarer Zeit an Unternehmungen plane.

Mir selbst Garmin-Karten zu erstellen, überfordert meine derzeitigen Kenntnisse.
Von daher Dank an dich und alle anderen, die das können und ihre Ergebnisse anderen zur Verfügung stellen.

Edbert (EvanE)

DANKE! :slight_smile:

Prinzipiell hast du recht, aber XP 32bit kann einer Anwendung nicht mehr Speicher zuweisen. :wink:

Manche Wünsche sind schon in Erfüllung gegangen bevor man sie gestellt hat :wink:
Es gibt unter http://140.78.94.22/osm/ bereits das aio-germany-custom.img ist mit dem germany+ Extrakt erzeugt worden ist.

Wenn irgendwo eine Ecke fehlen sollte, dann bitte melden. Bei der nach dem selben Prinzip erzeugten Österreichkarte hab ich so eine Ecke gehabt, die eigentlich innerhalb des Polygons und auch in Österreich lag, am resultierenden Garmin-Image dann aber doch fehlte, keine Ahnung warum eigentlich. Ich hab einfach den Polygonzug erweitert und damit passt es nun dort.

Markus

Mist, wieder nix! :confused:

Hallo,

Osmosis 0.39 funzt bei mir! Versuche gerade, einen winzigen Kartenausschnitt aus germany+.osm zu extrahieren. Der Vorgang selbst wird wohl ein wenig dauern. Denke, osmosis ist nicht das optimalste Werkzeug, um Daten aus einer großen Datei zu extrahieren.

Marqqs’ Vorschlag bezüglich pbftoosm klingt da schon vielversprechender…

Danke & Gruß

softcake

Edit 1: Bei weiteren (größeren) Ausschnitten legt osmosis ordentlich an Tempo zu. Seltsam. Leider meint Map_Composer beim Kartengenerieren “OSM file truncated” und bricht den Vorgang ab. Der input-Kartenausschnitt ist etwas größer gewählt als der output-Ausschnitt.

Edit 2: Mein Aufruf sieht so aus:
“c:\works\Programme\Osmosis-0.39\bin\osmosis.bat” --rx germany+.osm --bb left=11.1 bottom=49.7 right=12.9 top=50.7 clipIncompleteEntities=yes idTrackerType=BitSet --wx fichtelmap.osm

Passt doch soweit, oder?

Gut, oder besser schlecht.
An die 1600MB Grenze bin ich natürlich nicht gestoßen.

Edbert (EvanE)

Markus

Prima, die hatte ich mir gerade gestern geladen. :slight_smile:
Habe mal kurz kontrolliert, ein gutes Stück Holland ist im Bereich Emmerich/Kleve vorhanden.

Jetzt fehlen nur noch ein Fahrrad-Layer und Höhenlinien.
(Für die Reiter natürlich Reit- statt Radwege)

Edbert (EvanE)

Die in OSM als Rahrradrouten-Relation vorhandenen Radwege und auch Wanderwege sind im Garmin Image auch schon, als separater Layer, dabei. In dem Downloadverzeichnis ist aber auch dieser Layer einzeln vorhanden. Reitwege hab ich nicht drinnen, wären aber relativ leicht nach dem selben Schema wie Rad-/Wanderwege erweiterbar. Die Höhenlinien hab ich für meinen Bereich (Alpenregion) von der OpenMTB-Map Webseite, ich glaub die haben aber auch alle anderen Bereich Europas oder darüber hinaus.

Markus

Ich habe vor wenigen Tagen für odbl.de auch komplett auf pbf umgestellt, denn mit osmto geht das Entpacken und Ausschneiden (Polygon) extrem schnell (101 mal schneller als Osmosis und bzip2, 20 mal schneller als das alte pbf2osm und osmchange, 6 mal schneller als Osmosis und pbf).

Die Dateien werden durch pbf am stärksten gepackt und es geht viel schneller als mit gzip, bzip2 oder xz. Zum Packen verwende ich noch Osmosis, was natürlich nicht die beste Geschwindigkeit hat, aber es gibt noch keine schnellere Alternative. Und insgesamt ist es trotzdem schneller als mein vorher verwendetes lzo, weil pbftoosm das Ausschneiden eines Polygons jetzt integriert hat.

So wird beispielsweise Europa aktuell gehalten:


pbftoosm -i=planet-latest.osm.pbf -B=europe.poly | osmchange -B=europe.poly *_named.pipe | $OSMI --fast-read-xml - --wb europe.osm.pbf

Die Changesets einer Woche werden per Named-Pipes dort „eingeleitet" (im Flug entpackt und gleich verarbeitet). So:


for dailychange in $(ls *.osc.* | grep -v '\.pipe$'); do
    # create named pipes for each osc file
    mkfifo ${dailychange}_named.pipe
    zcat $dailychange > ${dailychange}_europe.pipe &
done

In Wirklichkeit sieht (auf dem „Berechnungsserver") das Ganze noch etwas komplexer aus, da mit tee und einer weiteren Named-Pipe die Ausgabe gleich noch an das Auswertungsskript weitergeleitet wird.

Hier noch ein paar Zahlen zur Packgeschwindigkeit und der resultierenden Dateigröße:


588 MB – bayern.osm.lzo – Dauer zum Packen: 0:57 min
351 MB – bayern.osm.gz – Dauer zum Packen: 2:08 min
287 MB – bayern.osm.bz2 – Dauer zum Packen: 20:09 min
217 MB – bayern.osm.xz – Dauer zum Packen: 42:19 min
181 MB – bayern.osm.pbf – Dauer zum Packen: 3:27 min

Ich empfehle von xz auf pbf umzustellen.

Hallo, ist das ganze wirklich schneller, als ein Update komplett über osmosis, auch wenn man den Planet komplett lässt und nicht Europa ausschneidet? Hast du da auch Erfahrung?

Um auf das eigentliche Thema dieses Fadens zurückzukommen:

Ich habe gerade Baden-Württemberg und Bayern mit osmchange verbunden und an Gosmore geschickt. Damit kann ich über den gesamten Bereich routen. Liegt das an der Primitivität von Gosmore oder ist das immer so einfach möglich, so dass die Idee „DE+50 km" total überflüssig ist?

Für Basel (Dreiländereck) würde man sich dann das Gebiet Elsass (alsace.osm.pbf), Baden-Württemberg (baden-wuerttemberg.osm.pbf) und die Schweiz (switzerland.osm.pbf) mit osmchange verbinden. Diese Methode ist schneller, als sich das aus ganz Europa rauszuschneiden. Und universeller als einen „Bla+50 km" oder so Extrakt zu finden (der erst mal erstellt werden musste).

Ohne es gemessen zu haben: Ja, denn mit Osmosis kann man immer nur ein Changefile gleichzeitig reinmischen¹. Mit osmchange dagegen beliebig viele. Oder ich habe es falsch verstanden.

¹) In der Anleitung steht folgendes:

Der fette markierte Teil des Satzes ist das Problem. Sonst könnte man einfach mit zcat 20110424-20110425.osc.gz 20110425-20110426.osc.gz mehrere Änderungen in einem Rutsch einfügen.

Die Idee, ein Download De+50 bereitzustellen, finde ich sehr begrüßenswert, da es den Nutzern von Grenzgebieten das Hantieren mit dem Europa-File erspart.
Die geringe Resonanz erkläre ich mir damit, daß sich 1. diese Möglichkeit bislang noch nicht herumgesprochen hat und 2. für den ein oder anderen Grenzkartenbastler ein De+50 bzw. der damit verbundene Rechenaufwand auch noch zu groß ist und man sich lieber mit anderen Methoden behilft, wenn nur ein kleiner Kartenausschnitt benötigt wird.

Die Methode, Teilextrakte mit osmchange zu verbinden, scheint mir daher für Kartenbastler, die sich nur für einen begrenzten Kartenausschnitt interessieren wesentlich zielführender zu sein, zumal diese Methode auf beliebige Bereiche anwendbar wäre.

@ Nop
Was meinst Du? Wäre diese Idee nicht eine interessante Funktionserweiterung des Composers? Oder ist das nicht realisierbar?

Gruß
tt

Ich bekomme beim verusch das File zu downloaden immer nee Fehlermeldung bzw. eine 1kb große Datei!!!

Vielleicht ist das auch ein Grund.

Von meiner Seite besteht durchweg ein Intresse an so einem OSM-Extrakt, auch unter den Hintergrund das ich keine Lust habe mich mit irgendwelchen Datenbanken usw. rumzuschlagen.

Gruß
Quasilotte

Du musst nichts mit Datenbanken machen. Du nimmst Dir einfach von http://download.geofabrik.de/osm/ (wie oben in meinem Beispiel mit Basel beschrieben) ein paar Extrakte um Dein Gebiet und verbindest sie mit osmchange. Fertig.

Beispiel:


osmchange -B=X.poly A.osm B.osm < C.osm > Ergebnis.osm

X.poly = Gebiet von Interesse, z.B. die Umrandung von Basel
A.osm = Gebiet links der Grenze
B.osm = zweites Gebiet links der Grenze
C.osm = Gebiet rechts der Grenze

Das „-B=X.poly" kann man auch weglassen, wenn man einfach nur A.osm, B.osm, C.osm komplett verbinden will.

Was der Welt fehlt ist also nicht ein +50km-Extrakt, sondern gute Doku. „Gut" = kurz und bündig und leicht verständlich.

Abgesehen davon ist pbftoosm so schnell, dass man auch beliebige Gebiete aus europe.osm.pbf ausschneiden kann. Dauert nur wenige Minuten + die Zeit des Herunterladens von 5,2 GB.

Irgendwie komm ich da nicht mit. osmchange dient laut Doku dazu, .osc updates auf eine .osm Datei anzuwenden. Es ist nicht dafür vorgesehen, mehrere .osm Dateien zu verbinden.

Hab gerade mal im Wiki geblättert http://wiki.openstreetmap.org/wiki/Pbftoosm
Bislang gibt es wohl noch keine Windowsversion.
Schade.

Hätte gerne mal probiert, ob mein kleiner Rechner die Zusammenführung von NRW RP B und NL schafft.

Über die Frage, wie ich die Datenmenge dann ausgewertet bekomme, denke ich noch nicht nach.

@ Nop
Wenn etwas für das eine erfunden wurde schließt es die Möglichkeit, daß es auch in einem anderen aber irgendwie ähnlichem Sinne verwendet werden kann doch nicht aus.

Ich rate mal:
*.oxc ist nichts anderes als ein osm-file nur halt eben mit “speziellem” Inhalt.
Beim Verbinden der Inhalte muß ähnlich wie in JOSM bei der Verbindung von mehreren Datenebenen ein Abgleich der Daten stattfinden, bei dem Objekte mit gleicher ID nicht dupliziert sondern upgedatet werden. Die Datenebenen in JOSM können geöffnet werden, indem man entweder auf dem Rechner liegende osm-Dateien aufruft oder ein Download startet. Vom Rechner aufgerufene Dateien müssen vor der Weiterbearbeitung upgedatet werden. Keine Ahnung, wie es funktioniert, aber ich stelle mir vor, daß das Programm in irgendeiner Form nach den Changes sucht.
In pbftoosm werden ebenfalls verschiedene separat auf dem Rechner geladene Dateien verknüpft. Ob diese Dateien nun zum einen ein Planetfile und zum anderen die Changes beinhalten oder zwei verschiedene Planetextrakte, die sich irgendwo überschneiden, scheint völlig egal zu sein.

Wäre nett, wenn die, die es besser wissen mal erklären, ob ich mit dieser Vorstellung halbwegs richtig liege oder ob das totaler Schrott ist. :wink: