Ich meinte das eher so, wie Stephan es auch in seiner Antwort
durchklingen lässt. Mir geht es um Datentypen innerhalb von Tag-Values,
nicht um neue Datentypen generell.
So wie du es vorschlägst, ist das ein massiver Umbau der API, und ob der
wirklich glücklich ist, lässt sich diskutieren.
Mein Vorschlag wäre eher in Richtung einer zentralen Dokumentation zu
sehen; also:
1) Das Semikolon kann als Sonderzeichen in values betrachtet werden.
2) Der Typ der Values eines Tags ist im wiki per Template definierbar.
3) Ist nichts anderes definiert, ist der Wert als atomar zu betrachten.
Im Wiki kann dann für amenity stehen:
amenity [typ: set]
Wenn im amenity-key ein Semikolon auftaucht,
dann enthält dieses Tag mehrere Werte,
deren Reihenfolge aber keine Bedeutung hat.
highway:lanes [typ: array]
Wenn im highway:lanes-Tag ein Semikolon auftaucht,
dann enthält dieses Tag mehrere Werte als geordnete Liste,
die Reihenfolge hat also eine Bedeutung.
seamark:colors [typ: array]
s. lanes.
ref [typ: set]
s. amenity
name [typ: atomic]
Wenn hier ein Semikolon auftaucht,
hat dieses keine besondere Bedeutung,
der Wert ist trotzdem als ein einzelnes Element zu
interpretieren.
Diesen Typ kann man jeweils in die Tag-Templates im Wiki mit aufnehmen
und taginfo, Editoren etc. können diese Info nutzen, um die GUI
anzupassen, Vergleiche/Suche anzupassen:
wenn ich nach amenity=bar suche, finde ich dann auch bar;restaurant;
wenn ich nach amenity=bar;restaurant suche, finde ich auch restaurant;bar
Wenn ich nach amenity=bar+ suche, finde ich amenity=bar;restaurant
nicht, aber amenity=barn
wenn ich nach seamark:colors=white suche, finde ich red;white aber
nicht, weil das ein anderer Wert ist,
wenn ich nach name="foo" suche, finde ich nicht name="foo;bar", bei
name="foo*" aber schon.
Bei deinem Vorschlag hingegen lässt sich zumindest Restaurant/Cafe von
Hotel trennen, falls Restaurant und Cafe dieselben Räumlichkeiten
verwenden, sind die Öffnungszeiten auch in dieser Form falsch, denn ich
kann dann ja auch Samstags um 13:30 ins Cafe gehen - schlimmstenfalls
krieg ich den Kuchen erst später, aber mit dem Kaffee kann ich schon
anfangen.
Dieser Unterschied ist aber nicht ersichtlich, was hier wie
zusammenhängt oder auch nicht.
Und: Willst Du sets dann auch noch verschachteln (z.B. weil restaurant
und cafe gemeinsam einen anderen operator haben als das Hotel)?
Gruß
Peter
Am 14.01.2014 08:54, schrieb André Riedel:
> Eine Set würde ich in API 0.7 bevorzugen, denn so könnte man bspw. die
> Unterschiedlichen Öffnungszeiten kenntlich machen.
>
> <key="name" value="Zum Goldenen Löwen" />
> <set>
> <key="amenity" value="restaurant" />
> <key="opening_hours" value="Mo-Su 11:00-21:00">
> </set>
> <set>
> <key="tourism" value="hotel" />
> <key="opening_hours" value="24/7">
> </set>
> <set>
> <key="amenity" value="cafe" />
> <key="opening_hours" value="Sa,Su 14:00-17:00">
> </set>
>
> Am 14. Januar 2014 08:33 schrieb Peter Wendorff <wendo...@uni-paderborn.de>:
>> 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
>>
>> _______________________________________________
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-de
>
> _______________________________________________
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
