Wie werden denn korrekt mehrere Attribute an einen Schlüssel getaggt? Nehmen wir als Beispiel mal “cuisine” - angenommen, Laden hat Sushi und Pizza. Welches Trennzeichen zwischen den Attributen “sushi” und “pizza” ist richtig, Semikolon oder Komma? Oder wird mehrfach der Schlüssel getaggt?
Mehrfach kannst du den Schlüssel nicht taggen. Korrekterweise wird hier mit einem Semikolon getrennt.
Bei Sport steht in der wiki:
where a number of sports are associated with a single feature then separate the sports with a ‘;’, for example ‘gymnastics;badmington’.
Demnach wäre ; zutreffend. Wenn ich das mache hat potlatch 2 mit einem roten Ausrufezeichen gemeckert…
Semikolon: http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
Mehrfacher Schüssel wäre viel schöner, hat aber den Herren des Datenbankschemas nicht gefallen.
Japs mit Semikolon kenne ich es auch. Wobei man dazu sagen muss, dass kaum ein OSM Tool dies bereits berücksichtigt. Also kann es sein, dass deine so getaggten Objekte z.B. nicht gerendert werden.
So ist es…in der Regel läuft die Auswertung so: ist der value für den key amenity identisch mit restaurant, dann male Restaurantsymbol
Ist der value nun aber restaurant;hotel, passt das natürlich nicht mehr.
Die bessere Auswertung wäre zu schauen, ob der Suchstring in der anderen Zeichenkette enthalten ist. Hilft aber auch noch nicht weiter, weil jedes Objekt nur einmal durchlaufen wird. In obigen Beispiel wird also entweder das Restaurant oder das Hotel erscheinen.
Daher würde ich mich bei solchen kleinen Unterschieden wie bei cuisine für das primäre entscheiden. Bei meinem Beispiel mit Restaurant und Hotel hängt es von der Gliederung der Einrichtungen ab. Wenn beides für den Gast unabhängig voneinander ist, dann würde ich in diesem Fall 2 Nodes setzen.
Schließe mich dem an, von Semikolons an gebräuchlichen Haupttags ist dringend abzuraten, das führt meistens dazu, daß das Tag überhaupt nicht mehr ausgewertet wird und die Information von allen Karten verschwindet.
“Wir mappen nicht für…” - ist mir völlig egal, wie die Karte aussieht, ich war mir bei dem Delimiter nicht sicher. Viel wichtiger ist mir: Was macht denn die XAPI wenn ich nach “cuisine=sushi” frage und es Objekte mit “cuisine=pizza;sushi” gibt? Wenn die das kann reicht mir das. Selber kann ich sowas mit PHP-Explode schnell aufdröseln.
Ich habs zwar noch nicht probiert, aber ich habe mal starke Zweifel daran, dass sie das findet. Die dürfte genau so suchen, wie aighes geschrieben hat: Wenn der Tag “cuisine=sushi” wörtlich vorhanden ist, gibt das Element aus, ansonsten nicht.
Soweit ich weiß, tut auch die (X)API das wohl nicht. Sollte man vielleicht mal anregen einzubauen…
Nö, die XAPI kann das ebensowenig wie die übrigen Tools - darum solltest Du’s ja nicht verwenden. 
bye
Nop
Ich hab auch schonmal die Variante gehört (im Zusammenhang mit Mobilfunkmasten) den Knoten doppelt an exakt der gleichen Stelle mit unterschiedlichen Ausprägungen des Operators zu setzen.
Aber nicht alles, was technisch kompliziert und für einen Typ von Anfragen pfiffig klingt, passt. Dann wäre das Restaurant ja schon vorm Besuch doppelt zu sehen.
Ich würde hier auch die “Hauptattraktion” taggen.
Christoph
P.S. wobei es nicht schlimm ist, wenn ich Restaurants mit der Kombination “sushi;pizza” nicht finde. Entweder Sushi Oder Pizza, das wäre mein Suchziel.
Zum Pizzabäcker, der sich an Sushi Versucht (oder vice versa), muss ich nicht hingehen 
.
Die opengastromap.de zeigt bei cuisine=pizza;sushi das Pizza-Symbol an, die Karte wertet also immer nur das aus, was vor dem Strichpunkt steht. Sauber ist diese Art zu taggen allerdings nicht. Es ist quasi eine Art hstore auf der Ebene des Datenbankschemas. 
Strukturell sauber wäre z.B. das hier:
cuisine=pizza
cuisine:2=sushi
cuisine:3=kebap
usw.
Aber gegen eine grundsätzliche Einführung des Strichpunkts als Trenner hätte ich auch nichts. Das heißt ja nicht, dass es dann in dieser Form in der Datenbank stehen muss. Dort kann man solche Konstrukte dann als Array abspeichern. Da könnte man jetzt endlos weiterphilosophieren…
Am einfachsten wäre pizza=yes und sushi=yes 
Eigenschaft = Ja|Nein|… ließe sich auf alles anwenden und wäre immer eindeutig.
dann aber
cuisine:pizza=yes
cuisine:sushi=yes
Also das finde ich nun ganz und gar unbrauchbar. Wesentlich schlimmer als die Strichpunktschreibweise, die nur daran leidet, dass kein Programm sie auswertet (obwohl das ja im Prinzip nicht so schwer wäre). Allerdings ist das Problem der meisten Programme wohl weniger daran liegt, dass es grundsätzlich zu kompliziert wäre, das zu zerlegen, als dass sich vielmehr die Frage stellt, wie man sowas darstellen soll.
Und wie baut man mit
cuisine=*
cuisine:2=*
cuisine:3=*
sinnvolle Renderregeln? grübel
*=yes
erfordern sehr detaillierte Renderregeln. Sie hätten aber den Vorteil, daß man bei Bedarf
amenity=restaurant
cuisine:pizza=yes
mit Ersetzungsregel “greifen” und in einem Spezialitätenführer anzeigen lassen kann.
Nachteil:
Das System verleitet dazu, die halbe Speisekarte zu taggen.
Und wer hält das nach?
Sinnvolle Zusammenfassungen wie
cuisine=international
cuisine=italian
cuisine=greece
etc.
wären klarer.
Gruß
tippeltappel
Im Prinzip sind die cuisine-Werte doch halbwegs brauchbare Zusammenfassungen - zumindest solange man das System nicht falsch versteht und cuisine=ice_cream taggt, nur, weil es das als Nachtisch gibt. Aber es ist schon richtig, dass z.B. pizza und italian getrennt ist.
An der Komplexität der Renderregel ändert sich doch nichts. Mit cuisine=* muss man amenity=restaurant und cuisine=pizza auswerten und mit *=yes muss man amenity=restaurant und pizza=yes auswerten.
Komplexer wird es, wenn man alle Restaurants mit einer beliebigen cuisine möchte. Aber wozu sollte man sowas wollen?
pizza hat ja nichts damit zutun, dass es auf der Speisekarte steht, sondern sagt aus, dass es sich um eine Pizzeria handelt. So eine typische Pizzabude mit Lieferservice würde ich jedenfalls nicht als Italiener eintragen.
Naja, die Anforderungen sind verschieden, manche wollen genau das:
http://toolserver.org/~stephankn/cuisine/?zoom=17&lat=50.93798&lon=6.95916&layers=BT
Trotzdem, deine Idee mit
pizza=yes
oder auch
cuisine:pizza=yes
find ich gar nicht schlecht.
Schwierig wird es allerdings, wenn man mit einer einfachen SQL-Abfrage die Art der Küche als Value ausgeben will. Dann müsste man alle Tags abklappern. Oder man lässt den Haupt-Tag mit cuisine=pizza zusätzlich drin. Fragen über Fragen.