Shop=< mehrere gleichwertige Funktionen>

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

  1. shop=stationery, copyshop=yes, photo=no
  2. shop=newsagent, tickets=yes ( oder =football)
  3. 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:

  1. 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?

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

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

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

Wenn es eine Geschäft ist, gibt es dort keine verschiedene Telefonnummern usw.

Mir gefällt am besten der Variant

Es ist leicht zu unterstützen (suchen nach shop=gifts und shop:gifts=yes).

Die Idee, einfach shop=stationery, copyshop=yes zu schreiben, finde ich schlecht. Diese Scheme überschneidet sich mit access=* und public_transport=. Es wäre besser, für Nebenangebot ein namespace zu benutzen (also **shop:=yes**).

Ich wage mal zu behaupten, dass die Schuhabteilung von Herti eine andere Durchwahl hat als die Schreibwarenabteilung :wink:

Hmm… Und warum ist das Thema still?

Das Thema ist parallel in der OSM Communitz in Polen diskutiert. Wir brauchen eine Proposal Seite und dort die Alternativen. Anschliessend eine Abstimmung.
Jemand muss diese Proposal Seite schreiben. Ich kann das erst nach der SOTM in Buenos Aires machen.
Wenn jemand (Du, Edward17?) diese Proposal seite früher macht, wäre das natürlich sehr schön.
Wir können diese Seite dann alle gemensam ergänzen.
Diskutiere diese verschieden Ideen auch in der Ukraine.

Viele Grüße,
Marek

Ich kann im Laufe der Woche gerne ein proposal schreiben, habe das allerdings noch nie gemacht. Bin momentan im Urlaub und großteils mit “Bespaßung” der Kinder beschäftigt. Mal sehen, wo ich da genug Zeit reinquetschen kann.

Klasse, vielen Dank.
Sag ob ich Dir irgendwie behilflich sein kann.
Viele Grüße!
Marek

Sodele, heute habe ich ein wenig Zeit gefunden, mich des Proposals zu widmen. Ich musste mich leider zunächst ein wenig in die Wiki-Syntax einlesen, kann also sein, dass man da noch einiges verbessern kann. Für Vorschläge und Kritik bin ich offen :slight_smile:

Klasse!
Ich danke Dir! :slight_smile: :slight_smile: :slight_smile:

Hast du es an die Tagging Mailingliste geschickt? Habe grade meinen Thunderbird geschossen, aber sehe es auch nicht auf der archiv seite.

Noch nicht. Ich wollte erst mal, dass Ihr, bzw. Marek und seine Freunde drueberschauen, ob sie noch Ideen haben, etwas vermissen, etc. Wenn dem nicht so ist, schick ich’s gerne auf den Weg.

Ich habe schon ein Post in dem poln. Forum platziert, unser Freund aus der Ukraine geht das sicherlich auch durch.
Lass uns noch einen Tag warten.

Viele Grüße,
Marek

Edit:
Ein Beispiel aus Polen: Bäckerei / Konditorei / Sex Shop :laughing:
http://forum.openstreetmap.org/viewtopic.php?pid=460561#p460561