[Talk-de] Softwareunterstützung für Semikolon getrennte Tags

Peter Wendorff wendorff at uni-paderborn.de
Di Jan 14 07:33:18 UTC 2014


Am 14.01.2014 00:40, schrieb Stephan Knauss:
> On 13.01.2014 23:40, Frederik Ramm wrote:
>> Du hast schon recht, es waere wuenschenswert, wenn Software das
>> "automatisch richtig" machen wuerde, aber puh, das wird ein langer und
>> steiniger Weg. Am Anfang stuende die Frage: Sollen wir
> 
> eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur
> key=value Paare, sondern noch etwas mehr.
> 
> Eine Idee für Api 0.7
> 
> Geordnete Listen:
> Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge
> nacheinander kommen. Doppelte Values sind erlaubt.
> 
> Sets:
> Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle,
> doppelte Values sind verboten.
> 
> Wäre eine größere Änderung, dürfte aber viele der bisherigen
> Verwendungen vom Semikolon abdecken.
> 
> Bisherige Werte in der Datenbank blieben als value erhalten bis es
> jemand von Hand (oder script) konvertiert.
> 
> ABER: Das ist eine recht große Änderung die eine Modifikation an jeder
> Software erfordern würde die die Daten verarbeiten will. Um kompatibel
> zu bleiben müsste es eventuell einen Konverter geben der den API 0.7
> output wieder zusammenmergen kann in einen einzelnen value mit Semikolon
> für nicht angepasste alte Software.
Oder die API wird tatsächlich mit der Dokumentation im Wiki verzahnt und
dieser Typ kann im Wiki angegeben werden, also z.B. im Wiki für die
Bojen-Farben:
value-type: List

Bei Lanes: List
Bei amenity: Set
Bei name: String
etc.

Dann kann der bestehende Wert (amenity=bar;restaurant) der Dokumentation
entsprechend behandelt werden (als eine ungeordnete Menge), beim name
als ein einzelner Wert, selbst wenn ein Semikolon vorkommen sollte.

Das kann natürlich auch Teil der API sein, aber selbst wenn nicht ließe
sich das vermutlich umsetzen. Die größte Hürde sehe ich in der Software,
die die OSM-Daten anwendet, denn die muss mehrere Werte unterstützen -
Renderer, Router, ...

Wir mappen zwar nicht für [Anwendungsimplementierung X], aber viele
Anwendungen, gerade Mapnik, OSRM etc. sind eben doch treibende Kraft
dafür, dass Mapper großflächig Daten beisteuern und vor allem
korrigieren; notfalls korrigieren in dem Sinne, dass [Anwendung X] dann
wieder funktioniert.

Gruß
Peter




Mehr Informationen über die Mailingliste Talk-de