ich will damit anfangen, Restaurants, Cafes, Fast_Foods etc mit einem Tag für evtl bewirtschaftete Außenbereiche zu versehen. Ich dachte da an outdoor_area=yes[no]. Es ärgert mich, dass man das bis jetzt noch nicht eintragen und damit auswerten kann.
Für Tipps oder Ideen wäre ich dankbar.
Ich würde das eher outdoor_service nennen. Schließlich geht es dir darum,
dass man draussen etwas zu essen/trinken bekommen kann und nicht darum,
ob es draussen einen Bereich gibt.
Dazu würde ich neben yes/no noch ‘self_service’ als möglichen Wert nehmen.
Eventuell wären auch ‘garden’, ‘terrace’ oder ‘sidewalk’ zur genaueren
Unterscheidung sinnvoll. (wenn schon, dann auch richtig )
In dem Fall würde Selbstbedienung besser mit
self_service=yes/no/outdoor/indoor
erfasst. Eventuelle auch self_service=takeaway.
Danke fürs erste Feedback. @ Edbert Es ging mir wirklich erstmal darum, ob das Cafe/Restaurant/etc überhaupt einen Aussenbereich anbieten. Ich fasse mal kurz zusammen
outdoor_area=yes/no
self_service=yes/no/outdoor/indoor
takeaway=yes/no/seasonal (finde ich irgendwie besser als self_service=takeaway, machmal kann man ja auch am Tisch warten und das Mitnehmessen wird gebracht // seasonal hier deshalb, da im Gegensatz zur Terasse etc, bei der sich jeder denken kann dass man da im Winter nichts bekommt, manche Lokalitäten im Winter trotzdem Coffee2Go verkaufen, manche aber nicht)
garden=yes/no/roofed/partial_roofed
terrace=yes/no/roofed/partial_roofed
winter_garden=yes/no
sidewalk=yes/no/roofed/partial_roofed (die letzten drei Tags würde ich ungern an outdoor_area hängen, da manche Lokalitäten mehrere Möglichkeiten bieten und dann wären wir wieder beim “;”)
kids_area=no/indoor/outdoor/both
takeaway=yes/no/seasonal (finde ich irgendwie besser als self_service=takeaway, machmal kann man ja auch am Tisch warten und das Mitnehmessen wird gebracht // seasonal hier deshalb, da im Gegensatz zur Terasse etc, bei der sich jeder denken kann dass man da im Winter nichts bekommt, manche Lokalitäten im Winter trotzdem Coffee2Go verkaufen, manche aber nicht)
Oder genauer
takeaway:ice=yes/no/seasonal
takeaway:coffee=yes/no/seasonal
takeaway:food=yes/no/seasonal
takeaway:beverages=yes/no/seasonal
garden=yes/no/roofed/partial_roofed
terrace=yes/no/roofed/partial_roofed
winter_garden=yes/no
sidewalk=yes/no/roofed/partial_roofed (die letzten drei Tags würde ich ungern an outdoor_area hängen, da manche Lokalitäten mehrere Möglichkeiten bieten und dann wären wir wieder beim “;”)
kids_area=no/indoor/outdoor/both
und in welcher Art sollte man das taggen können? Ich schlage vor als separater Node, als Area und auch als Multipolygon um diverse Sachen zusammenzufassen.
Das ist klar. Aber ich dachte nur, wenn Du ein Proposal hierzu erstellst, dass dies dann dort auch vermerkt ist (Applies to: Node, Area, Way, Relation).
ah okay. Danke für den Hinweis. Im Moment weiß ich allerdings garnicht, wie man ein Proposal erstellt. Bevor ich das mache, würde ich gerne noch ein paar Meinungen/Kritik/Tipps hören. Vielleicht stellt es ja auch jemand auf die Mailingliste
‘seasonal’ erschliest sich mir nicht wirklich.
In Wintersportgebieten ist die Außengastronmie auch/gerade im Winter offen.
Teilweise gibt es welche, die irgendwo an einer Skipiste liegen und nur
im Winter geöffnet haben.
Eventuell noch ‘self_service=only’ als zusätzlicher Wert.
Ich würde takeaway=yes/no/ice_cream/coffee/food/beverages/…
bevorzugen, statt die verschiedenen Sub-Keys (takeaway:…) zu benutzen.
Wie oben gesagt, erschliesst sich mir die Bedeutung von ‘seasonal’ nicht.
Weiter würde ich in Anlehnung an das Tagg ‘cuisine=ice_cream’ den Wert
‘ice_cream’ statt ‘ice’ bevorzugen.
Mich stören nur lange Listen von Schlüsseln mit ‘yes’/‘no’ als einzigen Werten.
So etwas sollte man zusammenfassen.
In diesem Fall gibt es ja mehrere Werte, die eigene Schlüssel rechtfertigen.
Das Tagg kids_area=* finde ich sehr gut. Das hat bisher gefehlt.
Was jetzt noch offen ist, sind Außengastronien, die als eigene Fläche
erfasst sind. ‘amenity=biergarten’ passt einfach nicht für alle Gegebenheiten.
Verstehe ich nicht. Seasonal heißt saisonabhängig, also in Wintersportgebieten wäre das im Winter. Ich hielt das variabele seasonal für besser als absolute Werte a la opening_hours
OK, danke
stimmt, es heißt ice_cream. Hatte ich nicht dran gedacht. Die Zusammenfassung finde ich kritisch. Gibt es nur ein Produkt (Kaffeeladen) lässt sich das über den kurzen takeaway=yes angeben. Andererseits gibt es Lokalitäten, die nur im Sommer Eis verkaufen aber das ganze Jahr über bspw Kaffee zum mitnehmen.
zusätzlich zu yes/no habe ich auf Wunsch von efred noch roofed (überdacht) und partial_roofed (teilweise überdacht) vorgeschlagen. Kam mir vernünftig vor. Es gibt ja Restaurants mit einem überdachten Straßenbereich und unüberdachten “Biergarten”. Auch ohne die Möglichkeit der Überdachung müsste man bei zwei Eigenschaften mit “;” arbeiten, was mir nicht so gut gefällt
zusätzlich vielleicht noch changing_table=yes/no (Wickeltisch)
Reine Außengastronomie fand ich unproblematisch. Da bekommt die Fläche dann halt den amenity=restaurant Tag und die neuen vorgeschlagenen Tags. Problematischer fand ich Restaurants, die ein building haben und eine Aussenfläche. Da müsste man dann die Gesamtfläche inkl. Haus und Aussenfläche einzeichen und nur der Fläche die Tags geben. Oder mit Site Relation arbeiten.
Aber wenn ich Dich richtig verstehe, fehlt für den Außenbereich ein Flächentag. Da bin ich im Moment etwas ratlos.
leicht verändert*
outdoor_area=yes/no
self_service=only/yes/no/outdoor/indoor
takeaway=yes/no/seasonal
Oder genauer
takeaway:ice_cream=yes/no/seasonal
takeaway:coffee=yes/no/seasonal
takeaway:food=yes/no/seasonal
takeaway:beverages=yes/no/seasonal
Die Verbindung von ‘take_away’ und ‘seasonal’ verstehe ich nicht.
Der Laden als solcher mag ja saisonabhängig offen/geschlossen sein, was dann
mit season=winter/summer/autumn/spring/wet/dry/snow/… zu taggen wäre.
Aber dass die Möglichkeit etwas zum Mitnehmen zu bekommen von der
Jahreszeit abhängig wäre, kenne ich nicht.
Ob nun ‘season=’ oder ‘seasonal=’ benutzt wird, ist mir dabei gleichgültig.
Muss man mal nachsehen, was gebräuchlicher ist.
Für typische Saisonprodukte wie Eis, Spargel, Erdbeeren usw. muss man
das meines Erachtens nicht extra aufführen.
Das mit roofed und partial_roofed ist gut, wobei man noch klären sollte,
ob das nur für fest angebrachte Dächer gelten soll (keine Sonnenschirme).
Mit ‘;’ getrennte Listen sind die Standardform für Taggs mit mehr als einem Wert.
Es gibt viele, die das nicht mögen und leider auch viele Programme, die das
ignorieren. Das führt nun leider zu der ‘xyz=yes/no’ Schwemme.
Ansonsten gibt es ja zur Vermeidung einer Liste den Ratschlag, sich auf das
Hauptprodukt zu beschränken, also ‘food’ statt ‘food;coffee’.
Ja genau um ein Restaurant als Gebäude mit Aussenbereich als eigene Fläche
geht es. Im Fall des Biergartens klappt das ja einfach.
amenity=restaurant würde gehen, aber die meisten Leute würden dort ein
Gebäude erwarten. Für den Fall nur Aussenbereich würde ‘outdoor_area=only’
wahrscheinlich passen. Aber für den Fall, dass Gebäude und Aussenbereich
als getrennte Flächen erfasst sind fehlt etwas, dass den Außenbereich mit
‘outdoor=???’ als zum Gebäude/Restaurant gehörig markieren könnte.
Ob ‘outdoor_area=affiliate’ passt oder ‘amenity=outdoor_restaurant’ oder
‘amenity=garden_restaurant’ oder … oder …?
Mir ist bei meinen Recherchen noch ‘patio’ für Innenhof aufgefallen.
Da das oft eine ganz besondere Atmosphäre ist, würde ich noch
patio=yes/no/roofed/partial_roofed vorschlagen.
Es ist zwar ein bischen aus der Mode gekommen, aber viele Wanderer nehmen auch heute noch Proviant mit auf ihren Weg. Daher interessiert mich bei einer Außengastronomie, ob der Verzehr von mitgebrachtem Essen geduldet wird.
Wie könnte man so etwas hinzufügen?
ich würde es roofed nennen, wenn man da im Regen sitzen kann. An bestimmten Merkmalen festmachen, halte ich für schwierig. Es gibt mittlerweile “Sonnenschirme”, unter denen sich ein veritables Unwetter überstehen läßt. Da ich";" persönlich nicht mag, würde ich erstmal dabei bleiben wollen. Auch mit dem “;” kann man einen überdachten Sidewalk und einen nicht überdachten Garten nicht mehr darstellen
dazu habe ich den outdoor_area Tag etwas modifiziert.
Fall 1 Restaurant (Building) mit Garten als Fläche: Jetzt kann man das Building mit amenity= restaurant und die Außenfläche mit outdoor_area=restaurant taggen. Es würde auch gehen, wenn man die gesamte Fläche als amenity Restaurant taggt, das building als building und die Außenfläche als outdoor_area=restaurant
Fall 2 Fast Food, Reiner Aussenbereich als Fläche: Auch einfach, einfach amenity=fast_food; outdoor_area=fast_food
Fall 3 Nur POI Node: Es passt auch alles in einen Node ohne an viel Aussagekraft zu verlieren. Es gibt nur ein Problem. Wenn man jetzt amenity_restaurant; outdoor_area=restaurant taggt, weiß man nicht mehr ob es einen Indoor-Bereich gibt. In diesem Fall müsste man outdoor_area=only taggen. Wobei das jetzt eher die Kür wäre.
Es hat übrigends auch den Vorteil, dass man einem Restaurant einen biergarten angliedern kann (amenity=restaurant; outdoor_area=biergarten)
Und wenn man es nicht genau weiß oder einfach keinen Bock hat es zu spezifizieren, kann man immernoch einfach nur outdoor_area=yes taggen.