[Talk-de] Dictonaries in OSM

[Martin Koppenhoefer]

Am 20. November 2011 03:59 schrieb Andreas Hubel <andi at saerdnaer.de>:
> Mir sind im ersten Moment nur die TMC und die parking Tags eingefallen:
> parking:lane:right=perpendicular
> parking:condition:right=disc
> parking:condition:right:maxstay=1 h
> parking:condition:right:time_interval=Mo-Fr 09:00-18:00;Sa 09:00-14:00
>
> parking = {
>        lane: {
>                right: "perpendicular"
>        },
>        condition: {
>                right: {
>                        value: "disc",
>                        maxstay: "1 h",
>                        time_interval: ["Mo-Fr 09:00-18:00", "Sa 09:00-14:00"]
>                }
>        }
> }


das könnte man auch anders rum machen (also erst rechts/links = die
Angabe des Subobjekts, und dann erst die zugehörigen tags (verkürzt
wiedergegeben): parking={lane:{right:{condition: {disc, maxstay,
timeinterval}, surface: "asphalt", width: "2.5m"}}} bzw. "klassisch"
parking:lane:right:condition=...

Alternativ könnte man auch dedizierte Geometrie verwenden, dann würde
das meiste schonmal wegfallen (parking:lane:right). Das ist wenn man
nur an den Park-details interessiert ist, vielleicht nicht nötig, aber
vermutlich wird man irgendwann auch weitere Details wie die
Unterbrechungen der seitlichen Parkplätze (z.B. Fußgängerquerung),
mappen wollen, und dafür jedesmal die Straße zu splitten ist auch
weniger schön.


> Ich wäre grundsätzlich dafür beim Taggen drauf zu achten, das möglichst wenig verschiedene Keys entstehen.
> Das heißt ich würde dynamische Dinge wie Zahlen oder Wochentage gerne aus dem Key rauslassen.


+1


> Ggf. sollte man dann auch noch ein einheitliches Trennzeichen für subkey und subvalue einführen, z.B. den Doppelpunkt.


das haben wir mehr oder weniger bereits. Einziger Haken: neben dem
Doppelpunkt gibt es noch den underscore, der in bestimmten Fällen eine
ähnliche Rolle einnimmt.


> level_names:U=basement
> level_names:G=ground floor
> level_names:3=roof

> Oder sollte man doch einfach JSON in den Value stecken?
> level_names={"U": "basement", "G": "ground floor", "3": "roof"}


würde m.E. in diesem Beispiel hier Sinn machen.


> Wie sieht ihr das?
> Macht es Überhaupt sinn da ne einigermaßen einheitliche Regel zu erarbeiten?


Danke für diese Mail. Das ist ein Thema, das regelmäßig hochkommt, die
Welt ist nun mal komplex.


Naja, Sinn. Einerseits erhöht es die Komplexität für den Mapper (er
muss sich jetzt auch noch ein paar Regeln zur Notation merken),
andererseits würde ein fester Satz Regeln vermutlich die Bereitschaft
erhöhen, komplexere Sachverhalten auch abzubilden, und bestimmte tags
würden auch übersichtlicher durch diese Art der Notation (s.d.
Beispiele). Ausserdem könnte man die gestiegene Komplexität durch den
Editor geschickt verbergen / einfach zugänglich machen.

Grundsätzlich gibt es allerdings wohl Bedenken von Seiten der
Entwickler gegen Werte, die erst durch Parsen und Weiterverarbeiten
des Wertstrings Sinn ergeben, weil das die Auswertung verlangsamt
(bereits das Semikolon als Werte-trenner wird von den Hauptanwendungen
wie osm2pgsql soweit ich weiss nicht gesondert berücksichtigt, erst
recht keine Dictionaries), und weil eine rasche Verarbeitung bei den
von uns gebräuchlichen Datenmengen unabdingbar ist (vor allem, wenn
man die globalen Daten vorhalten will).

Gruß
Martin