amenity=cafe;restaurant;bar;... shop=kiosk;tobacco;newsagent;... ?????

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 )

Zecke wrote:

Du hast alles richtig gemacht!

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-inte … 63540.html
http://wiki.openstreetmap.org/wiki/Semi … _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.

Zecke wrote:

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.

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.

derstefan wrote:

In diesem Fall sollte man halt zumindest nach Datenbankschema taggen - und das erlaubt nun mal keine Konkatenation mit Strichpunkten.

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.

MHohmann wrote:

derstefan wrote:

In diesem Fall sollte man halt zumindest nach Datenbankschema taggen - und das erlaubt nun mal keine Konkatenation mit Strichpunkten.

Aber genau das erlaubt doch das Datenbankschema (Oder weist die Datenbank Semikolon-Notation neuerdings zurück?)

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

Joachim Moskalewski wrote:

Deiner Logik folgend ist richtig was die Datenbank frisst. Also alles.

Nein, eben nicht alles, das habe ich doch oben geschrieben. Die Datenbank "frisst" kein amenity=cafe und amenity=bar am gleichen Objekt.

Joachim Moskalewski wrote:

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?

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.

Joachim Moskalewski wrote:

Letztlich sollte das Taggingschema möglichst einfach schreib- und auswertbar sein. Die schönste Datenbank nützt nix, wenn die Daten nicht effektiv verarbeitet werden können.

Das steht natürlich völlig außer Frage und das bezweifelt auch niemand.

Joachim Moskalewski wrote:

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).

Nicht zwangsläufig, das kommt auf die Implementierung an.

MHohmann wrote:

Joachim Moskalewski wrote:

Deiner Logik folgend ist richtig was die Datenbank frisst. Also alles.

Nein, eben nicht alles, das habe ich doch oben geschrieben. Die Datenbank "frisst" kein amenity=cafe und amenity=bar am gleichen Objekt.

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).

Joachim Moskalewski wrote:

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!
- Es gibt Restaurant, in denen man Kaffee und Kuchen bekommt und in manchen Restaurants - Speise-Lokale wird erwartet, daß man was ißt.
- Zum Thema Kiosk: In der Region Düsseldorf gibt es sogenante Büdchen, da bekommt man häufig Tabak, Getränke, Süßigkeiten, Knabberzeugs aber keine Zeitschriften... Und Lottoannehmestellen gibt es ja auch manchmal in der Kombination
- Oder ein Arzt (Internist) bietet zusätzlich Ernährungsberatung und Akupunktur an.

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

EinKonstanzer wrote:

Gebt ihr mir eure Stimme?????? 😄 :-) ;-)

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

EinKonstanzer wrote:

Noch eine Idee wäre:
amenity=bar
amenity:1=cafe
amenity:2=restaurant
amenity:3=launch
amenity:4=...

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.

Nadjita wrote:

aber ohne breiten Support in den wichtigsten Editoren wird's nix

Wenn ich die Objektvorlagen richtig verstanden habe, ist das in JOSM nicht das größte Problem (ist auch nur ein XML File).

Christoph

Danke an alle für Eingabe zum Thema!
Das Healthcare 2.0 Schema finde ich ganz gut und auch verständlich und auch nicht zu kompliziert.
Den, den es interessiert muss sich halt einarbeiten...

TheFive wrote:

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 :-).

Ich halte es für unumgänglich das tagging zu erweitern.
4 Konten würden dazu führen, daß 4 mal die Adresse, Tel., website, Öffnungszeiten, ... eingetragen werden. Bei Änderungen müßten auch wirklich alle 4 berücksichtigt werden.

Die Komplexität steigt mit der Erweiterung vom tagging Schema... Ist so.

EinKonstanzer wrote:

4 Konten würden dazu führen, daß 4 mal die Adresse, Tel., website, Öffnungszeiten, ... eingetragen werden.

Ich trage die Adresse immer und nur am Gebäude ein. Liegt nur eine Nutzung des Gebäudes vor, trage ich die POI-Daten ebenfals am Gebäudumriß ein. Liegen mehrere Nutzungen vor, trage ich die POIs als Node (innerhalb des Gebäudes) ein, aber ohne Adresse.

Gruß
Peter

Hi Peter,
das Problem ist POI<>Adresse.
Wurde keine Adresse beim POI (Restaurant, ...) hinterlegt, kriegt man nur über das Haus die Adresse heraus - dann noch copy & past...:(
Bei der Suche nach einem POI möchte man halt schon direkt die Adresse haben. :-) Spätestens beim Navigieren. 😉

Grüße EK

EinKonstanzer wrote:

Ich halte es für unumgänglich das tagging zu erweitern.
4 Konten würden dazu führen, daß 4 mal die Adresse, Tel., website, Öffnungszeiten, ... eingetragen werden. Bei Änderungen müßten auch wirklich alle 4 berücksichtigt werden.

Ja und wenn wir dann ein Tagging für 4 SubPois haben, erweitern wir es, das wir unterschiedliche Öffnungszeiten, verschiedene Durchwahlen... abbilden können. :-) . KISS.

Christoph

EinKonstanzer wrote:

das Problem ist POI<>Adresse.
Wurde keine Adresse beim POI (Restaurant, ...) hinterlegt, kriegt man nur über das Haus die Adresse heraus

Ich habe auf meinem Handy OSMand mit brouter installiert. Andere OSM-Navis nutze ich nicht und kann deher keine Aussage dazu treffen.
Wenn ich mir in OSMand die Daten eines POIs anzeigen lasse, bekomme ich keine Adresse angezeigt, auch wenn diese in OSM beim POI hinterlegt ist. Das ist auch nicht schlimm, da bei jedem POI die lat/lon-Daten hinterlegt sind und ich mir die POIs somit auf der Karte anzeigen lassen kann. Damit ist dann ein Routing zu diesem POI kein Problem. Will ich nur die Adresse wissen, kann ich diese auf der Karte ablesen.

Gruß
Peter