Hallo zusammen,
häufig ist es nicht mit einer Eigenschaft getan.
Was dann?
Habe das mal wie oben gemacht.
Gibt es das etwas etabliertes?
Und sagt jetzt bitte nicht dass da 3 mal amenity oder shop hinzu klatschen ist…
Danke für reichlich Antworten liebe Gemeinde und herzliche Grüsse!
EK
Wenn Du mehrere Tags mit ; aneinanderhängst erzeugst Du einen ungültigen Wert, der von keiner oder fast keiner Software ausgewertet wird.
Ist praktisch das gleiche wie gar nicht taggen oder löschen.
bye, Nop
Kartieren ist eben auch die Kunst das Wesentliche zu erkennen. Und da ist es in Deutschland klar, dass man in einem Kiosk auch Raucherzeug und Zeitungen bekommt und so die Nennungen unnötig sind.
Die Unterschiede zwichen Bar (und Pub), Cafe und Restaurant sind auch fließend, da muss man sich eben entscheiden, was man als primär ansieht.
Du hast alles richtig gemacht!
Du hast verstanden, daß OSM eine Datenbank ist und keine Karte. Du hast verstanden, daß die Realität abzubilden ist, egal wie schlecht das Taggingschema das unterstützt. Und du hast das Mantra beherzigt, das hier immer gerne hochgehalten wird: Nicht für den Renderer mappen.
Irgendwann™ wird jemand einen Renderer entwickeln, der mehr als einen Wert pro Eigenschaft darzustellen in der Lage ist. Der vielleicht auch den ersten in der Liste als Haupteigenschaft berücksichtigt.
Gruß,
Zecke
…oo( Und vielleicht wird OSM sogar irgendwann mal ein brauchbares Taggingschema bekommen )
Das Eintragen von ungültigen Werten entgegen der Wiki-Beschreibung würde ich weder als “richtig” noch als hilfreich für OSM bezeichnen.
Aber früher oder später wird der kaputte Eintrag sowieso von jemand anders auf etwas korrigiert, das wenigstens ein paar Editoren und Auswerter verstehen. Auf jeden Fall bedeutend früher als daß sich alle Entwickler die Mühe machen, universelle, aufwändige Umsetzungen für alle untauglichen Ansätze zu bauen.
Zur Lektüre empfehle ich
http://gis.19327.n5.nabble.com/Who-interprets-semicolon-in-tag-values-td5763540.html
http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
bye, Nop
Alternative:
Die Hauptverwendung des POI taggen, die Nebenverwendungen mit *=yes ergänzen.
Es ist ja weder generell falsch noch ungültig, wenn man verschiedene Werte für ein Tag durch Semikolon trennt, wenn dieser Tag eben tatsächlich mehrere Werte hat, sondern die übliche Vorgehensweise in diesem Fall. Die Tatsache, dass dieses Tagging noch zu wenig von Auswertern, Renderern etc. unterstützt wird, ist ja letztlich eine ganz andere Frage, die aber nichts damit zu tun hat, ob das Tagging an sich richtig oder falsch ist. Wir taggen ja weder für die Renderer, noch für die Auswerter.
Im Einzelfall muss man natürlich immer überlegen, ob man für ein bestimmtes Tag mehrere Werte vergeben muss / sollte / will oder nicht. Bei einem Kiosk, der auch Zeitungen und Tabakwaren anbietet, würde ich z.b. eher zum reinen shop=kiosk tendieren, weil ich mir denke, dass ein Kiosk eben üblicherweise auch diese Dinge im Angebot hat, während ich mir unter einem shop=tobacco einen spezialisierten Tabakwarenladen und unter shop=newsagent ein spezialisiertes Zeitschriftengeschäft vorstelle, deren Auswahl über die eines Kiosks hinausgeht. Genau so würde ich mir bei Restaurant / Cafe / Bar überlegen, wo denn der Schwerpunkt liegt, ob es also eher ein Cafe mit Barecke oder eher eine Bar mit ein paar Kuchen im Angebot ist. Unter einer richtigen Bar stelle ich mir dann doch etwas mehr vor als ein Cafe oder Restaurant mit Barecke.
Wie auch im ersten Link von Nop beschrieben, würde ich im Falle von mehreren fast gleichberechtigten Werten doch eher zu Unter-Tags mit : tendieren. Im Falle eines Restaurants, welches die bayerische Küche, aber auch mediterrane Köstlichkeiten anbietet, würde ich nicht cuisine=bavarian;mediterranean sondern eher in Richtung cuisine=bavarian cuisine:mediterranean=yes gehen. Das wird zwar momentan vermutlich noch genausowenig von Auswertern unterstützt, aber man kann wenigstens Zusatzangaben machen, ohne dass man das Haupttag (in diesem Fall cuisine=bavarian) kaputt macht.
Heißt: dieser Ansatz führt dazu, dass man ein bestehendes Tagging erweitern kann, ohne dass nicht angepasste Auswerter nichts damit anfangen können. Deshalb gehen auch so ziemlich alle neuen Proposals genau diesen Weg.
Tja, das ist dann vielleicht genau eine Spezialkarte, wo die Entwickler Hirnschmalz reingesteckt haben. Und die restlichen 1.000 Karten (Tendenz steigend) zeigt einfach gar nix an, weil der Filter amenity=cafe nicht wie bei 99,9% der Cafés anschlägt.
Jedes Kind weiß, dass man nicht für den Renderer, sondern für die Datenbank kartiert. In diesem Fall sollte man halt zumindest nach Datenbankschema taggen - und das erlaubt nun mal keine Konkatenation mit Strichpunkten.
edit: Stimmt natürlich, ich hab mich oben etwas falsch ausgedrückt. Die Datenbank erlaubt alles, auch Tippfehler oder Strichpunkte.
Aber genau das erlaubt doch das Datenbankschema (Oder weist die Datenbank Semikolon-Notation neuerdings zurück?), mangels Unterstützung von mehreren separaten amenity=* Tags am gleichen Objekt. Da man nicht amenity=cafe und amenity=bar gleichzeitig an ein Objekt setzen kann, ist die Ausweichlösung nach Datenbankschema eben die mit dem Semikolon, also in dem Fall amenity=cafe;bar. Genau so wird es ja auch bei anderen Keys benutzt.
Demzufolge ist es auch nur konsequent, wenn Renderer eben dieses Schema umsetzen. Das Problem liegt hier eher darin, dass es nicht einmal auf der osm.org Standard-Mapnik-Karte benutzt wird, statt hier ein Beispiel zu setzen, dass man es auswerten kann. Es muss einfach ein Anfang gesetzt werden, damit sich andere Karten daran orientieren und es ebenfalls umsetzen.
Deiner Logik folgend ist richtig was die Datenbank frisst. Also alles.
Ist denn das semikolonseparierte Aneinanderfügen von mehreren Values irgend wo dokumentiert / beschlossen worden, oder ist das nur eine seltene Praxis, die sich halt eingeschlichen hat?
Letztlich sollte das Taggingschema möglichst einfach schreib- und auswertbar sein. Und da lassen sich mehrere Tags (“*=yes” zusätzlich zum Basis-Tag) einfacher verwerten, als Strings nach der Datenbankabfragen einzeln erst zu splitten (bzw. erst mal zu schauen, ob der Value zu splitten ist). Die schönste Datenbank nützt nix, wenn die Daten nicht effektiv verarbeitet werden können.
Hi EK,
willkommen bei OpenStreetMap (bist ja gleich mittendrin).
Ich würde auch empfehlen, den hauptsächlichen tag zu setzen. Nimmt man zusätzlich noch die Website auf, so hat der Anwender auch noch die Möglichkeit, dort einfach nachzuschauen. Auf der Hauptkarte ist das zwar etwas schwieriger an die Info zu kommen (man muss dafür den Datenlayer einschalten).
Ansonsten ist OpenStreetMap ein Projekt das in Bewegung ist und keine starren Regeln hat. Das ermöglicht es neue Schemata aufzunehmen, zu verproben und auch die Akzeptanz durch Verarbeitungssoftware zu testen, führt aber manchmal zu nicht eindeutigen Antworten 
Christoph
Nein, eben nicht alles, das habe ich doch oben geschrieben. Die Datenbank “frisst” kein amenity=cafe und amenity=bar am gleichen Objekt.
Siehe der Link von oben. Dort steht auch, wann man das Semikolon wenn möglich vermeiden sollte, aber nicht dass es “ungültig” oder “verboten” oder gar “falsch” wäre. Es gibt eben keine festen Regeln jenseits des Datenbankschemas, sondern “nur” Konventionen, wie Dinge üblicherweise getaggt werden.
Das steht natürlich völlig außer Frage und das bezweifelt auch niemand.
Nicht zwangsläufig, das kommt auf die Implementierung an.
Da hast Du natürlich Recht (Node/Key sind Primary). Der Bezug war jedoch nicht der Key, sondern der Value, den die Datenbank zu speichern hat - und da kannst Du auch beliebige Sätze reintippen (wobei m.W. eine Begrenzung auf 256 Zeichen besteht).
Richtig, im Value kann man natürlich “beliebigen” Inhalt eingeben und er entspricht dem Datenbankschema (mit Ausnahme von leeren Werten, so weit ich mich erinnere). Ob diese Inhalte wirklich sinnvoll sind, ist natürlich noch einmal eine andere Frage - bei weitem nicht alles, was die Datenbank annimmt, macht auch Sinn.
Das Semikolon sollte so lange nicht verwendet werden, bis genau definiert ist, was es bedeutet. Es gibt ja durchaus Schlüssel, wo eine solche Definition existiert (z.B. turn:lanes), und dort sehe ich auch kein Problem.
Ich habe nur irgendwie den Verdacht, dass man beim Versuch, eine derartige Definition für Schlüssel wie amenity aufzusetzen, feststellen wird, dass Mapper eigentlich ganz unterschiedliche Bedeutungen im Kopf haben.
Der Vorschlag man sollte die best passende Eigenschaft nehmen zerstört den Nutzen der ganzen Idee!
Der Nutzen besteht darin, daß ich speziell nach Zeitschriften, Akupunktur, Skisport-Geschäft, … suchen kann
… und dabei nicht geden Kiosk, jeden Artz, Heilpraktiker oder jedes Sportgeschäft (nebenbei: Gibt es einen tag für reine Sportgeschäfte überhaupt schon???) abklappern muß.
Ich habe mich die letzen Wochen sehr intensiv damit beschäftigt Geschäfte, Läden, etc. zu erfassen… und muß feststellen, daß wir da noch in den Kinderschuhen stecken.
Douglas ist eine Parfümerie(!!!) und eben nicht so ein Drogeriegeschäft… Und bei Rossmann kriegt man ja auch Lebensmittel…
So einfach ist das nicht! Bei der suche nach etablierten tags läuft man sehr häufig ins nichts. Ist ja jetzt auch egal an der Stelle.
Wo wir jetzt noch nicht weiter sind - das Kernproblem - ist wie am besten mehrere gleiche Eigenschaften einem Objekt zugeordnet werden.
Noch eine Idee wäre:
amenity=bar
amenity:1=cafe
amenity:2=restaurant
amenity:3=launch
amenity:4=…
Der Vorteil hier wäre, daß die bisherige Kompatibilität gewahrt bleibt!
Schlage das hiermit mal vor.
Gebt ihr mir eure Stimme??? 
In jedem Fall vielen Dank für die ganzen Antworten!
Das Healthcare 2.0 Schema steckt vermutlich wegen genau dieser Komplexitaet noch ein wenig fest. Hier wird zwischen main, additional, yes, no, partial unterschieden. Das macht das ganze Thema allerdings so komplex, dass sich kaum einer ans Taggen wagt. Genau deshalb wird sich so etwas ohne gute Unterstuetzung im Editor auch nicht durchsetzen koennen. Schau Dir mal an, wie Healthcare 2.0 das Ganze angeht. Damit koenntest Du
amenity=bar (als Kompatibilitaet)
amenity:bar=main
amenity:cafe=yes
amenity:restaurant=partial
eintragen. Aber wer wird das alles eintragen frage ich? Ich stimme Dir zu, dass es ganz toll waere, so etwas als Konsens zu haben. Doch sogar ohne jemals darueber eine Abstimmung gesehen zu haben kann ich Dir orakeln: das wird leider nix, das ist vielen einfach zu komplex. Hier jammern ja schon Leute wegen Multipolygonen.
Also kurzgefasst: Tolle Sache, aber ohne breiten Support in den wichtigsten Editoren wird’s nix. Und dazu muss man sehr viele Leute ins Boot holen…
ps. Douglas tagge ich shop=beauty beauty=perfume
Kannste haben: Laß es.
Das allerhöchste der Gefühle liegt mMn bei key=val1;val2;val3 also eine per Semicolon getrennte Liste. Da kannst du Glück haben, wenn jemand das nicht komplett verwirft, sondern (bei guter Laune und Sonnenschein) den ersten Wert berücksichtigt.
Gruss
walter
Bevor wir das Tagging Schema explodieren lassen, wie wäre es in diesem Fall mit 4 Nodes. Das gibt dir die Möglichkeit, auch Informationen Kuchen nur bis 17:00 und die Bar hat erst um 23:00 geöffnet zu taggen, ohne mit Doppelpunkten einen Knoten in das Tagging zu machen :-).
Vlelsagende Subkeys wie :1 finde ich persönlich unschön.
Und den Versuch, detaillierter das Warenangebot zu taggen, gab es auch schon (Stichwort Mate), je nach Level erscheint mir das sogar sinnvoll.
Wenn ich die Objektvorlagen richtig verstanden habe, ist das in JOSM nicht das größte Problem (ist auch nur ein XML File).
Christoph