GUI für osmconvert

Ok, ok, der Thread-Titel ist Etikettenschwindel. :wink:
Es ist kein GUI, es ist ein - wirklich primitives - Textinterface, also ein primitives “TUI”.

Mir ging es darum, eine Hilfe für die User anzubieten, die noch nie die Kommandozeile verwendet haben und es gewohnt sind, Programme einfach per Doppelklick zu starten. Deswegen meldet sich (ab Version 0.4C) eine sehr spartanische interaktive Hilfe, wenn das Programm ohne Parameter aufgerufen wird.

Das Design gefällt mir noch gar nicht. Wenigstens sind aber die wichtigsten Funktionen ausführbar.

Kritik willkommen!

Markus

EDIT:
OK, Link nachgeliefert: https://wiki.openstreetmap.org/wiki/DE:Osmconvert

Ein passender Link wäre nicht verkehrt :wink:

SCNR,
ajoessen

Hi,

  • Statt “Bustabentaste D” “Buchstabentaste D” oder einfach “Taste D”

  • Obwohl steht “… im gleichen Verzeichnis befindet wie Ihre OSM-Dateien”, wird ein
    /home/user/blub/blob/stern.osm
    oder ein
    data/blub/blob/stern.osm
    akzeptiert, was natürlich praktisch ist :wink:

  • Ich würde eine TAB-Funktion vermissen, sprich Filename-Completion

  • Das Programm legt Dateien mit 600 an obwohl mein user 644 als default hat (?)

Ciao,
Frank

Hallo Frank,

danke fürs Feedback. Text hab ich geändert. Das mit den kompletten Pfadangaben klappt leider nur bei Linux. Bei Windows müsste ich erst das Problem mit dem Backslash lösen, und das war mir für einen ersten Wurf zu aufwändig. Gleiches gilt für die Tab-Funktion. :slight_smile:

Dass dir das mit den Zugriffsrechten aufgefallen ist… - du schaust echt jedes Bit an. :slight_smile:
Das Problem liegt in der neuen Funktion write_open(), der Funktionsaufruf open() gibt 0600 als Maske mit. Vielleicht sollte ich da 0666 reinsetzen, denn die echte umask müsste die Bits dann ja entsprechend zusamenstreichen. Andererseits will nicht jeder User, dass seine Dateien gleich von allen gelesen werden können. Bin mir da noch unschlüssig.

EDIT:
Die “-o=”-Option hat übrigens einen Vorteil: das Programm kennt dann den Namen der Zieldatei (bei “>abc.osm” geht das ja nicht, da bleibt er Geheimnis der Shell).
Dadurch wird die Bedienung komfortabler, weil das Zielformat automatisch erkannt wird. Beispiel:

./osmconvert abc.o5m -o=abc.pbf

Das bisher notwendige “–out-pbf” ist in diesem Fall nicht mehr nötig. Außer, man will eine PBF-Datei mit dem Namen abc.osm erzeugen… :wink:

Also unter Windows war ich mit dem TUI leider erfolglos. Das Programm wollte sich nicht überreden lassen, die Datei planet-111012.o5m zu akzeptieren.
Als Fehlermeldung kam immer wieder sorry, die Datei muss auf .osm .o5m .pbf … enden. Diese Bedingung ist allerdings erfüllt. Kann ich sonst noch was beitragen um den Fehler zu finden?

Danke!
Das war ein typisches Linux/Windows-Problem. Linux beendet Zeilen mit LF, Windows mit CR/LF. Ähnliches gilt auf für die verstümmelten Umlaute. Ich kümmer mich gleich drum.

Recht herzlichen Dank. Ich habe noch ein Problem festgestellt.
Nachdem ich mir den Planeten als bz2 heruntergeladen habe, hatte ich weder mit Osmosis noch mit osmconvert die Möglichkeit diese datei umzuwandeln. Erst ein entpacken mit 7zip machte es möglich. Die bz2 Datei ist ca 19 GB groß. die daraus erzeugte o5m Datei ist 26 Gb groß und die pbf Datei ist immer noch stolze 14 GB. Außerdem wird eine aus der PBF Datei erzeugte o5m Datei 290 Kb größer als die aus der xml erzeugte.

So, gefixt, Version 0.4H ist oben.

Linux hat in aller Regel einen Entpacker für .bz2 an Bord, Windows meines Wissens aber nicht. Das Programm 7zip ist für sowas eine sehr gute Wahl! Damit müsstest du sogar das Entpacken und Umwandeln per “|” verbinden können, so dass du die entpackte .osm-Datei nirgends zwischenspeichern musst.

Osmosis bringt allerdings einen bz2-Entpacker mit - soweit ich mich recht erinnere. osmconvert kann selber nur ungepackte Dateien und .gz-gepackte direkt lesen (z.B. die Daily Changefiles 2011-*.osc.gz).

Zu den unterschiedlichen Größen: Wär interessant rauszufinden, inwieweit sich die Geofabrik-PBF-Datei von der Geofabrik-XML-Datei inhaltlich unterscheidet. Könnte auch sein, dass irgendwo ein Fehler ist - in einem der Programme, mit dem diese Dateien erzeugt werden oder in osmconvert. 290 kb sind zwar im Verhältnis zu 14 GB verschwindend wenig, aber verdächtig find ich das trotzdem.

Also den Planeten habe ich nicht von der Geofabrik geladen und gleich als bz2 geladen. Dann habe ich den entpackt und mit osmconvert in o5m gewandelt. Diese o5m Datei in pbf und zurück in o5m und erhalte jetzt 290Kb mehr als die Ausgangsdatei. Es hat also nichts mit Unterschieden von Quelldateien zu tun, sondern betrifft allein die Umwandlung von o5m in pbf und wieder zurück mit osmconvert.

Interessant. Einen solchen Test hab ich bisher nur mit .osm->.pbf->.osm durchgezogen. Da gab es keinen Unterschied. Ich werd mit .o5m auch nochmal experimentieren. Vielleicht komm ich auf den Grund…

Nachdem ich nun auch das Menü benutzen kann, sage ich erstmal sehr schön.
Zwei Sachen sind mir aufgefallen: 1. er fragt nicht wie meine Datein heißen soll.
2. “Bitte waehlen Sie die Nummer(n) von einer oder mehreren Funktionen:”
Diesen Satz sollte man vielleicht anders formulieren. Geben Sie bitte die Nummer(n) der Funtion(en) hintereinander [durch … getrennt] ein und beenden sie die Eingabe mit Enter.
Wie die weiteren Abfragen aussehen kann ich nicht beurteilen, da ich die Daten nicht ausschneide, aber eventuell macht es keinen Sinn sowohl Polygon als auch Längen und Breitengrade zum Ausschneiden gleichzeitig zu benutzen. Falls doch den Satz einfach ignorieren.

Achso und was auch noch genial wäre eine Fortschrittsanzeige in Prozent, damit der User weiß wieviel Ausgangsdatei schon bearbeitet wurde. Gerade bei dem Planeten ist man ja oft im dunkeln.

Du hast Recht, ich hab die Frage nach dem Namen der Ausgabedatei einfach weggelassen. Das Programm generiert selbst einen einigermaßen sinnvollen Dateinamen, den es noch nicht gibt. Das spart dem Benutzer eine Eingabe - natürlich wirds hinterher umständlicher, wenn er die Datei umbenennen muss, weil ihm der Name nicht gefällt. Kein Vorteil ohne Nachteil. :slight_smile: Ich lass mir das durch den Kopf gehen, vielleicht findet sich eine bessere Lösung.

Zu den Nummern der Funktionen:
Das Programm akzeptiert es, wenn man die Nummern gar nicht trennt. Beispiel: 135
Man kann sie aber auch trennen, erlaubt sind die Trennzeichen Komma, Strichpunkt und das Leerzeichen. Kurzum, das Programm frisst alles, was 99% der User in diesem Fall eingeben würden - denk ich.
Und stimmt, Polygon und Koordinaten gleichzeitig kann osmconvert nicht sinnvoll verarbeiten. OK, um ehrlich zu sein, ich hab noch nie probiert, was dabei rauskommen würde. :slight_smile: Beim Eingabedialog wird jedenfalls auf “3 und 4 gleichzeitig” geprüft und ggf. eine Fehlermeldung ausgegeben.

P.S.: Fortschrittsanzeige wär eine super Sache. Ich hab aber auch hier noch keine Idee, wie ich das einigermaßen zuverlässig und ohne großen Aufwand realisieren kann. :frowning:

Ich weiß nicht ob bekannt ist wie groß die Datei ist. Wieviel davon bearbeitet ist läßt sich ja durch einen Zähler problemlos auswerten. Ich vermute aber das du C++ typisch die Datei immer Brocken für Brocken einliest und dann auf EOF wartest. Das Betriebssystem kennt aber die Größe auf jeden Fall schon und vielleicht kann man auch irgendwie erst ans Ende springen und weiß dann wie groß die Datei ist, ohne das einmal komplett durchgelesen zu haben.

Ja, wenn nur EINE Eingabedatei verwendet wird und diese nicht per Pipe oder stdin eingelesen wird (also nicht per “|” und nicht per “<”), dann kann das Programm die Dateigröße abfragen. Bei mehreren Dateien brauchst du dann schon die Summe, und sobald du eine Region extrahierst, kommen noch temporäre Dateien ins Spiel, das heißt, das Einlesen der Original-Datei wird unterbrochen und nach unbestimmter Zeit wieder fortgesetzt.

Ein schlauer User hat den Balken mal per Programm pv (“pipe view”) realisiert. Das hat dann auch nicht in allen Fällen geklappt, aber die Idee fand ich pfiffig.

Das geht dann über meine C++ Kenntnisse hinaus.

pv ist ein Linux-Programm, das du unter Windows eigentlich auch per Cygwin installieren kannst.
http://linux.die.net/man/1/pv

Alternativ kannst du natürlich auch gleich Linux installieren. :wink:

Der Unterschied hat sich heute aufgeklärt: osmconvert hielt so genannte “leere Relationen” für nicht plausibel und hat sie beim Lesen von .pbf-Dateien verworfen. Ich hab das mit Version 0.4J geändert. Zwar wird vermutlich keiner was mit leeren Relationen anfangen können, aber das Programm soll sich beim sturen Umwandeln von Dateien transparent verhalten. Alles andere verwirrt nur.

http://wiki.openstreetmap.org/wiki/Empty_relations

Moin moin,

hab’ mal spasseshalber osmconvert mit clang compiliert. Selbst mit “-std=c99” waren die Fehlermeldugen die gleichen:


$ clang -o osmconvert osmconvert.c -lz -O3 -std=c99
osmconvert.c:2145:3: warning: implicit declaration of function 'gmtime_r' is invalid in C99 [-Wimplicit-function-declaration]
  gmtime_r(&vtime,&tm);
  ^
osmconvert.c:2264:8: warning: implicit declaration of function 'timegm' is invalid in C99 [-Wimplicit-function-declaration]                    
return timegm(&tm);
       ^
osmconvert.c:8690:29: error: variable has incomplete type 'struct sigaction'                                                                   
    static struct sigaction siga;
                            ^
osmconvert.c:8690:19: note: forward declaration of 'struct sigaction'                                                                          
    static struct sigaction siga;
                  ^
osmconvert.c:8693:5: warning: implicit declaration of function 'sigemptyset' is invalid in C99 [-Wimplicit-function-declaration]               
    sigemptyset(&siga.sa_mask);
    ^
osmconvert.c:8695:5: warning: implicit declaration of function 'sigaction' is invalid in C99 [-Wimplicit-function-declaration]                 
    sigaction(SIGPIPE,&siga,NULL);
    ^
6 diagnostics generated.

Eine Performaceverbesserung gegenüber dem gcc hab’ ich auch nicht festgestellt. Viellecht liegts daran, dass die mit Debian 6 mitgelierferte
Version schon zu alt ist:


$ clang --version
clang version 1.1 (Debian 2.7-3)
Target: x86_64-pc-linux-gnu
Thread model: posix

Einen icc hab’ ich nicht :wink:

Ciao,
Frank

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.

Viele Grüße
tippeltappel