Na ja, unsere Datenbank-Leute hatten sich aber auch schonmal beschwert wenn es im Key variable Teile gibt. 
+1
gefällt mir. In diesem Fall wäre das Semikolon sicherlich etwas unglücklich. Würde man dann auch meinem Waren-/Kaufhaus anstatt shop=department_store auch die unterschiedlich angebotenen Waren mit Semikolon abtrennen?!
Im vorliegenden Fall stellt sich mir aber noch die Frage, ob es sich hier nicht doch eher um ein Geschäft handelt, in dem “Kinderkleidung”, “Kinderschuhe” und “Kinderspielzeug” verkauft wird. In diesem Fall könnte man ein shop=children (nein - hier werden keine Kinder verkauft 
) und zusätzlich noch das Warenangebot (clothes=yes shoes=yes toys=yes) eintragen (ähnlich wie bei shop=clothes und clothes=*; siehe http://wiki.openstreetmap.org/wiki/DE:Key:clothes))
VG,
Thorsten
-snip- Vorposter war schneller.
Ich weiß mehrere Beispiele dazu. Ich weiß nicht, ob man in Deutschland solche Laden sehen kann, aber bei uns in der Ukraune sie sund nicht Seltenheit. Beispiele:
- Schreibwarenladen (shop=stationery), wo man Xerokopie machen kann (shop=copyshop)
- Zeitungsstand (shop=newsagent), wo man Fußballtickets kaufen kann (shop=tickets)
- Haushaltschemie-Laden (shop=chemist), wo man noch ein wenig Spielzeugen kaufen kann (shop=toys)
In diesen Fällen, meine ich, ohne ; kann man nicht auskommen.
Ein Problem ist (soweit ich das verstehe) auch, das ein Rendering von key=neuerwert im CartoCSS schnell umzusetzen ist, wohingegen ein key:neuerwert=yes schwer (weil es zusätzliche Datenbankspalten braucht) umzusetzen ist, d.h. für key=neuerwert brauchts nur ein minor release des Kartenstils, wobei ein key:neuerwert=yes ein major release braucht. Siehe https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style ; da stehen die Keys, die eigene Spalten bekommen.
Man kann also beliebig viele neue subkeys generieren, aber die kriegen vermutlich keinen Support im openstreetmap-carto-Stil.
Hey Edward,
auch in Deutschland gibt es natürlich solche Geschäfte und sind sicherlich auch keine Seltenheit. Wenn man so will, kann man z.B. auch in einem Schreibwarenhandel, Zeitungsstand und auch einer Drogerie (“Haushaltschem-Laden” ) und Tankstelle Zigaretten, Alkohol, Süßigkeiten, Getränke, z.T. Spielwaren (für die kleinen quengeligen Kinder auf der Fahrt in den Urlaub ) kaufen. In einer Drogerie gibt es z.T. auch Medikamente (rezeptfreie).
Wenn man nun das komplette Warenangebot komplett mit Semikolon eintragen möchte, hätte man sicherlich irgendwann eine ganz schön lange Liste (mal von dem Pflegeaufwand, wenn eine Ware aus dem Sortiment genommen wird, oder ein neues Angebot hinzukommt).
Ich denke mal, dass hier der Hauptzweck eines Geschäftes (nämlich z.B. der Schreibwarenhandel, der Zeitungskiosk, oder die Drogerie) im Vordergrund stehen sollte. Wenn es z.B. darum geht, die Möglichkeit der Fotokopien zusätzlich zu beschreiben, könnte man mit einem Zusatztag (z.B. copy=yes) ergänzen.
Bei einem Ticketshop würde ich dann ggf. einen separaten node anlegen.
Ich meine mich erinnern zu können, dass es vor ein paar Monaten mal eine Diskussion hinsichtlich von Lotto-Annahmestellen gab - finde es aber auf die Schnelle nicht. Das würde aber hier sicherlich ganz gut reinpassen.
VG,
Thorsten
Hallo DoDoMR,
Natürlich sage ich nicht, Geschäften, wo man nur ein Bleistift kaufen kann, shop=stationery hinzufügen 
Aber wenn es in einem Drogerie eine vollwertige Schreibwaren-Abteilung gibt, warum soll sie nicht gemappt sein? Das würde nutzlich für Menschen, die Schreibwaren suchen.
Noch ein tolles Beispiel: Ich habe viele große Laden gesehen, wo man gleichzeitig Alcohol und Zigaretten verkauft. Und die Angebot ist in jedem Fall weit! Wie kann ich das taggen?
Warum denn? Das ist ein Laden, ein Object in realen Welt, deshalb soll es mit ein Punkt gemarkt sein.
Mein Kommentar dazu:
Eigentlich sollte alles so bleiben wie es ist bezüglich dem Shop-Node (z.B shop=kiosk). Obwohl ich gegen Erweiterungen der shop-Bezeichnungen absolut nichts einzuwenden habe. Jetzt sind wir an einem Punkt angekommen, in dem das Warenangebot, wenigstens im groben, dargestellt werden soll.
Um mal beim Beispiel Kiosk zu bleiben. Hier sagt Wiki aus: http://wiki.openstreetmap.org/wiki/DE:Tag:shop%3Dkiosk
“Ein Kiosk ist ein kleines Geschäft, das Zigaretten, Zeitungen, Zeitschriften, Süßigkeiten und Getränke verkauft.”
Stimmt zwar oft, aber meißt ist das Angebot größer, selten kleiner. Wie erfassen wir jetzt das wirkliche Warenangebot eines Kiosks?
Mit einem Zusatztag. Mein Vorschlag wäre portfolio oder goods.
Dann würde das ganze so aussehen:
shop=kiosk
portfolio=cigarettes,newspapers,sweets,snacks,beverages
portfolio:de=Zigaretten,Zigarren,Zeitungen,Zeitschriften, Süßigkeiten,Getränke,Lotto....
Hier extra das Trennungszeichen Komma, weil das ganze Angebot in versch. Sprachen dargestellt werden soll. (Nicht nur die offiziell anerkannten, das könnte man mit Semikolon trennen.
portfolio=shoes;clothes;toys ...
Man könnte auch Vorschlag in #5 mit meinem Vorschlag kombinieren.
Mit meinem Vorschlag könnte man das komplette Angebot von allen Arten von Geschäften (nicht nur, auch von Firmen …) beschreiben, muss es aber nicht.
NG Rolf
Hallo,
also dass department_store oder kiosk mehr als nur einen Warentyp im Angebot hat, ist klar. Aber dabei ist auch klar, dass beide ein klar definiertes Warenangebot haben. kiosk: Schreibwaren, Rauchwaren, Lebensmittel
department_store: umfangreiches Warenangebot aus allen Lebensbereichen, häufig auch mit Lebensmittel.
Auch gibt es Läden, die bestimmte Waren als Nebengeschäft haben (z.B. - Achtung Werbung - Ernstings Familie hat Kleidung für Kinder und Mütter aber auch ein kleines Angebot an Spielzeug). Diese würde ich nur mit der Hauptwaren (hier clothes) mappen.
Es gibt aber Läden, die lassen sich nicht darunter einordnen. In meiner Stadt gibt es z.B. einen Laden, der gleichwertig Elektrogeräte (Waschmaschinen, Kühlschränke etc.) anbietet als auch Geschenkartikel (gifts). Zur Zeit ist diese Laden als shop=electronics;gifts getaggt.
Aber der Vorschlag:
shop=electronics
shop:electronics=main
shop:gifts=yes
gefällt mir hier ganz gut, um die Gleichwertigkeit des Angebotes zu dokumentieren. Ähnliches sollte auch bei craft gelten.
Da fällt mir ein, was wird eigentlich in dem Fall angezeigt, wenn man craft=painter und shop=paint auf einen node setzt?
Hmm… Eine radikale Idee:
Gar keine shop=shoptype, sondern shop:shoptype=yes/main.
Vorteile:
Keine “;” deshalb leicht unterstützt bei allen Datennutzer
Eine Mappingregel für alle Geschäfte
Die Möglichkeit, Läden mit mehreren Spezialisierungen einfach zu mappen.
Nachteile:
Ganz neue Mappingregel, alle Shops in der Welt sollen geändert werden.
Vielleicht noch etwas 
Renderer sollen nur shop:shoptype=main malen, aber in POI-search sollen alle shop:shoptype sein.
Was denkt ihr?
Nö! -10 Du willst doch keinen 3. Weltkrieg anfangen, oder? Hinterher werden aus lauter Panik nach dem weltumspannenden Change sämtliche shops geplündert… , nur weil sie nicht mehr in OSM gerendert werden und damit nicht existent… 
Ich würde die “Hauptfunktion” des Shops in shop=* packen, alleine schon aus Kompatibilitätsgründen. Und selbst wenn man die nicht ermitteln kann würde ich das nehmen, was das erste ist, als was man den Shop wahrnimmt. Alles weitere dann eben in shop:= aber sagte ich ja bereits.
Also, zur Klarstellun wie es aussieht:
In kleineren Orten in dm Osten, aber auch in Asien, ist es oft so, dass ein Laden mit einem Sortiment sich nicht über´s Wasser halten kann.
Und ide Miete für drei verschiedene Läden, sowie der Kundenkreis dafür wäre zu klein.
Dann gibt es also praktischerweise eben zwei - oft völlig unterschiedliche Sortimentgruppen in einem Geschäft. Manchmal sogar drei.
Ich habe mir so ein Laden vor-Ort angesehen und kann beim besten Willen nicht sagen, welche Funktion die wichtigste ist.
In dem Beispiel (in #1 von mir genannt,) sah ich praktisch drei verschiedene, völlig verschiedene Funktionen.
Es ist was anderes, wenn bei uns in einer Edeka eine Postfiliale ist und ein Handwerker Stempel, Visitenkarten und Shuhreparatur anbietet.
Ganz klar, wir haben eine Edeka in der man noch zwei weitere, unabhängige POI´s eintragen kann.
Im Osten war die Situation ganz anders. Ein Laden, ein Inhaber und z.B. Lebensmittel / Gartenmöbel/ Billigurlaub Verkauf in einem.
Dies machte die Antwort für mich so schwierig.
Grüße,
Marek
- shop=stationery, copyshop=yes, photo=no
- shop=newsagent, tickets=yes ( oder =football)
- shop=chemist, toys=yes, ( bag=yes, shoes=yes, … )
Die “Schlangenaufzählungen” sind m.E. schwerer auswertbar egal ob mit “,” oder “;”. (surface mit mehreren Werten moniert JOSM als Fehler)
Man kann ja auch an den shop=* description=* setzen, und dort aufzählen, was verkauft wird (kann dann auch angezeigt werden) - da lässt sich dann aber nicht mehr über eine einfache Suche finden.
Die Lösung mehrere shop-Nodes zu taggen sollte man vielleicht auch noch erwähnen.
Würde aber dem “One feature, one OSM element”-Prinzip widersprechen. Wobei man auch darüber diskutieren könnte, ob das nicht ein separates Feature sein darf, immrhin zerlegen wir auch Gebäude in bulding:parts, etc. Aber ja: die Möglichkeit existiert definitiv und wird auch schon des öfteren genutzt.
Nun, haben wir einige Ansätze. Alle haben gewisse Vor- und Nachteile.
Was nehmen wir nun?
Wie kommen wir zu einem Ergebnis?
Grüße,
Marek
Das mache ich, wenn über einen Eingang mehrere “Kioske” - also abgetrennte Lädchen - sind. Meist haben diese auch eigenen opereator, website , telefon.
M.E. Geht es um einen Laden mit einem operator, telefon. Das ähnlich Problem ist z.B die vielen Postfilialen/Paketannahmen, dort sind es aber meist abgetrennte Bereiche (Ecken), die einen Extranode erhalten können.
Tja, Ergebnis gibt’s sowieso nur über ein Proposal, da die Problematik da doch recht weitgreifend ist und die Lösung auf einer soliden Basis stehen sollte. Ich gebe auch zu bedenken, dass dieses Problem nicht nur shop=, sondern auch amenity= und wohl auch craft=*, etc. betrifft es also keine Lösung sein darf, die nicht flexibel genug ist, um auf all die dort auftreten könnenden Probleme eingehen zu können. Genau das trifft auf die Semikolon-Lösung nicht zu (z.B. kann man nicht die implizit enthaltenen Shop-Teile ausblenden wie etwa bei einem Kiosk der keine Snacks oder Getränke anbietet), auch ist sie nicht rückwärts kompatibel, da es derzeit wohl keinen Renderer gibt, der shop=kiosk;travel_agency rendern könnte. So wie ich das sehe, haben wir also 4 Ansätze:
-
Mehrere Nodes taggen
Vorteil: maximale Flexibilität, getrennte Öffnungszeiten, Stockwerke, Telefonnummern und Tags
Nachteil: Ziemlicher Overhead, da viele Tags dupliziert werden könnten/müssten, da sie für alle Bereiche identisch sind. Nicht ganz konform mit dem “One feature, one OSM element”-Prinzip - bietet sich aber vermutlich gerade bei Indoor-Mapping an, um zu zeigen, wo im Geschäft welcher Teil ist. Zusammengehörigkeit der einzelnen Nodes nicht immer erkennbar - woher weiß man, dass alle Nodes zum selben Geschäft gehören? -
Subtags nutzen
Vorteil: Unterscheidung zwischen Haupt- und Nebenangeboten (ähnlich Healthcare mit main/yes/partial) und explizites Ausschließen von Features (shop=kiosk shop:beverages=no) Rückwärtskompatibel, da shop=* das Haupttag trägt, mit dem es auf der karte erscheinen soll. Einfache maschinelle Abfrage (shop = X OR (shop:X = * AND shop:X != no)). Wenig tagging overhead.
Nachteil: Angeblich schwerer auswertbar für Renderer, wobei diese sowieso nur shop=* rendern müssten. Keine getrennten Tags für die Features, also keine getrennten Telefondurchwahlen, Öffnungszeiten, etc. -
Präzisierungstags ohne Subtag nutzen
Beispiel: shop=stationery, copyshop=yes, photo=no
Vorteil: Wenig overhead, rückwärtskompatibel, gut auswertbar
Nachteil: Nicht immer klar, auf was sich das Tag bezieht. shop=covenience beverages=no könnte heißen: Keine Getränke zu kaufen oder keine Getränke erlaubt (ähnlich dog=no). Sonst wie bei Subtags keine getrennten tags für die Features -
Description nutzen
Beispiel: shop=stationary, description:de=Verkauft keine Getränke
Vorteil: Wird schon jetzt teilweise dargestellt, kein neues Schema nötig. Maximale Flexibilität (description:de=Verkauft nur Wasser)
Nachteil: Machinelle Auswertung unmöglich, wartbarkeit bei mehreren Sprachen so gut wie nicht gegeben. Keine getrennten Öffnungszeiten, etc.
Habe ich etwas übersehen? Wir können ja gerne forums-intern einen Favoriten abstimmen und den dann als Proposal aufstellen, aber ich befürchte, dass es eine hoch emotionale Debatte wird.
Stimmt schon. Es ist aber auch ok. Sonst kommen wir zu keinem Ergebnis. Danke Dir für die gute Zusammenstellung.
Ich bin leider die nächsten Tage sehr knapp mit der Zeit. Könntest Du helfen und diese Erkenntnisse als Proposal zur Abstimmung platzieren?
Viele Grüße,
Marek