das Thema Abgrenzung zwischen Bäckerei und Café ist wohl ein Dauerbrenner.
Im deutschen Wiki zu shop=bakery steht derzeit, man soll so etwas als shop=bakery und cafe=yes taggen. Das steht aber so nicht auf der englischen Seite und laut der englischen Seite hat cafe= eine ganz andere Bedeutung (Spezifizierung des Typs eines amenity=cafe), wird hier also scheinbar zweckentfremdet verwendet.
Das Problem ist, dass es Bäckereiketten gibt, die je nach Filiale teilweise nur Bäckerei sind (also keine Sitzplätze haben und keinen Kaffee verkaufen), teilweise aber auch eher Café (großer Sitzplatzbereich und man geht dort vor allem hin um Kaffee und Kuchen zu genießen). Nur sträubt es mir, die gleiche Kette anders zu taggen je nachdem wie die Filiale aussieht, und eigentlich gibt es für so etwas auch indoor_seating=yes um anzuzeigen dass die Bäckerei Sitzplätze anbietet.
In der Praxis hab ich hier schon alles gehen: Kombination shop=bakery mit amenity=cafe, eins von beiden, oder auch zwei getrennte Nodes für die gleiche Bäckereifiliale.
Aus diesem Grund bin ich eigentlich eher der Auffassung, dass die Unterscheidung danach getroffen werden sollte, ob auch ganze Brote und Brötchen (unbelegt) verkauft werden, denn in einem echten Café gibt es das nicht. Bin mir da aber immer noch unsicher.
Hallo,
da auch bei der gleichen “Bäckereikette” mache Filialen keins oder auch zusätzlich ein Cafe habe setze ich zwei Nodes mit entsprechenden Tags.
Einen für die Bäckerei und einen für das zugehörige Cafe
Was ist den gegen die Kombination shop=bakery mit amenity=cafe an einem element einzuwenden? Zwei getrennte nodes für einen Laden halte ich für falsch.
Solange die Suche und Filterung nach beidem funktioniert ist sowas doch zu erwarten. Man kann erkennen, dass es ein Bäcker mit Cafe ist.
Und sonst würde ich den Renderer in der Pflicht sehen solch eine Standardsituation aufzulösen.
Es ist eben keine Standardsituation. Für einen Renderer kann ein Objekt entweder Café oder Bäckerei sein - nicht aber beides. Es fängt schon damit an, dass dann ein Renderer entscheiden müsste, welches Icon zur Darstellung benutzt werden soll (siehe oben), und dann müsste z. B. ein Editor noch wissen, welche Vorlage zum Hinzufügen weiterer Tags angezeigt werden soll (die Vorlage für Bäckereien oder die für Cafés). Und diese Entscheidung kann ein Renderer nun mal nicht treffen, woher auch?
Dass unser Datenmodell theoretisch vorsieht, mehrere Arten von shop zu kombinieren, heißt nicht, dass man es auch tun soll, denn mit dieser Situation kommen die Renderer nicht klar. Eine ähnliche Situation gibt es z. B. auch bei Gemischtwarenläden in ländlichen Regionen, wo frische Back- und Fleischwaren, aber auch kleinere Dinge des täglichen Bedarfs angeboten werden. Könnte man auch als shop=bakery;supermarket taggen, erscheint dann halt nicht auf der Karte. Für die Geschäfte, die nebenbei noch Postfiliale/Paketannahmestelle sind, gibt es ja inzwischen eine Lösung mit post_partner=, warum hier nicht auch so etwas?
Ein Bäcker mit Café ist für mich in Mitteleuropa schon eine Standardsituation.
Und da kann ich jetzt eine neue Klasse oder neue Tags erfinden oder die bestehenden in Kombination entsprechend interpretieren.
Und warum soll ich einem Renderer nicht sagen können, das bestimmte Tags Priorität bei der Darstellung haben?
Ähnlich wie bei einer Tankstelle und da setzte ich tendenziell lieber getrennte Nodes für die unterschiedlichen Angebote (Tankstelle, Shop, Autowäsche, Werkstatt, Luft, etc.)
Wobei hier der Unterschied ist, dass Tankstelle und Shop häufig getrennte Öffnungszeiten haben (meistens ist der Shop nur tagsüber geöffnet, nachts macht der Shop zu aber tanken kann man über den Nachtschalter immer noch), teilweise sogar unterschiedliche Betreiber haben wie z. B. mit Aral und den Rewe To Go-Märkten.
Was ist das Problem daran den Renderegeln dafür ein neues Kombisymbol samt -regel hinzuzufügen und bei Editoren bei der Suche nach “Cafe” auch noch eine Vorlage für “Cafe + Bäckerei” mit in den Ergebnissen anzuzeigen?
Mittlerweile kommt es häufiger vor, ja. Die Ausprägungen sind halt doch sehr verschieden. Bei einem amenity=cafe erwarte ich schon, dass man sich gemütlich hinsetzten kann und ein Stück Kuchen essen kann und wäre enttäuscht eine Bäckerei vorzufinden, wo ich einen Becher Kaffee zu meinem Gebäck ordern kann und dies am Stehtisch in der Ecke verzehren kann…
Letzteres wird sinnvollerweise eher mit cafe=yes (aka hier kannst du auch einen Kaffee bekommen) eingetragen.
Aber das wäre dann ein Unterschied zwischen einem Bäcker mit Café und einem Bäcker wo man Kaffee bekommt. Die Frage wäre dann aber wiederum, wo man da die Grenze zieht.
Bäckerei-Cafe ist sicherlich kein “Einzelfall”, Bücherläden mit Café sind schon etwas spezieller, aber auch kein Einzelfall, beides könnte eine App durchaus spezifisch behandeln, bei einer deutschen Karte würde ich es für Café Bäckerei eigentlich erwarten, wenn sie “gut” gemacht ist und diesen Themenbereich abdeckt. Polnische Delikatessen und Optiker in einem? Das wäre ein Einzelfall (habe ich so gesehen).
Auszug aus DE:Key:drink:* drink ist das Präfix für verschiedene drink:*=* Schlüssel, die kennzeichnen, dass ein bestimmtes Getränk erhältlich ist.
Es wird als Ergänzung für amenity=pub, amenity=bar, shop=beverages, shop=alcohol usw. gebraucht.
Von shop=bakery steht da nichts.
Bei shop=bakery steht dafür:
Optionale Tags
cafe=yes - Die Bäckerei hat eine kleine Cafe-Ecke für den Sofortverzehr; bei größeren Cafè - Bäckerei Kombinationen sind getrennte Nodes sinnvoller.
@aighes schrieb “Hier kannst du auch einen Kaffee bekommen”, und genau dafür ist dieser Tag gemacht. cafe=yes eben (wenn überhaupt) nur, wenn man vor Ort auch verzehren kann