Hi Marqqs
Nachdem ich mir vor längerer Zeit pbftoosm mit kleinen batch-Dateien eingerichtet hatte und mit dem Workaround gut klar komme, hab ich mich bislang vor weiteren Updates “gedrückt”. Nun lese ich hier und in den anderen entsprechenden Threads wieder ein wenig mit und frage mich, welcher Vorteil die Nutzung von osmconvert gegenüber pbftoosm hat, wenn im Prinzip nichts anderes vom Programm erwartet wird, als einenen definierten Kartenausschnitt aus einer europe.osm.pbf auszuschneiden und mit -drophistory etwas einzudampfen. Für die anderen aufwändigereren Projekte ist noch keine Zeit. Aber ich probier es wenigstens mal aus. Bevor ich mich allerdings ans Testen mache, wüßte ich gerne noch, ob osmconvert auch unter win7 im 64-bit-System läuft, obwohl 32-bit dran steht. Und ob ich gegebenenfalls irgendetwas berücksichtigen muß, damit es korrekt funktioniert.
Wahrscheinlich dürfte es keinen Unterschied machen ob man osmconvert bzw. pbftoosm verwendet.
Vorteil von osmconvert das es von osmupdate verwendet wird, dadurch ist mann immer auf dem aktuellen Stand ohne in eine Downloadorgie zu verfallen (Das Europa-File ist da nach 15 min (natürlich je nach aktuallisierungs Intervall) uptodate) statt wieder mal fast 7 GB zu saugen.
Die Programme laufen problemlos auf win7 64bit.
Ich selbst starte osmvonvert (mit win7 und nem 2600er mit 16GB) 8 mal - da hab ich nach ca 4min aus dem Euopa-File 8 Länder ausgeschnitten.
Der Vorteil dürfte eventuell bei der Geschwindigkeit und der Vielfalt der Formate liegen. Dein Anwendungsgebiet hast du jetzt allerdings noch sehr eng gesteckt. Wenn du wie bei Quasilotte beschrieben Europa nicht jedesmal neu laden möchtest sondern lokal updaten ist osmconvert mit osmupdate und das o5m Format sicher die bessere Wahl.
Beide Programme laufen unter Windows7 64 Bit wie bereits bestätigt einwandfrei. Nur osmupdate möchte Administratorrechte haben. Dies ist aber ein Windowsbug und lässt sich durch umbenennen von update in einen beliebigen anderen Namen beheben.
Weiterer Vorteil ist der schnelle Support des Autors. Er kümmert sich einfach um seine Programme und ist Fehlermeldungen hinterher.
Das Anwendungsgebiet wird vorerst so eng gesteckt bleiben. Ein Kartenupdate erstelle ich vielleicht alle 1 bis 2 Monate. Manchmal sogar noch seltener. Da lohnt sich die Mühe nicht, ein Update mit Diffs einzurichten.
Das eingerichtete Workaround (Download abrufen, auf dem Desktop verlinkte batch starten und auszuschneidendes Gebiet anwählen, Composer starten und zu berechnende Karte anwählen) funktioniert mit den wenigen Klicks mal eben nebenbei.
Für neue (im Winter anzugehende) Projekte (thematisch ausgerichtete Routen-Overlays) werden vor allem die Filterfunktionen interessant sein. In pbftoosm hatte Marqqs ja schon verschiedene eingebaut. Wenn die jetzt nur noch in osmconvert weiterentwickelt werden, ist es natürlich sinnvoller, die batch-Dateien darauf abzustimmen.
Naja die Frage ist was du unter einrichten verstehst.
osmupdate old_file.o5m new_file.o5m
Alternativ auch mit pbf, wobei letzteres aufgrund der Dateistrucktur langsamer in der Verarbeitung. Auf Anfrage einiger Nutzer hat Marqs auch schon den Zeitstempel in pbf integriert. Das Programm sucht sich also nur beim erstenmal mit der Statistikfunktion den Zeitstempel des letzten Elemnts und lädt ab diesem Zeitpunkt automatisch alle Diffs als Daily Hourly und Minutely herunter.
Beim zweiten Update wird dann nur noch der Zeitstempel verwendet ohne die Datei nochmal komplett zu parsen. Außerdem lassen sich bei dem Update die Filter und Geografischen Bereiche gleich mit anlegen, so dass auch kein zusätzlicher Müll dazu kommt.
Bevor ich abzisch, noch eine kurze Bemerkung zur GUI.
Die Ansprache find ich lustig.
Aber das nur nebenbei.
Mich stört, daß die Auswahl nur ermöglicht, ein Ausgabeformat der Datei zu wählen, eine Möglichkeit, die Dateigröße zu reduzieren z.B. per -drop history aber nicht angezeigt wird.
Wenn ein Anfänger das Programm startet, kann es sein, daß er als erstes im Kopf hat “ich brauch eine osm-Datei”.
Daß er aber nur einen kleinen Ausschnitt z.B. aus der europe.osm.pbf benötigt, vergißt er in diesem Moment vielleicht, gibt zweimal hintereinander die 1 ein und hat dann eine unnötig große Datei auf dem Rechner.
Daher wäre ein Tipp für die beste Vorgehensweise nicht schlecht:
“Wenn Sie einen Ausschnitt der Datei im *.osm-Format benötigen, schneiden Sie am besten zuerst den gewünschten Kartenbereich aus und convertieren Sie anschließend das Ergebnis in das gewünschte Format. Geben Sie daher zuerst die 4 und dann die 1 ein.”
Bei der Eingabe des Minimum-Längengrades bin ich dann gescheitert, weil eine Antwort wie “Sorry, das hab ich nicht verstanden.” dem Anwender nicht weiterhilft. Da wäre ein Beispiel für das erwartete Eingabeformat nützlich.
Grundsätzlich wäre es schön, wenn der Anwender beim Bedienen der batch-Datei lernen könnte, wie der “Befehlebaukasten” funktioniert.
Kommentare wie “Das geht in Ordnung.” sind eine wichtige Erfolgsmeldung. Mir wäre allerdings lieber, wenn ich sehen könnte, welcher Befehl durch meine Eingabe aktiviert wurde.
Na, das liest sich simpel, setzt allerdings voraus, daß das Update regelmäßig erfolgt. Doch so oft brauch ich das ja nicht.
Mein erster Versuch mit den Diffs ist schon ein paar Monate her. Da hab ich mir von Hand die Diffs von mehreren Tagen heraus gesucht und mit Osmosis herumexperimentiert.
Das bekam ich nicht auf Anhieb auf die Reihe. Mein kleiner Internet-Rechner “verschluckte” sich an den Datenmengen und der Zugriff auf das www war in dieser Zeit total blockiert. Nachdem ich dann viel Freizeit investiert und die Erkenntis gewonnen hatte, daß mit einem sporadischen Download der kompletten europe.osm.pbf das Leben wesentlich leichter ist, hab ich das Diff-Update nicht weiter verfolgt.
Beim Update die Filter und geografischen Bereiche gleich mit anlegen, ist natürlich eine gute Idee. Wenn ich bastele, benötige ich allerdings unterschiedliche Filter und wechselnde geografische Bereiche. Da benötige ich dann doch wieder die komplette europe.osm.pbf.
@ quasilotte
Sorry, hatte Dein Post übersehen.
Nach ca 4 Minuten 8 Länder aus dem Europafile ausgeschnitten ist natürlich ein Wort!
Droppst Du gleichzeitig die History?
Nochmal Es ist so einfach wie es aussieht. Du musst osmupdate nur die alte Datei vorwerfen und sagen schreib mir eine aktuelle daraus. Der Rest wird vom Programm erledigt. Download mergen etc. du hast am Ende nur die fertige Datei. Musst dich also um nichts kümmern.
Osmosis hingegen benötigt jede Menge Steuerungsdateien und lädt dann auch immer nur einen Typ von Diffs herunter.
osmupdate hingegen ist sehr effizent.
Nein, osmconvert ist eher etwas langsamer als pbftoosm, allerdings nur 1 oder 2 Prozent. Der Grund, warum pbftoosm nicht mehr empfohlen wird, ist ein ganz einfacher: ich habe nicht die Zeit, beide Programme gleichzeitig zu warten und auch noch weiterzuentwickeln. Da osmconvert alles kann, was pbftoosm tut, will ich mich in erster Linie um osmconvert kümmern, das übrigens damals aus dem Quellcode von pbftoosm entstanden ist. osmconvert ist also eine Weiterentwicklung von pbftoosm.
OK, ich werd drüber nachdenken, wie ich das im Dialog unterbringen kann. Grundsätzlich soll “Bert” aber nicht ausufern, er war erstmal nur für diejenigen gedacht, die das Programm mangels Kommandozeilenerfahrung sonst überhaupt nicht nutzen könnten.
Naja, der Nutzer kann ja direkt “14” eingeben. Oder “1,4” oder “1 4” oder “4 1” oder “1 ; 4” - das Programm akzeptiert da vieles.
Stimmt! Welcher Syntaxfehler ist dir passiert? Die Eingabeaufforderung könnte wirklich klarer formuliert werden, richtig.
Ja, gute Idee. Scheiterte bisher daran, dass intern gar kein echter Kommandozeilenbefehl erzeugt wird. Aber man könnte trotzdem einen generieren.
EDIT zum Thema Update:
osmupdate ist sicher ein geschicktes tool, aber wenn du wirklich nur alle 3 oder 6 Monate updaten willst, dann wärs aus meiner Sicht sinnvoller (und einfacher), die Dateien komplett neu runterzuladen. Ich persönlich würde osmupdate dann verwenden, wenn Updates im Abstand von 3 Wochen oder kürzer geplant sind. Das kommt natürlich auch auf die Größe der zu aktualisierenden Region an. Bei europe.pbf rentiert sich das viel eher als z.B. bei bremen.pbf. Im Fall von Bremen sind die täglichen Updates schon größer als die ganze Bremen-Datei - wenn ich mich jetzt nicht verschätzt hab.
Und wie lange dauert das?
Wenn ich das richtig verstanden habe, muß man sich dann mehrere Dateien herunter laden. Richtig? Aber das organisiert das neue Programm im Gegensatz zu OSMOSIS jetzt selbst. Was natürlich eine große Erleichterung ist.
So etwas ähnliches habe ich schon irgendwo gelesen. Ist ja kein Problem.
Solange die fertigen batches funktionieren, lasse ich die mit pbftoosm laufen.
Wenn ich was Neues bastel, probiere ich es dann also mit osmconvert.
Muß mir die Hilfe-Seite --help noch einmal in Ruhe ansehen/übersetzen. In der Eile heute Morgen habe ich die --drop-Optionen nicht gesehen. Drum nahm ich an, die funktionieren in dem Programm nicht.
Das ist bei mir auch von vorn herein so angekommen. Und --drop history wäre auch die einzige --drop-Option, die mir an dieser Stelle sinnvoll erscheint.
In welcher Reihenfolge die Optionen eingetragen werden ist demnach völlig egal?
Damit hatte ich nicht gerechnet.
Zuerst habe ich einfach nur eine ganze Zahl eingegeben.
Die verstand Bert nicht.
Dann habe ich 7° daraus gemacht.
Bert begriff immer noch nicht, was ich wollte.
Nach dem nächsten mißlungenen Versuch war Bert “beleidigt” und ich mußte weg.
Schön, daß man in der nächsten Version sieht, was passiert.
Moin Marqqs
In der aktuellen Version von -h und --help fehlt der Eintrag für --drop-history tatsächlich.
Außerdem finde ich keinen Hinweis auf die --keep Optionen.
In pbftoosm gibt es die Möglichkeit die Ausgabedatei zu komprimieren:
./pbftoosm < norway.osm.pbf | gzip -1 > norway.osm.gz
In --help von osmconvert ist diese Möglichkeit nicht dokumentiert.
GUI
Nach der Erläuterung … wäre das ihr Kommando gewesen: …
blinkt der Cursor unterhalb der ----------
Ein Anfänger könnte sich fragen, was nun los ist, wenn da keine Eingabe möglich ist.
Ein Hinweis wie “Berechnung läuft …” wäre da ganz hilfreich.
Gruß und dickes Dankeschön!
tt
Edit
Die Option heißt --keep und nicht --get. (Gedankenfehler - Sorry.)
Hallo tippeltappel,
freilich fehlt “–drop-history”, weil es diese Option schon lange nicht mehr gibt. Sie wurde aufgeteilt in --drop-author und das radikalere --drop-version.
Für viele Anwendungsfälle wird nämlich die Versionsnummer benötigt, der Rest der so genannten Metadaten aber nicht. Dafür kannst du --drop-author verwenden. Soll zusätzlich auch die Versionsnummer gelöscht werden, dann verwende --drop-version. Die Größenunterschiede von Dateien mit und ohne Versionsnummer sind allerdings gering, so dass --drop-author nun der Standardfall ist.
Das Komprimieren übernimmt in diesem Fall ja nicht osmconvert, sondern ein externes Packer-Programm, z.B. bzip2 oder gzip oder lzop. In den Beispielen bei --help ist eine solche Zeile zu finden. Vielleicht ist das doch etwas zu versteckt. Das Thema wär aber auch etwas für die Wiki-Seite.
Hmmm… drüber steht ja eigentlich
Einen Moment bitte - ich arbeite fuer Sie.
Falls die Eingabe-Datei sehr gross ist, dauert das einige Minuten.
Oder meinst du eine andere Stelle im Programmlauf?
Danke für deine konstruktive Kritik!
Ach ja: Der Bert in 0.4M kennt nun --drop-author (nicht wundern, die Nummerierung der Funktionen hat sich bei dieser Gelegenheit auch geändert).
Hmmm. Das wußte ich nicht.
Ich hatte die Option --drop-history so verstanden, daß die ganzen Veränderungen, die ein Objekt im Laufe der Überarbeitungen erfährt, aus der Datei entfernt werden und nur die jüngste Version erhalten bleibt. Diese Reduktion beschleunigte dann die Weiterverarbeitung, weil beim Rendern der Karte für jedes Objekt nur noch eine Version ausgelesen werden mußte. Dabei ging dann allerdings die Versionsnummer verloren. Als klar wurde, daß dies bei manchen weiterführenden Arbeitsschritten zu Problemen führte, wurde ein Weg gefunden, eine Ersatz-Versionsnummer (fake) einzufügen.
–drop-author hatte ich so verstanden, daß spezivische Autorenangaben ausgegrenzt werden.
Zitat aus --help
For most applications the author tags are not needed. If you specify this option, no auther information will be written: no changeset, user or timestamp.
Das bedeutet für mein Verständnis aber nicht, daß alle Vorgängerversionen der Objekte ausgegrenzt werden.
Das sehe ich dann wohl falsch. Oder?
Das Beispiel habe ich gesehen. Wie muß ich das jetzt verstehen? Ist der Packer in osmconvert irgendwie integriert oder muß er separat auf den Rechner geladen werden oder greift osmconvert auf einen Packer zu, der standardmäßig irgendwo in einem Betriebssystem enthalten ist/sein könnte? Eine Erläuterung wäre da wirklich hilfreich.
Nein, Du hast mich schon richtig verstanden.
Wenn man die Zusammenhänge durchschaut, ist ein weiterer Hinweis natürlich eigentlich überflüssig, weil doppelt gemoppelt.
Nur wenn man keine Ahnung hat oder zumindest aus der Übung, dann versteht man das Blinken unter Umständen als Aufforderung, irgendetwas zu tun. Nur dann ist alles blockiert und nichts geht. Der vorher so hilfreiche Bert reagiert nicht mehr und ein ratloser Anfänger hat dann keine Idee, was er machen soll. In diese Falle bin ich im ersten Moment auch getappt. Nur war ich dann nicht ratlos, sondern habe noch einmal nach oben geguckt … Ist nun Geschmacksache, ob man den Anwender da selbst drauf kommen lassen will, oder ihm auf die Sprünge hilft.
Hab’s gerade ausprobiert.
Dabei entstand noch ein Wunsch.
Könntest Du eine Art “Rücksprungschleife” einbauen, daß man alternativ zwischen C (=Abbruch) und R(=Abbruch der laufenden Aktion & Rückkehr zum Menüanfang) wählen kann?
Soeben verwechselte ich bei der Zahlenauswahl den Menüpunkt Polygondatei und manuelle Koordinateneingabe. Daraufhin “quengelte” Bert logischerweise, daß meine Eingaben nicht seinen Vorstellungen entsprechen und mir blieb nur der C-Ausstieg. Ein Rücksprung ins Menü wäre da komfortabler gewesen.
Hallo tippteltappel,
nur mal ganz kurz, ich muss gleich los.
History
In den normalen .osm-Dateien oder .pbf-Dateien (z.B. von geofabrik.de) sind gar keine Historien-Daten enthalten. Dort gibt es zu jedem Objekt immer nur die allerneueste Version. Anders sieht es aus bei so genannten “Full History Files”. Wenn du ein solches haben solltest, kannst du die jeweils veralteten Objektversionen mit --merge-versions rauswerfen. Aber, wie gesagt, du hast sehr wahrscheinlich nur “normale” Dateien vorliegen.
Packer
Nochmal: osmconvert kann zwar .gz-Dateien entpacken, aber gar keine Dateien komprimieren. Das Programm enthält weder einen Packer, noch ruft es einen externen Packer auf. Das Missverständnis entsteht vermutlich dadurch, dass z.B. “| bzip2 >x.osm.bz2” am Ende der Zeile steht. Diesen Teil der Zeile bekommt osmconvert gar nicht zu sehen, er wird von deinem Betriebssystem (in dem Fall von Windows) interpretiert. Das heißt, Windows ruft den Packer “bzip2” auf - sofern er installiert ist. Bei Linux gehören solche Packer in aller Regel zum Standard.
Rücksprungschleife
Auch hier ist es so, dass nur Strg-C abgefangen werden kann. Das erledigt das Betriebssystem und gibt dieses “Abbruch-Signal” ans Programm weiter. Andere Sondereingaben sind meines Wissens nicht möglich, hier lass ich mich aber gern aufklären, vielleicht hat jemand eine praktikable Idee.
Ansonsten halte ich Rücksprünge für unterschiedliche Ebenen zwar für hilfreich, aber sie machen die Bedienung nicht übersichtlicher. Dein Vorschlag ist aus meiner Sicht zwar gut, aber ich bin mir nicht ganz sicher, ob wir ihn umsetzen sollten.
Schau mal in die Dateien rein. Die Extrakte zum runterladen sind eigentlich alle nur mir visible=true und in der letzten Version des Objektes ausgestattet. Anders ist es nur beim Fullhistoryplanet.
Also der der Planet hat als bz2 derzeit 18GB und als fullhistory sind es 28GB
In osmconvert ist kein Packer oder Entpacker mehr dabei. Vielmehr muss dieser vom Betriebssystem bereitgestellt werden. Für Windows empfehle ich dir 7Zip der ist vielleicht nicht der schnellste, versteht aber fast alle Formate die in OSM eine Rolle spielen und ist opensource.
Daumen hoch
