Shop=< mehrere gleichwertige Funktionen>

Wenn dann shop=shoes;clothes;toys
Was erlaubt ist aber kaum ausgewertet wird.

Hallo Marek,

marek kleciak wrote:

Sollten wir nicht sowas wie shop=shoes|clothes|toys zulassen und in Wiki festschreiben?

Als Trennzeichen hat sich in OSM schon vor einigen Jahren das Seminkolon etabliert. Also bitte shop=shoes;clothes;toys.

So ein Multi-Value-Shop-Tagging hat den Nachteil, dass dumme Renderer und Auswerter, diese Läden nicht finden. Aber wir taggen ja nicht für die App. Gute Auswerter würden reguläre Ausdrücke verwenden (vielleicht mit dem Nachteil einer Performanceeinbuße). Wer also dann eine mittelmäßig gute Schuhgeschäftfindeapp entwickelt, verwendet bei der Abfrage statt

shop=shoes

shop=~/.*shoes.*/

und findet alle POIs, deren shop-Value shoes enthält (egal, ob an erster oder letzter Stelle oder irgendwo).

Obiges Beispiel enthält einen Bug. Die App meldet nämlich auch Treffer, die mit shop=working_shoes getaggt sind. :-)

Viele Grüße

Michael

Wollen wir dies in der Wiki unterbringen? Die Frage kommt nämlich wie ein Boomerang von den Newbies in den Foren in Osteuropa, wohl aber auch woanders.

Viele Grüße,
Marek

Hallo!

Mir gefällt die Idee shop=toys;clothes sehr.
Was die Rendenerer angeht: können sie z. B. die Icon "Schuhe" für alle Objecte malen, in deren Tag shop mit shoes beginnt? Wenn das Geschäft z. B. Schuhe und Spielzeugen verkauft, aber das wichtigste ist Schuhe, kann man schreiben shop=shoes;toys (die wichtigste steht am Anfang). Und wenn die Geschäft nur die Schuhe verkauft (und hat shop=shoes), wird es auch gerendert, weil shop beginnt mit shoes.
Was denkt ihr darüber?

Und noch: osm2mp schon jetzt kann shop=shoes;toys in 2 POI verschiedene convertieren.

P. S. Entschuldigung für mein nicht so gut Deutsch.

Sehr gut.
Mir gefällt wiederum der Vorschlag von Edward17
Wollen wir das Übliche mit dem Proposal und Abstimmung oder machen wir´s per Akklamation?

http://wiki.openstreetmap.org/wiki/Semi … _separator

Sehr schön. Dann dürfen wir sowieso darauf auf der Shop=* Seite hinweisen.
Viele Grüße,
Marek

Naja, ich halte das Semikolon-Tagging, so wie es auch das Wiki sagt, für einen Notbehelf. Ich fände es gerade bei Shops besser zum Subtagging zu greifen. Z.B.:

shop=clothes (zur Kompatibilität)
shop:clothes=main (oder eben nur yes, wenn gleich wichtig)
shop:shoes=yes
shop:toys=yes

anstatt shop=clothes;shoes;toys

Da beides derzeit nicht ausgewertet wird, sollte man, wenn man es zukunftssicher haben will, doch besser auf Subtags setzen - der Trend geht nicht grundlos eher in diese Richtung bei neuen Proposals. Ist aber nur meine persönliche Meinung, ich weiß, dass viele hier anders denken 😉

shop:shoes=yes
shop:toys=yes

Na ja, unsere Datenbank-Leute hatten sich aber auch schonmal beschwert wenn es im Key variable Teile gibt. 🤣

Nadjita wrote:

Naja, ich halte das Semikolon-Tagging, so wie es auch das Wiki sagt, für einen Notbehelf. Ich fände es gerade bei Shops besser zum Subtagging zu greifen. Z.B.:

shop=clothes (zur Kompatibilität)
shop:clothes=main (oder eben nur yes, wenn gleich wichtig)
shop:shoes=yes
shop:toys=yes

anstatt shop=clothes;shoes;toys

Da beides derzeit nicht ausgewertet wird, sollte man, wenn man es zukunftssicher haben will, doch besser auf Subtags setzen - der Trend geht nicht grundlos eher in diese Richtung bei neuen Proposals. Ist aber nur meine persönliche Meinung, ich weiß, dass viele hier anders denken 😉

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

DoDoMR wrote:

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=*

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/openstr … arto.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.

edward17 wrote:

DoDoMR wrote:

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=*

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.

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

DoDoMR wrote:

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

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?

Bei einem Ticketshop würde ich dann ggf. einen separaten node anlegen.

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?

Hmm... Eine radikale Idee:
Gar keine shop=*shoptype*, sondern shop:*shoptype*=yes/main.

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

edward17 wrote:

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

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.

chris66 wrote:

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

chris66 wrote:

Die Lösung mehrere shop-Nodes zu taggen sollte man vielleicht auch noch erwähnen.

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.

marek kleciak wrote:

Nun, haben wir einige Ansätze. Alle haben gewisse Vor- und Nachteile.
Was nehmen wir nun?
Wie kommen wir zu einem Ergebnis?

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.

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

2. Subtags nutzen

Keine getrennten Tags für die Features, also keine getrennten Telefondurchwahlen, Öffnungszeiten, etc.

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

Mir gefällt am besten der Variant

shop=electronics
shop:gifts=yes

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

edward17 wrote:

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

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

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 🙂

Klasse!
Ich danke Dir! 🙂 🙂 🙂

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 🤣
http://forum.openstreetmap.org/viewtopi … 61#p460561

marek kleciak wrote:

Ein Beispiel aus Polen: Bäckerei / Konditorei / Sex Shop

Ich bin mir nicht sicher, ob ich dort meine Brötchen holen würde 🙄
Vielleicht könnt Ihr ja ein paar solcher Beispiele zusammen mit Bildern in die Beispiel-Sektion einarbeiten, ich werde dasselbe hier auch machen. Wir haben ein paar Geschäfte mit mehreren Geschäftsfeldern, bin nur momentan am kränkeln und hab viel zu arbeiten.

Ich bin mir nicht sicher, ob ich dort meine Brötchen holen würde

Die haben ja sehr leckere Baguettes gehabt. 😉

Die Idee Beispiele zu sammeln ist gut, denn in der BRD ist sowas zugegeben, eine Randerscheinung.

Grüße,
Marek

Nadjita wrote:

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

OT: Danke für die korrekte Nutzung einer Definitionsliste 🙂

Vielen Dank, Nadjita, für das Proposal!

Im großen und ganzen, es gefällt mir. Aber eine Frage, die meiner Meinung nach geschrieben werden soll: wie viele Tags shop:*=main können sein? Ein oder mehrere?

In Fall, wenn es nur ein Tag shop:*=main gibt (und er ist gleich mit shop=*), halte ich shop:*=main Tag als überflüssige Duplizierung.

Aber in Fall, wenn es im Geschäft keine Hauptassortiment gibt (z. B. Alcohol-Zigaretten-Geschäft, wo viele Alkoholgetränken und so viele elite Zigaretten sind), sind 2 shop:*=main notwendig. Bleibt aber die Frage, und was schreiben in shop=*.

Hallo Edward!

edward17 wrote:

wie viele Tags shop:*=main können sein? Ein oder mehrere?

Es stimmt, dass ich das nicht erwähnt habe, tut mir leid. „Es kann nur einen geben“™. Deshalb ist implizit auch immer shop=* shop:*=main. Ich ergänze das nachher. Danke für den Hinweis.

Zur zweiten Frage: Wenn es kein Hauptgeschäftsfeld gibt, nimmt man x-mal shop:*=yes und muss trotzdem in den sauren Apfel beißen, sich dafür zu entscheiden, als was es gerendert werden soll. Aber diese Entscheidung kann ich niemandem abnehmen.

Nadjita wrote:

edward17 wrote:

wie viele Tags shop:*=main können sein? Ein oder mehrere?

„Es kann nur einen geben“™.

Hmmm, dann verstehe ich nicht, wofür wir shop:*=main brauchen. shop=* spielt eine gleiche Rolle und wird dazu gerendert.

Nadjita wrote:

Zur zweiten Frage: Wenn es kein Hauptgeschäftsfeld gibt

Z. B: ein Geschäft, wo viele Alkoholgetränken und so viele Zigaretten sind. Ich meine, es muss so bezeichnet sein:
shop=alcohol
shop:tobacco=yes
shop:alcohol=yes - um zu zeigen, dass Alkohol kein Hauptgeschäftsfeld ist.

edward17 wrote:

Hmmm, dann verstehe ich nicht, wofür wir shop:*=main brauchen. shop=* spielt eine gleiche Rolle und wird dazu gerendert.

Naja grundsätzlich, weil das Tagging dann konsistent ist, aber natürlich hast Du recht, dass man es nicht unbedingt als expliziten Wert benötigt. Ich komme aus der Programmierwelt und dort kann man normalerweise alle impliziten Flags auch immer explizit mitgeben, einfach weil es dann leichter zu lesen und auch zu verstehen ist. Ich lebe da eher nach der Devise "Programs should be written for people to read, and only incidentally for machines to execute."* Ich weiß, OSM ist kein Programm, aber so denke ich nunmal 😉

Und ja, das Tagging für zwei gleichwertige Geschäftsfelder wäre korrekt. Wenn irgendwann einmal ein Renderer lieber shop:* als shop=* rendern möchte (wenn vorhanden), so sind nun alle Infos dazu vorhanden. Wie auch immer das aussehen würde.
Ich hab keine Ahnung, wie man Geschäfte halb Erotik halb Bäcker darstellen wollte auf einer Karte, aber rein vom äußerlichen wirkt das Geschäft in Mareks Beispiel auf mich eher wie ein Erotik-Shop, also würde ich das nicht als shop=bakery taggen. Ich würde das immer jeweils von der Situation vor Ort abhängig machen und in Deinem Beispiel mit Alkohol und Tabbak das nehmen, was äußerlich am ehesten ins Auge springt.

• aus "Structure and Interpretation of Computer Programs" von Abelson and Sussman
  

Eine Frage (und Idee?):
Zum Beispiel, ein Geschäft, das weibliche Kleidung (Hauptassortiment) und weibliche Schuhe (Nebenassortiment) verkauft. Es soll so gemarkt werden:
shop=clothes
clothes=women
shop:shoes=yes
shoes=women
Wäre diese Variante besser:
shop=clothes
clothes=women
shop:shoes=women

Und: warum erwähnt niemand Semikolon?

edward17 wrote:

Wäre diese Variante besser:
shop=clothes
clothes=women
shop:shoes=women

Am besten wäre eigentlich
shop=clothes
shop:shoes=yes
clothes:women=yes
shoes:women=yes.

Und: warum erwähnt niemand Semikolon?

Weil es zum Auswerten nicht wirklich schön ist.

Hm... nach meinem Proposal gäbe es zwei Möglichkeiten:

shop=clothes
clothes=women
shop:shoes=yes
shoes=women

oder

shop=clothes
shop:clothes:clothes=women
shop:shoes=yes
shop:shoes:shoes=women

Das erste wäre mit allen derzeitigen Auswertern kompatibel, das zweite Beispiel sieht zugegebenermaßen dämlich aus, nutzt aber die Namespaces shop:*, um Features abzutrennen. Ich gebe AndiG88 recht, dass es natürlich am schönsten wäre, wenn man auch hier wieder in die Richtung X:Y=main/yes/partial/no geht anstatt X=Y. Auf diese Weise könnte man dann wieder wunderbar geschäfte wie diese mappen:

shop=clothes (impliziert shop:clothes=main)
clothes=women (impliziert clothes:women=main)
shop:shoes=yes
shoes=women (impliziert shoes:women=main)
shoes:men=partial
shoes:orthopaedic=partial
shoes:oversize=partial

Was mit dem derzeitigen Tagging nicht ginge. Allerdings wollte ich eine solche "Revolution" jetzt nicht starten ;o)

Nadjita wrote:

Allerdings wollte ich eine solche "Revolution" jetzt nicht starten ;o)

Ich denke das gehört hier auch nicht direkt mit rein. Das hängt einfach vom shop typ ab ob : oder = mehr Sinn macht z.B. wenn ich nur Mann/Frau unterscheiden will.

Sorry das ich querschieße:
Gibt es einen Grund ein Proposal nur für shop zu entwerfen? Es gibt ja durchaus auch andere POIs, die zwei unterschiedliche Dienstleistungen/Waren anbieten.

Mir fallen da typischerweise so Gasthöfe auf die auch Unterkunftsmöglichkeiten bieten (klar die Tags amenity=restaurant und tourism=guest_house o.ä. haben keine problematischen Namensraumüberschneidungen, aber es wäre ja schön das Hauptgewerbe festlegen zu können),

Oder beispielsweise in meinem Ort gibt es einen Schlachter, der zusätzlich zum Thekenverkauf auch Imbiss ist und Partyservice bietet.

Oder ein Cafe das auch eine Rösterei beinhaltet und ein Restaurant, dass eigenes Bier braut.

Es gibt zahlreiche Geschäfte und Betriebe, die sich nicht so einfach Kategorisieren lassen. Wäre doch schön eine allgemeine Vorgehensweise für solche POIs zu etablieren.

P.S. Bitte nicht hauen, ich habe weder die ganze Diskussion gelesen, noch das Proposal intensiver betrachtet 😉

Hmmm..da ich gerade mal wieder mit dieser Problematik beim mappen befasst bin, was ist denn aus diesem
Proposal geworden?

Thoschi wrote:

Hmmm..da ich gerade mal wieder mit dieser Problematik beim mappen befasst bin, was ist denn aus diesem
Proposal geworden?

Hast es ja mitbekommen. Erst mal wurde es stillgelegt. Sollte aber weiter aufgebaut werden. Siehe: http://forum.openstreetmap.org/viewtopic.php?id=46983
Wer hilft mit, das Proposal zu finishen?
Bin der Meinung, das es erstmal bei shop mit verschiedenen Zweigen bleiben kann. Das wäre schon extrem hilfreich.
Alternativ oder ergänzend könnte ich auch nur eine Beschreibung erstellen (De/En) und erst mal eine Testzeit laufen lassen. Verschiedene neue tags laufen auch ohne Proposal, wie ihr alle wisst. Problematisch ist dann nur das rendering, was wir hier aber auch nicht unbedingt brauchen. (Hauptshop-Symbol)

Rogehm wrote:

Sollte aber weiter aufgebaut werden.

Was meinst Du? Etwas ins Proposal hinzufügen? Oder einfach Abstimmung machen ("Voting" auf Englisch; ich weiß nicht, wie man das auf Deutsch richtig sagt)?

P. S. Ich weiß nicht, wofür wurde dieses Thema gemacht. Meiner Meinung nach wäre es besser, einfach hier zu schreiben.

edward17 wrote:

Was meinst Du? Etwas ins Proposal hinzufügen? Oder einfach Abstimmung machen...

Beides. Weiter ausdiskutieren, vervollständigen, voten...!
Hier geht es um shop im shop. Einer der vielen noch ungelösten Probleme in der OSM. Ich halte das Proposal im Ansatz für gut und verwendungsfähig, wenngleich mir die Ausführlichkeit noch etwas missfällt. Hier sollte man den Vorschlag deutlich "aufpeppen" im Konsens einer weiteren Diskussion. Ich würde mich hier beteiligen. Vielleicht ist auch eine Abfrage vorher sinnvoll, was mit "Shop im Shop" passieren soll.
Meine jetzige vorbereitete Abfrage amenity + shop ist eine andere Zusammenstellung und passt nicht in diesen Thread.

Vielleicht sollen diese Links in den Proposal hinzugefügt sein, um zu zeigen, dass die Schemen shop:*=* und craft:*=* benutzt werden:
http://overpass-turbo.eu/s/ccB
http://overpass-turbo.eu/s/ccD

edward17 wrote:

Vielleicht sollen diese Links in den Proposal hinzugefügt sein, um zu zeigen, dass die Schemen shop:*=* und craft:*=* benutzt werden:

Der reguläre Ausdruck müsste noch mit ^ geankert werden, sonst passiert das hier:

node(2092138068)[~"shop:"~"."];out;

Also, ich habe mal so abgefragt:
http://overpass-turbo.eu/s/ce0

Dabei sollten noch eine ganze Menge shop:* ausgefiltert werden, um zu einen einigermaßen genauen Abfrage für dieses proposal zu kommen.
Nämlich:
shop:de ; shop:vakant ; shop:type ; shop:description ; shop:number ; shop:disused ; shop:historic ; shop:entrance ; shop:start_date ; shop:name ; shop:operator

Ich bin kein Overpass Profi, im Gegenteil. Vielleicht macht sich jemand die Mühe, diese tags auszuschließen.
Aber im Prinzip bleibt nicht mehr viel übrig.

Durch diese bunte Vielfalt im tagging shop:X=Y sehe ich ganz stark die Felle schwimmen für dieses Proposal. Leider.

Anh: OT: Bei verschiedenen Abfragen habe ich gemerkt, das unsere Niederländischen Kollegen sehr aktiv sind und tlw sehr merkwürdige Kombinationen taggen. Ist das auch schon jemand aufgefallen? Hier: shop:number=X (Auch in anderen Bereichen mit unbeschriebenen tags).
Nichts dagegen. Aber was steckt dahinter?

Rogehm wrote:

Also, ich habe mal so abgefragt:
http://overpass-turbo.eu/s/ce0

Dabei sollten noch eine ganze Menge shop:* ausgefiltert werden, um zu einen einigermaßen genauen Abfrage für dieses proposal zu kommen.
Nämlich:
shop:de ; shop:vakant ; shop:type ; shop:description ; shop:number ; shop:disused ; shop:historic ; shop:entrance ; shop:start_date ; shop:name ; shop:operator

s/vakant/vacant/ 😉

Gruss
walter

s/vakant/vacant/

Danke, Walter.

Aber nichtsdestotrotz komme ich zum Schluß, das ein tagging-Schema: shop:1=bakery ... shop:2=pastry,
also ein tagging mit Ziffern für die Einstufung un Priorisierung noch nicht "verseucht" ist, und damit eine gute Chanche hat.
Siehe: http://forum.openstreetmap.org/viewtopic.php?id=52421

Habe zufällig gefunden. Issue in Repository von Standart Layer über mehrere Werte im shop=*-Tag. Nur 2 Wochen alt.
https://github.com/gravitystorm/openstr … ssues/1979