osmfilter 1.2 released.  Neu:  and, or, =, !=, <, >, <=, >=, Klammern

chris66 · 2011-12-14T16:55:30.000Z

Zumindest wäre es mkgmap-kompatibel wenn es so rechnen würde wie in meinem Beispiel.
Tausender Trennungen (100.000) habe ich in den Daten noch nie gesehen, ich denke die
kann man ignorieren.
Vorschlag:
String ab dem ersten Buchstaben abschneiden, Komma durch Punkt ersetzen, umwandeln in Decimal und Vergleichen.

Tordanik · 2011-12-14T17:06:01.000Z

Marqqs:

extremecarver:

Doch einheiten sollten schon definierbar sein. Aber bitte als eigener tag etwa
maxspeed=50
unit:maxspeed=km/h

Dem stimm ich zu. Aber ich hab bei der Beschreibung zu “maxspeed” grad gesehen, dass laut Wiki auch Angaben wie “30 mph” erlaubt sind.

Die Angabe von Einheiten als Teil des Wertes ist eine übliche Vorgehensweise und aus Sicht des Mappings auch wesentlich einfacher und intuitiver. Das ist eigentlich schon vor Jahren gründlich diskutiert worden und inzwischen nicht nur im Wiki, sondern auch in den Vorlagen von Potlatch so verankert.

Die technische Aufgabe, mit Werten + Einheit umgehen zu können, ist also nun einmal da und man sollte sich lieber Gedanken machen, wie man sie sinnvoll löst.

Marqqs · 2011-12-14T21:30:02.000Z

viw & Tordanik:
OK, kann ich nachvollziehen. Dann, wenn unterschiedliche Einheiten gebräuchlich sind, wie z.B. km/h und mph, kann ich mir vorstellen, sie im gleichen Feld mitzuführen, quasi als Faktor. Das von chris66 angesprochene Problem ist ja auch lösbar.

chris66:

Vorschlag:
String ab dem ersten Buchstaben abschneiden, Komma durch Punkt ersetzen, umwandeln in Decimal und Vergleichen.

Stimmt, wäre eine brauchbare Lösung. Vorerst will ich aber bei dem Verfahren ohne Zahlensystemumwandlung bleiben, das heißt, ich vergleiche die einzelnen Zeichen direkt.

Der Algorithmus im Groben:
Zuerst führende Nullen überspringen, dann Ziffer für Ziffer vergleichen, bis entweder ein ‘.’ oder ein fremdes Zeichen kommt (Sonderzeichen, Leerzeichen, Buchstabe). Nach einem ‘.’ weiter vergleichen. Für die, die sich mit dem Code erschrecken wollen: die Prozedur heißt fil__cmp().

Neu eingebaut habe ich jetzt, dass der Vergleich ab dem ersten Sonderzeichen, Leerzeichen oder Buchstaben abgebrochen wird, das heißt, die angehängte Einheit verursacht keine “Störungen” und kann durch einen eigenen Vergleich ausgewertet werden - sofern benötigt (siehe mein letzter Beitrag).

Die Beta-Version ist hier: m.m.i24.cc/osmfilter_new.c
Fertig für Windows (für 32 Bit, aber auf 64 Bit lauffähig): m.m.i24.cc/osmfilter_new.exe

viw · 2011-12-15T06:21:11.000Z

Marqqs:

Der Algorithmus im Groben:
Zuerst führende Nullen überspringen, dann Ziffer für Ziffer vergleichen, bis entweder ein ‘.’ oder ein fremdes Zeichen kommt (Sonderzeichen, Leerzeichen, Buchstabe). Nach einem ‘.’ weiter vergleichen. Für die, die sich mit dem Code erschrecken wollen: die Prozedur heißt fil__cmp().

Neu eingebaut habe ich jetzt, dass der Vergleich ab dem ersten Sonderzeichen, Leerzeichen oder Buchstaben abgebrochen wird, das heißt, die angehängte Einheit verursacht keine “Störungen” und kann durch einen eigenen Vergleich ausgewertet werden - sofern benötigt (siehe mein letzter Beitrag).

Die Beta-Version ist hier: m.m.i24.cc/osmfilter_new.c
Fertig für Windows (für 32 Bit, aber auf 64 Bit lauffähig): m.m.i24.cc/osmfilter_new.exe

Das ist jetzt aber nur die Programmlösung für die erste Näherung oder?
Ich meine wenn ich versuche nach Maxspeed<50 (km/h) zu filtern und er mit 49 mph durchwinkt wäre das doch nicht das erwünschte Ergebnis.

kellerma · 2011-12-15T06:38:23.000Z

viw:

Ich meine wenn ich versuche nach Maxspeed<50 (km/h) zu filtern und er mit 49 mph durchwinkt wäre das doch nicht das erwünschte Ergebnis.

Also viw, gerade von Dir hätt’ ich da jetzt mehr erwartet

Man kann jetzt nicht verlangen, dass das osmfilterproggie sämliche Einheitensysteme dieser Welt und vergangener Zeiten beherrscht.
Schaut nur mal das an:
97625 4. Dez 05:05 bin/osmfilter
2856275 15. Dez 07:26 osmfilter

Wenn das so weiter geht mit Markus Programmen, muss ich ernsthaft an externe Festplatte für mein Netbook denken.
Oder gleich 'ne Cloud-Lösung

Wenn Du bei den Einheiten unsicher bist, dann kannst sie ja zur sicherheit gleich mal “vorfiltern” und ggf. korrigiern

Marqqs · 2011-12-15T06:41:36.000Z

viw:

Das ist jetzt aber nur die Programmlösung für die erste Näherung oder?
Ich meine wenn ich versuche nach Maxspeed<50 (km/h) zu filtern und er mit 49 mph durchwinkt wäre das doch nicht das erwünschte Ergebnis.

Was Besseres ist mir nicht eingefallen.
Ne, mal im Ernst: was soll das Programm machen, wenn die möglichen Einheiten vom User nicht vorgegeben werden? Im Programm einen Katalog mitzuführen, der für jeden Tag die zulässigen Einheiten enthält, ist aus meiner Sicht zu aufwändig und auch kaum pflegbar.

Für dein Abfragebeispiel wäre es dann eben notwendig, den Filter etwas ausführlicher zu definieren:

--keep="( maxspeed<50 and maxspeed!=*mph ) or maxspeed<30"

Wenn es sich um eine Abfrage für rein deutsche Daten handelt, kann man sich diese Verrenkung vermutlich sparen.

Marqqs · 2011-12-15T06:56:24.000Z

kellerma:

Schaut nur mal das an:
97625 4. Dez 05:05 bin/osmfilter
2856275 15. Dez 07:26 osmfilter

Uff, ich sehs auch grad. Wie konnte das passieren? Der Quellcode ist gar nicht sooo viel größer geworden. Gefällt mir nicht.

viw · 2011-12-15T09:46:00.000Z

Marqqs:

viw:

Das ist jetzt aber nur die Programmlösung für die erste Näherung oder?
Ich meine wenn ich versuche nach Maxspeed<50 (km/h) zu filtern und er mit 49 mph durchwinkt wäre das doch nicht das erwünschte Ergebnis.

Was Besseres ist mir nicht eingefallen.
Ne, mal im Ernst: was soll das Programm machen, wenn die möglichen Einheiten vom User nicht vorgegeben werden? Im Programm einen Katalog mitzuführen, der für jeden Tag die zulässigen Einheiten enthält, ist aus meiner Sicht zu aufwändig und auch kaum pflegbar.

Für dein Abfragebeispiel wäre es dann eben notwendig, den Filter etwas ausführlicher zu definieren:
--keep="( maxspeed<50 and maxspeed!=*mph ) or maxspeed<30"
Wenn es sich um eine Abfrage für rein deutsche Daten handelt, kann man sich diese Verrenkung vermutlich sparen.

Wahrscheinlich kann man sich das oft sparen. Wichtig wäre nur für den Nutzer, dass er darüber eine Information erhält. Wie “ich konnte beim vergleich nicht alle Zeichen berücksichtigen, da es unerwartete Werte gab.” Nächste Schritt wäre, wenn man sicher sagen kann das es Einheiten sind das Kind so zu nennen oder die Werte konkrett zu benennen. Wenn das nicht zu lasten des Speichers gehen soll schiebst du das am Besten in ein Log rein, wo der User das nachlesen kann welche Elemente nicht vollständig vergleichbare Elemente haben.
Aber du musst das nicht alles machen. Es sind einfach nur Ideen, was man von einem Programm vielleicht erwarten würde. Besonders wenn es ohne Fehler durchläuft hielte ich den Vergleich für schlicht falsch.

kellerma · 2011-12-15T13:09:21.000Z

@viw
Nenn mir bitte mal ein (Standard-)Programm uner Lin/Win/Mac, welches das kann, innerhalb eines value-strimgs!
Excel macht es nicht. Und wenn ich nur an die x-moeglichkeiten denke, dass Datum zu schreiben …

viw · 2011-12-15T13:21:01.000Z

kellerma:

@viw
Nenn mir bitte mal ein (Standard-)Programm uner Lin/Win/Mac, welches das kann, innerhalb eines value-strimgs!
Excel macht es nicht. Und wenn ich nur an die x-moeglichkeiten denke, dass Datum zu schreiben …

Ich weiß jetzt nicht worauf du dich beziehst. Aber ich denke das Excel/openoffice/libreoffice schon sehr viel kann. Dannw erden mir jedenfalls keine falschen Werte geliefert sondern die Werte einfach ignoriert. Das ist ein Unterschied zu der hier eingebauten Variante wo nur die Einheiten bzw. alles was wie string aussieht ignoriert wird und der davor liegende nummeriesche Wert den Ausschlag gibt. Erst dann kommt es nämlich zu dem geschilderten Verhalten.
Was das Datum angeht, sind diese beiden Programme sehr weit was die Erkennung angeht. Manchmal sogar zuweit, so dass sie ein Datum erkennen was keines ist. Intern wiederum wird ein Datum aber als Zahl gespeichert und in einem anderen String eine Formatierung. Das eigentliche zu vergleichszwecken herangezogene Datum ist dann aber standardisiert. Von mir aus sollte OSM das auch gerne so machen. Einen Formatstring und ein Value. Aber einen standardiserten Value, bei dem sich jeder auf den Inhalt verlassen kann und keinen Schiffbruch erleidet, wenn man den Formatstring nicht kennt.
Im ürbrigen wäre es ein leichtes für Editoren, die CI Einheiten in Standardeinheiten für den Nutzer umzurechnen. Wenn man das denn will.

Marqqs · 2011-12-15T15:16:59.000Z

viw:

Wahrscheinlich kann man sich das oft sparen. Wichtig wäre nur für den Nutzer, dass er darüber eine Information erhält. Wie “ich konnte beim vergleich nicht alle Zeichen berücksichtigen, da es unerwartete Werte gab.” Nächste Schritt wäre, wenn man sicher sagen kann das es Einheiten sind das Kind so zu nennen oder die Werte konkrett zu benennen.

Genau dafür gibts aber die Statistik-Funktion von osmfilter. Ich hab spaßhalber grad ein Beispiel durchlaufen lassen:

$ ./osmfilter germany.o5m --out-count=maxspeed
     330274    30
     157533    50
      33148    100
      28008    70
      10630    60
       9198    80
       8474    none
       7104    10
       6181    20
       5850    120
       2647    signals
       2466    40
       2374    7
       1508    130
        940    160
        850    5
        592    300
        552    no
        474    250
        440    200
        437    6
        341    15
        277    walk
        218    230
        194    DE:urban
        160    90
         95    8
         85    280
         82    25
         60    DE:zone:30
         55    DE:living_street
         49    DE:rural
         47    3
         44    2
         42    AT:urban
         40    5 mph
         40    variable
         34    4
         33    moderate
         31    1
         28    0
         28    unknown
         21    30km
         13    de:urban
         12    6.5
         10    10 mph
         10    110
         10    30 km/h
         10    DE:motorway
         10    DE:zone30
          9    6 Knoten
          8    undefined
          7    dynamic
          6    de:rural
          6    moderat
          5    12
          5    220
          5    30mph
          4    100;60;80
          4    30; 50
          4    30;50
          4    50; 30
          4    50; 30; 50
          4    50km
          4    7.4
          4    <unterschiedlich>
          4    Spielstraße
          4    default
          3    100;50
          3    11
          3    20 mph
          3    3.5
          3    50 km/h
          3    50; 100
          3    6,5
          3    DE:walk
          3    fixme
          2    100;60
          2    100;70
          2    2.5
          2    30 mph
          2    39
          2    4-7 km/h
          2    50;70
          2    50mph
          2    80; 100
          2    a
          1    %=
          1    (30km/h)
          1    -
          1    /
          1    07
          1    1.50
          1    100; 50
          1    100;30
          1    15 mph
          1    15kmh
          1    21
          1    24
          1    3.0
          1    30; 50; 30
          1    34
          1    35
          1    45
          1    50/70
          1    50; 70
          1    50; 80
          1    50?
          1    600
          1    60; 70
          1    7 kmh
          1    70; 50; 50; 50
          1    70;100
          1    =30
          1    ?
          1    FIXME
          1    living_street
          1    open
          1    signal
          1    urban
          1    workday 06:00-19:00 30; 50

Ich hoffe, ihr kommt nicht auf die Idee, dass das Programm alle diese 121 verschiedenen Werte “korrekt” auswerten können muss…

viw · 2011-12-15T15:26:09.000Z

Also alle diese Werte muss man sicher nicht auswerten. Aber die Keys “none” und “no” halte ich für interessant, genauso wie DE:urban. Weiter unten scheinen ja nur noch versprengte Ausnahmen zu sein.
Aber vielleicht ließe sich das auch anders machen. Nämlich wie bei den Garmin Styles wo es Ersetzungen gibt. Denn Maxspeed ist vielleicht nur eines der uns jetzt einfallenden Baustellen. Wahrscheinlich gibt es noch andere.

chris66 · 2011-12-15T15:57:58.000Z

maxspeed=600? Wo gibt es dieses Paradies für Porschefahrer?

edit: Es handelt sich um einen Parkplatzweg:
http://www.openstreetmap.org/browse/way/57818304

Marqqs · 2011-12-15T15:58:46.000Z

viw:

Also alle diese Werte muss man sicher nicht auswerten. Aber die Keys “none” und “no” halte ich für interessant, genauso wie DE:urban. Weiter unten scheinen ja nur noch versprengte Ausnahmen zu sein.
Aber vielleicht ließe sich das auch anders machen. Nämlich wie bei den Garmin Styles wo es Ersetzungen gibt. Denn Maxspeed ist vielleicht nur eines der uns jetzt einfallenden Baustellen. Wahrscheinlich gibt es noch andere.

Klar, kann man alles machen, aber ich überleg immer noch, um welchen Anwendungsfall es geht. Das Programm ist zum Filtern von Dateien da. Wenn man wirklich einen Key (z.B. maxspeed) umfassend berücksichtigen will, kann man sich dafür ohne Weiteres einen Filter mit Hilfe der Booleschen Operatoren bauen, und zwar exakt so wie man ihn haben will.

Damit will ich nicht sagen, dass deine Ideen schlecht sind! Das sind sie ja absolut nicht. Ich mein aber, osmfilter ist nicht die beste Plattform, das alles umzusetzen.

kellerma · 2011-12-15T17:30:26.000Z

chris66:

maxspeed=600? Wo gibt es dieses Paradies für Porschefahrer?

Die ehemals in Nürnberg ansässige Firma Dauer hat mal 962er mit 400 Stundenkilometer mit Straßenzulassung gebaut.
http://static.pagenstecher.de/uploads/4/47/475/4758/2307-307.jpg

Da Vmax proportional zur 3. Potenz der Leistung ist, wirst Du für 600 km/h schon einen Raketen"motor" (oder ähnliches) brauchen,
womit man wohl dann nicht mehr “durch den TÜV” kommt

Marqqs · 2011-12-15T17:46:29.000Z

Marqqs:

kellerma:

Schaut nur mal das an:
97625 4. Dez 05:05 bin/osmfilter
2856275 15. Dez 07:26 osmfilter

Uff, ich sehs auch grad. Wie konnte das passieren? Der Quellcode ist gar nicht sooo viel größer geworden. Gefällt mir nicht.

Erwischt. Es lang an einer statischen Feldinitialisierung. Habs geändert in eine dynamische, nun ist die Datei wieder vernünftig klein.

EDIT:
Nun doch wieder als statische Initialisierung. Mir ist nämlich aufgefallen, dass der Compiler bei “” (Leerstring) unter Windows sinnvoll dynamisch initialisiert hat, unter Linux aber nicht. Mit {0} klappts unter beiden Betriebssystemen. Dabei müssten “” und {0} eigentlich gleich behandelt werden - jedenfalls, soweit ich das verstehe. Zusammenfassend: Für die übergroße Binary unter Linux ist der Compiler verantwortlich gewesen. Das Problem ist jetzt gelöst, und kellerma braucht nun doch keine externe Festplatte für sein Netbook.

Marqqs · 2011-12-15T17:52:29.000Z

kellerma:

Da Vmax proportional zur 3. Potenz der Leistung ist, wirst Du für 600 kmh schon einen Raketen"motor" (oder ähnliches) brauchen,
welches wohl dann nicht mehr “durch den TÜV” kommt

Also, bei den dann notwendigen Beschleunigungswerten, um an der Toilette zu starten und dann rechtzeitig vorm Kinderspielplatz zum Stehen zu kommen, möchte ich nur ungern im Auto sitzen.

http://www.openstreetmap.org/browse/way/57818304

Walter_Schlögl · 2011-12-17T09:25:23.000Z

Für population funktiert die neue Funktion super, vielen Dank.

Bei Einheiten wäre es vermutlich notwendig, mit regular Expressions zu arbeiten.
Diese Funktion benötige ich jedoch eher bei mkgmap und im Moment weniger bei osmfilter.
Leider hat mkgmap einige Probleme mit Platzhaltern (* darf nicht in der obersten Ebene verwendet werden), hier ist osmfilter bereits deutlich weiter.

Habe ich das richtig verstanden, dass der Default-Operator OR ist und mit Angabe voll “all” auf AND geändert werden kann.
Neu hinzugekommen ist nun die Möglichkeit, OR bzw. AND auch explizit anzugeben, und damit den Default-Operator zu overrulen.

Walter

kellerma · 2011-12-17T10:13:55.000Z

Walter Schlögl:

Habe ich das richtig verstanden, dass der Default-Operator OR ist und mit Angabe von “all” auf AND geändert werden kann.
Neu hinzugekommen ist nun die Möglichkeit, OR bzw. AND auch explizit anzugeben, und damit den Default-Operator zu overrulen.

yep, seh’ ich auch so.
Man kann auch mischen, wie Markus zu Beginn des threads gezeigt hat
–keep=" ( … or … ) and ( … or … ) "

Marqqs · 2011-12-17T11:59:08.000Z

Richtig. Das mit dem “all” ist nur noch beim Tags-Filter relevant (–keep-tags). Beim Objektfilter (–keep) ist es ein Relikt, das aus Kompatibilitätsgründen trotzdem noch unterstützt wird. “all” sollte nicht mit dem neuen Syntax gemischt werden. Beispiel:

all highway=primary oneway=yes

funktioniert zwar noch, heute würde man aber schreiben:

highway=primary and oneway=yes

Auch richtig, aber beim Objekt-Filter ebenfalls ein Relikt ist, dass man “or” weglassen kann. Es ist zwar bis jetzt nicht zwingend notwendig, aber es erleichtert die Lesbarkeit, wenn man es dazu schreibt. Bitte dran denken, “and” geht vor “or” so wie “Punkt” vor “Strich”.

(EDIT: Mir ist grad aufgefallen, dass --help hier keine klare Aussage liefert, weil der alte Syntax ebenfalls beschrieben wird. Ich änder das.)

Zu den Klammern: die können beliebig verwendet und auch geschachtelt werden. Wichtig ist nur, sie immer mit einem Leerzeichen von allem Übrigen zu trennen.

Ein Tipp für die Performance:
osmfilter bricht die Auswertung immer dann ab, sobald das Ergebnis eindeutig ist. Wenn also im obigen Beispiel die untersuchte Straße eine “secondary” ist, wird gar nicht mehr geprüft, ob sie eine Einbahnstraße ist oder nicht, weil das Ergebnis der Prüfung ja schon feststeht. Für diejenigen, die mit Operatoren && und || unter Linux vertraut sind, ist das nichts Neues. Beispiel:

name=Ohmstraße and highway=residential

läuft etwas schneller durch als

highway=residential and name=Ohmstraße

weil es deutlich mehr residentials als Ohmstraßen gibt.
Das ist aber nur für die Leute wichtig, die wirklich das Letzte rausholen wollen oder extrem große Datenmengen verarbeiten müssen.

Generelle Frage:
Sind bei euren Tests noch Fehler aufgetreten, oder kann ich es wagen, die Testversion als reguläre Version online zu stellen?