Abgrenzung Bäckerei/Café

Hallo

genau meine Vorgehensweise:
Kaffee im Stehen zu bekommen, dann an den Bäckereitag,
zum Hinsetzen und gemühtlich einen Kaffee mit Kuchen essen, seperater Tag Cafe

Gruß
Danfost

2 Likes

Kaffee != Café :yum:

3 Likes

Bei den vor dem “usw” aufgeführten Shops geht es ausschließlich im Shops wo vorwiegend Getränke verkauft werden. Eine Bäckerei gehört hier wohl nicht dazu.

Das kannst du so meinen, aber die tatsächliche Nutzung sieht anders aus, dieser Tag wird sehr häufig bei Bäckereien verwendet. Evtl. sogar häufiger als cafe=yes, die Info gibt Taginfo leider nicht her.

1 Like

Woher weißt Du dann, was mehr verwendet wird? :roll_eyes:

1 Like

“drink:coffee” etc. wird auch in Kombination mit noch ganz anderen Läden verwendet. Z.B. bei diesem Laden Node: 754607449 | OpenStreetMap, der vorwiegend Bekleidung verkauft, aber im Sommer auch ein paar Tische auf der Straße stehen hat und dort Kaffee und andere Getränke serviert.

Es würde helfen, wenn man sich z. B. mal auf eine Lösung für die häufigsten Fälle (also nicht jeder Kleinklecker-Spezialfall) von kombinierten Einrichtungen (Bäcker+Cafe, Restaurant+Cafe, Restaurant+Bar, …) einigen könnte. Noch besser wäre eine Erfassungslösung, die bezüglich der Zusatztags für solche Einrichtungen eindeutig ist, ohne das man zur mehrere-Knoten-für-eine-Einrichtung-Notlösung greifen muß.

3 Likes

Hotel/Restaurant (tourism=hotel + amenity=restaurant) ist auch recht beliebt.

Ich sehe kein Problem bei dieser Form des Taggings. Da gibt es mMn Schlimmeres. :yum:

3 Likes

Ich schon. Das fängt allein mit den Öffnungszeiten an…
Bei

Bäcker+Cafe

Habe ich da persönlich weniger Probleme, obwohl ich das Doppeltagging bisher nicht praktiziert habe in dem Bereich

1 Like

Das wäre tatsächlich schön, aber

und wird es auch bleiben, zumal sich hier gerne die Diskussionen mal im Kreis drehen und dann im Sande verlaufen oder abschweifen. Dafür könnte ich einige Beispiele nennen, was aber dann OT wäre und noch mehr dazu führen würde, dass die Diskussion abschweift oder …

Zum Problem an sich: Es sollten sich alle darüber im Klaren sein, dass OSM abstrahiert und wir die Wirklichkeit nicht 1zu1 abbilden können! Die Wahrheit liegt - wie im wahren Leben - oft in der Mitte!

… meint Uwe

1 Like

Datenmodell-mäßig wäre es vermultich sinnvoll, das physische Objekt = Gebäude/Räumlichkeit und die Nutzungen des Objektes getrennt zu erfassen. Idealerweise ist das Objekt natürlich als Fläche mit einem building=* erfasst. Kann natürlich auch nur ein node sein.

Die Nutzung(en) kann man dann per Relation sauber erfassen. Keine Ahnung, evtl. eine type=site oder aber auch ein ganz anderer type. Klar die zusätzliche Relation bringt mehr Komplexität mit sich, auf der anderen Seite erlaubt die Trennung, dass man mehrere Nutzungen individuell beschreiben kann und dennoch ein Link existiert zu allem, was noch vorhanden ist in dem physischen Objekt.

Supermärkte mit Bäcker, Fleischer oder Käsetheke
Restaurant mit Cafe
Restaurant mit Gästezimmer
Hotel mit Bar und Restaurant, Swimming pool…
Möbelhaus mit Restaurant

Mit mehreren Nodes geht das auch irgendwie, aber es wird nicht in den Daten deutlich, dass Cafe und Restaurant bspw. ein und das selbe Objekt sind. Oder ich zum Supermarkt-Eingang rein muss um zum Fleischer zu kommen.

Das Problem mit der Kombination amenity=cafe + shop=bakery ist doch, dass es nicht generell funktioniert, sondern nur, wenn man zwei verschiedene top-level-tags wie eben amenity und shop hat. Sobald ich einen Supermarkt mit eingebauten Bäcker taggen will, geht das nicht mehr, weil beide shop brauchen. Abgesehen davon ist es allerdings die simpelste und vermutlich auch verbreitetste Lösung, gerade bei Mappern, die nicht auf Mailinglisten, oder in Foren unterwegs sind. Das ist keine Unterstellung, ich hätte es selbst früher so gemappt, einfach weil es logisch klingt und scheint.

Wenn wir das jetzt aber “korrekt” taggen möchten, geht das mit den derzeitigen Bordmitteln nicht. Zwei Nodes, je einen pro Geschäftsteil, halte ich auch nur für eine weitere mögliche Notlösung, und eine Site-Relation geht auch nicht. Ich halte die Variante amenity=cafe + shop=bakery für ebenso richtig oder falsch, wie das Eintragen von zwei Nodes. Beides sind Möglichkeiten, die derzeitige „Unerfassbarkeit“ zu lösen, beide mit ihren eigenen Vor- und Nachteilen.

Ehe wir uns also weiter im Kreis drehen und hinterher wieder nichts dabei herauskommt, können wir entweder eine Auflistung erstellen, welche Vor- und Nachteile beide Mapping-Varianten haben, diese am besten im Wiki dokumentieren, oder aber wir suchen 3 oder 4 Freiwillige, die zusammen ein Proposal ausarbeiten, wie man die beiden grundsätzlichen Fälle erfassen soll. Und damit meine ich, um es politisch auszudrücken, einen „ergebnisoffenen Austausch“ bei dem auch herauskommen kann, dass wir das nicht brauchen, wollen oder es einfach zu umständlich ist. Ach ja, ich meine die folgenden zwei grundsätzlichen Fälle:

  1. Eine Haupteinrichtung mit X Nebeneinrichtungen, z.B.
    • Restaurant mit Gästezimmern
    • Hotel mit Café
    • Supermarkt mit Bäcker und Fleischtheke und Café
    • Buchladen mit Café
    • Autoverleih mit Gebrauchtwagenverkauf, Waschanlage und Tankstelle (ja, gibt es)
  2. Mehrere gleichwertige Haupteinrichtungen, optional mit X Nebeneinrichtungen, z.B.
    • Bäckerei mit Café
    • Kiosk mit Stehkneipe
    • Kaffeeverkauf mit Café
    • Metzger und Käsetheke
    • Tee- + Kaffee-Laden

Wenn sich keine Freiwilligen finden, dann war das Problem wohl nicht akut genug. Oder wir haben einfach zu viel zu tun. Oder einfach keine Lust. Gibt ja genug Gründe.

Um es einfach zu machen: Ich würde mich an so einem Proposal beteiligen, aber nicht alleine.
Mehr Mitstreiter = mehr Ideen = besseres Ergebnis

2 Likes

Doch, geht, mit Semikolon-Wert. Da sprechen auch ein paar Dinge dagegen, aber gehen tut das schon.

On important “top-level” tags that define what an element is avoid ; separated values whenever possible . Examples are highway=*, amenity=*,
[…]
It is not a good idea to map it as amenity=cafe;bar.

Also das würde ich jetzt mal wörtlich nehmen. Aber vielleicht stellt sich ja heraus, dass es weniger problematisch ist, als im Wiki steht. Muss man sehen :slight_smile:

1 Like

Ich war gerade 7 Wochen in UK, Dort ist ein Bäcker in der Regel jemand , der Backwaren verkauft und Backwaren sind Kuchen, Torten und Kekse. Und zwar an Tischen. Also wie bei uns im Cafe. Oft habe ich eine Bäckerei (laut OSM) aufgesucht und stand vor Erdbeertorten und Bienenstichblechen …
Für den Kauf von Brot und Brötchen musste ich meist in den Supermarkt.

Spielmops

Das ist das, was hierzulande abgrenzend zum Bäcker in einigen Landstrichen Konditor genannt wird (oder ganz althergebrachter Begriff: Zuckerbäcker). Diese Unterscheidung und Abgrenzung wird aber zunehmend seltener gebraucht.

Das Problem mit der Kombination amenity=cafe + shop=bakery ist doch, dass es nicht generell funktioniert, sondern nur, wenn man zwei verschiedene top-level-tags wie eben amenity und shop hat. Sobald ich einen Supermarkt mit eingebauten Bäcker taggen will, geht das nicht mehr, weil beide shop brauchen.

wobei diese beiden Fälle m.E. grundverschieden sind, beim Supermarkt ist noch ein Bäcker mit drin im selben Ladenraum, oder es werden vom Supermarkt Backwaren verkauft. Bei einer Bäckerei-Café betreibt derselbe (in der Regel Bäcker) auch ein Café (wo er ebenfalls Backwaren verkauft), d.h. es könnte als Unterkategorie von Bäckereien bzw. Café gesehen werden, eine Mischform. Beim Supermarkt ist das anders und der Backbereich untergeordnet in Relation zum gesamten Laden

Die unterschiede im EN und DE Wiki sind nicht gut, da müssen wir uns einigen.
Seit 2016 ist bei shop=bakery auf Englisch ein direkter Hinweis, man solle zwei getrennte Nodes nehmen:

If a cafe is in the same building, add another point and the corresponding properties.

Allerdings steht noch länger, nämlich seit 2015, im DE-Wiki der Satz:

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.

Wir könnten ja mal international vorschlagen, diesen Satz auch in EN einzubauen.

Wenn du mal auf Taginfo nach der Verwendung der cafe=* values schaust, siehst du, dass die stark überwiegende Mehrheit “cafe=yes” ist. Daher denke ich, dass die Seite key:cafe eher an die Realität angepasst werden sollte.

Ich kann leider nicht genug Overpass um eine echte Statistik für Haupt-Tags welche auch cafe=yes sind, zu erstellen. Ein paar Stichproben in verschiedenen Ecken der Welt zeigen z.B.

shop = bakery|supermarket|deli|convenience|chocolate|pastry|bookmaker|confectionery|furniture
tourism = attraction|hotel
leisure = sports_centre|hackerspace|outdoor_seating
amenity = restaurant|fuel|fast_food

Ob wir eine Regel finden, ab wann ein eigener Node mit amenity=cafe für ein Café in einer Bäckerei besser als cafe=yes ist, müssten wir diskutieren (und dann im Wiki dokumentieren).
Ich denke, solange die anderen Tags wie Öffnungszeiten, Name, Operator… sich nicht unterscheiden, kann auch ein großes Café mit Sitzplätzen einem Bäckerladen per cafe=yes untergeordnet werden. Dann wären alle Läden einer Bäckerei-Kette (worum es ja im OP ging) shop=bakery und bei denen mit Café wäre noch cafe=yes zu ergänzen.

Aber es stört mich auch nicht, wenn ein Mapper entscheidet, einen eigenen amenity=cafe Punkt zu ergänzen. Da müssten dann halt alle Öffnungszeiten usw auch dran, wenn man es genau nimmt.
Vielleicht können wir mit ein paar guten Fotos eine Abstimmung machen? Ist das noch ein Teil der Bäckerei oder schon was eigenes?

Stimmt – schon die Realität ist relativ :stuck_out_tongue: Und dann gibt es auch noch für (fast) jedes Problem in der Realität mehrere gute Lösungen in OSM :exploding_head:

Ein gemeinsamer Node für Bäckerei, Cafe, Toilette ist völlig OK, aber es ist genauso OK das in drei Punkte zu teilen oder sogar mit supergenauen Flächen zu arbeiten. Das macht es für die Daten-Nutzer aber leider nicht leichter.

1 Like

Ganz im Gegenteil, weil die Objekte/Features als eigenständige Objekte erfasst sind, macht es die Auswertung sogar einfacher.

Anderes Beispiel: Wenn ich in OSMAND nach dem nächsten Mülleimer suche, dann bekomme ich keine Kottütenspender oder Bushaltestellen mit bin=yes angezeigt.