primitive Tag-Änderungen mit osmconvert

Hallo zusammen,

weil ich immer mal wieder einen entsprechenden Anwendungsfall hatte, habe ich das Programm osmconvert (und osmfilter) nun um eine einfache Funktion zur Massenänderung von Tags erweitert. Bevor jetzt jemand erschrickt: Mit “Massenänderungen” sind nur Änderung auf Dateiebene gemeint. Manchmal braucht man so etwas, um die nachfolgende Verarbeitung von OSM-Daten zu vereinfachen.

Syntax:

--modify-tags="schluessel=wert to neuer_schluessel=neuer_wert"

Wildcards sind erlaubt, auch durch Weglassen von Elementen. Zum Beispiel:

--modify-node-tags="schluessel= to neuer_schluessel="
--modify-relation-tags="=wert to neuer_schluessel=neuer_wert"
--modify-tags="schluessel=wert* to neuer_schluessel=neuer_wert"

Hinzufügen von neuen Tags geht auch:

--modify-way-tags="schluessel=wert add zusatzschluessel=zusatzwert"

Wie schon von osmfilter her bekannt, sind auch Vergleiche möglich:

--modify-node-tags="maxheight<2 add kopf_einziehen=yes"

Hab mir gedacht, ich sag hier Bescheid, vielleicht braucht auch jemand anders sowas – oder hat weitere Ideen dazu – oder weiß, wie es viel einfacher gegangen wäre. :slight_smile:

Grüße
Markus

Schön, aber wenn du deine Wikiseite etwas pflegen würdest was die Versionen betrifft, hätte ich das auch in die Releases-Tabelle der Wochennotiz und der WeeklyOSM übernehmen können. Ansonsten dauert das mal wieder mehrere Jahre, bis plötzlich irgendwo eine Mail oder wie hier ein Forenbeitrag auftaucht, der dann zufälligerweise zu mir findet. Eigentlich schade für so ein wichtiges Programm.

Gruss
walter

Hallo Walter,

da hast du Recht, für die einzelnen Programme (osmconvert, osmfilter, osmupdate) gibt es kein vernünftiges Changelog. :frowning:

Was es aber wenigstens gibt, ist eine grobe Übersicht im Repository, denn nach allen größeren Änderungen wird eine neue “osmctools”-Version erstellt, die dann auch Eingang in die Debian-Welt findet und dort als Paket zur Verfügung steht.

https://gitlab.com/osm-c-tools/osmctools/tags

https://packages.debian.org/experimental/osmctools

Viele Grüße
Markus

Erstmal finde ich es gut, dass du die Programme osmconvert und osmfilter kontinuierlich pflegst. Für die Freizeitkarte-Android verwende ich osmfilter um Objekte (beliebig) manipulieren zu können. Hierbei werden die Tags eines Objektes ganzheitlich betrachtet. Sowohl die Keys, als auch die Values der Tags, können verändert werden. Ebenso können neue Tags hinzugefügt, oder vorhandene Tags gelöscht werden. Hier mal ein Code-Beispiel: name=“Gasthof Meier” → name=“3* Gasthof Meier”

...
// Hotel ohne Restaurant (mit Beruecksichtigung der Hotel-Kategorie)
  else if ( TAG_EXISTS(tourism, "hotel") && KEY_EXISTS(stars) && KEY_EXISTS(name) ) {
    FOR_ALL_TAGS
      if (strcmp (*keyp, "name") == 0) {
        snprintf (fzk_value, sizeof(fzk_value), "%s* %s", valp_stars, *valp);
        TAG_WRITE(*keyp, fzk_value)
      }
      else {
        TAG_WRITE(*keyp, *valp)
      }
    END_FOR_ALL_TAGS
  }
...

Anregung für die Nice-To-Have-Liste: Implementierung eines allgemein gültigen Regelwerkes zur (ganzheitlichen) Manipulation von OSM-Objekten. Vermutlich ist das aber alles andere als trivial und nicht mal “so schnell” implementiert.

Gruß Klaus

Kurz was zur Technik, mit der ich die Releases-Liste für meine Webseite, die Wochennotiz und weeklyOSM erstelle:

Ich habe eine Tabelle mit zu beobachtender Software bestehend aus u.a. einem Url der zu überprüfenden Seite und einem eindeutigen Pattern, was sich auf dieser Seite befindet oder befinden sollte.

Dazu lasse ich am Montag einen Job laufen, der überprüft, ob sich dieses Pattern immer noch auf der Webseite befindet. Wenn ja, ist alles ok und wenn nein, muss ich halt manuell nachsehen, was sich geändert hat.
Typisch: von derzeit 100 überwachten Softwareprodukten haben sich in der letzten Woche genau 14 geändert.

Ich kann aber nur prüfen, ob dieses Pattern existiert oder nicht.

Beispiel: Auf meiner Github-Seite https://github.com/wambacher/NoFarm (und auf fast allen anderen Github-Seiten) ändert sich der “N releases” - String, wenn eine neue Release freigegeben wird.

Leider kann ich das auf Gitlab nirgendwo finden.

Auf der Tags-Seite von Gitlab wird wohl irgendwann “0.8” auftauchen, aber das “0.7” bleibt weiterhin dort stehen. Pech für mich :frowning:
Auch auf allen anderen Gitlab-Seiten finde ich keinen Hinweis auf die “current release” - wenn ich da was übersehen hab, bitte Info. Dann wäre das Problem erledigt.

Vorschlag: Erstelle ein README, wo ein Satz zur aktuellen Release drin steht und das würde allen helfen: https://gitlab.com/osm-c-tools/osmctools. oder schreib es ins Wiki. Egal wo, nur an einem festen Platz.

Danke und Gruss
walter

Ein Feed reicht Dir nicht? Oder ein Mailabo?

Nein. Und warum, steht oben.

Hallo Klaus,

sehr schön gemacht! Sogar anwenderfreundlich mit geschickten Code-Makros.

Hab mir deinen Vorschlag gestern mal durch den Kopf gehen lassen, aber du hast wohl recht, das ufert aus. Wenn man die Funktion wirklich universell einbauen wollte, landet man sehr schnell bei einem Interpreter, und das widerspricht dem grundsätzlichen Ansatz des Programms, das ja schnell sein will. Bleibt noch der Weg über einen automatisch selbstgenerierten Code, aber das wäre wirklich etwas Größeres…

Hallo Walter,

danke für die ausführliche Erklärung zu deiner Versionsauswertung!

Die gitlab-Seite hat einen solchen Release-Zähler leider wirklich nicht, und um ein Readme müsste ich mich dringend kümmern. Aber vielleicht könntest du auf https://gitlab.com/osm-c-tools/osmctools/tags nach dem ersten Vorkommen von “tags/” suchen. Direkt danach steht dann die aktuelle Versionsnummer. Beispiel:

<a href="/osm-c-tools/osmctools/tags/0.7"><span class="item-title">

Das wären dann aber nur die größeren Paketänderungen.

Für kleinere Änderungen/Bugfixes/Erweiterungen müsste man auf die Programme selbst schauen. Falls dein Scan gescriptet ist, kriegst du die Versionsnummer direkt aus dem Quellcode der Programme. Beispiel:

wget -q m.m.i24.cc/osmconvert.c -O -|head|grep VERSION|cut -d \" -f 2

Desgleichen für “osmfilter.c” und “osmupdate.c”. Wäre das ein Weg?

Eine weitere Möglichkeit, derer ich mich bediene um auf neue Versionen zu checken, wäre folgender Aufruf:

wget --quiet --server-response --spider m.m.i24.cc/osmconvert.c 2>&1 | grep “Last-Modified:” | grep -o “[0-9]* [A-Z[[a-z]* [0-9]*”

Lässt sich auch hervorragend mittels $(…) in eine Variable packen.

Grüße
Mario

Nee, ich kann (mit meinem jetzigen Script) nur auf existiert/existiert schauen.

Technisch schon aber ich werde den Aufwand wohl nicht treiben. Ich kann es wirklich nicht verstehen, wieso ein winziges README oder ein Satz im Wiki nicht machbar sein soll. Schliesslich haben deine Anwender genauso ein Problem, falls sie die Gitlab-Seite nicht kennen.

Gruss
walter

Ist doch kein Problem. Ich sag ja, ich muss mich dringend drum kümmern und werde das auch tun. Als vorläufiges Mini-Readme habe ich ein paar Zeilen reingestellt, in denen auch die aktuelle Versionsnummer genannt wird. Ist das Format so in Ordnung?

https://gitlab.com/osm-c-tools/osmctools

Absolut, Danke

und wenn du das Format änderst (z.B. Current Version: 0.7 —> Current version is 0.7) krieg ich das auch mit, da ich halt den ganzen String abfrage.

Gruss
walter

So sehen die Basisdaten bei mir jetzt aus.

Bin mir nicht ganz sicher über die Plattformen, wo das Zeug läuft.

Gruss
walter

Sauber! Du hast die Auswertung wirklich professionell aufgezogen. :slight_smile:

Bei den Plattformen bin ich mir selber nicht so ganz sicher. Da sind zum einen die Architekturen, für die es Debian-Pakete gibt ( https://packages.debian.org/search?keywords=osmctools&searchon=names&suite=all&section=all ), zum anderen die üblichen Verdächtigen wie Windows und Mac (eine Version für OS X von User:MotorKUH wurde im Wiki verlinkt).

Der Versionscheck-URL sieht mir noch ein wenig merckgewürtzig aus.

–ks

Geh mal einfach davon aus, dass der noch länger ist.

Gruss
wal

Warum nicht gleich auf den Punkt kommen? Das http://wik am Anfang ist einfach zu viel und muss weg.

Eigentlich wollte ich ja zum Thema des Threads etwas schreiben: osm2pgsql hat bspw. ein generisches Tag rewriting auf Basis von lua drin. Ist wahrscheinlich für osmconvert dennoch Overkill, obwohl es zumindest ohne neukompilieren auskommen würde.

tnx.

Sorry. Ich dachte, das fällt auf.

–ks