Restaurant nur für Gruppen und nach Anmeldung

War letzlich auf einer Wanderung und wollte ein alt-bekanntes Berg-Restaurant besuchen. Leider gab’s nichts zu Essen aber neue Oeffnungszeiten einzutragen:

  • Sonntag geschossen
  • Montag – Samstag : auf Anmeldung für Gruppen

Auf nachträgliche Anfrage per Email ist es wirklich nur noch für Gruppen geöffnet.

Aber wie soll man dies Eintragen? Macht es überhaup Sinn dies noch als amnety=restaurant einzutragen? Gibt es alternativen?

Was meint Ihr?

Sinn macht es allemahl, oder dürfen Gruppen nicht essen gehen und Gruppenangebote nicht in OSM finden?

opening_hours=Mo-Sa “auf Anmeldung für Gruppen”

Hallo,

Wenn ich unterwegs wäre und auf einem Garmin oder einer gedruckten OSM-Karte nach Restaurant suchen und dann zu besagten Gruppenrestaurant laufen würde, würde ich mich ziemlich aufregen und fragen, warum ich nicht gleich die Gelben Seiten benutzt habe (eine gedruckte Ansammlung von Karteileichen garniert mit proprietären, vor Eastereggs strotzenden Karten). Wärst du der Mapper, der ein Restaurant so getaggt hatte, würde ich dir eine aussagekräftige PN schreiben, wenn ich in diese Falle tappen würde. Anschließend würde ich das Ding in disused:amenity=restaurant umtaggen.

Nicht jede Plattform, auf der OSM-Daten eingesetzt werden, unterstützt Öffnungszeiten. Daran ist nicht der Entwickler schuld, der OSM auf diese Plattform bringt, sondern meist das Medium selbst. Ein Garmin kann mit Öffnungszeiten nichts anfangen und ich bezweifle, dass das überhaupt im Garmin-Format geht. Auf Papierkarten ist auch kein Platz für Öffnungszeiten. Willst du von jedem Datennutzer erwarten, dass dieser Öffnungszeiten von allen POIs parst? Das frisst Programmieraufwand, Rechenzeit und Leistung (Hardware).

Daher mein Vorschlag:
disused:amenity=restaurant
name=Burgrestaurant
description=nur für Gruppen auf Anfrage geöffnet

Es gibt im Nordosten Bayerns (u.a. Frankenwald) Gegenden, deren Tourismus seit dem Mauerfall zurückgegangen ist (z.B. Wallenfels). Dort findet man viele geschlossene Restaurants und auch mehrere, bei die nur noch nach Vereinbarung für Gruppen öffnen. Die Küche und der Gastraum ist dort noch vorhanden, aber investiert wird nichts mehr, da die nächste Generation das Lokal nicht mehr weiterführen wird.

Viele Grüße

Michael

disused ist definitv falsch, es wird ja genutzt, nur die Nutzer sind eingeschränkt.

Auf die PN würde ich mich freuen, es aber wieder zurücktaggen, denn es ist nach den Regeln korrekt…es ist ein in Benutzung befindliches Restaurant.
Man muss ein Nutzungstag dafür erfinden.

access=groups? :smiley:

Das wäre eine Lösung, das access-Tag entsprechen aufbohren.
Dann würde opening_hours=“Nach Anmeldung” ausreichen
Zusätzlich sollte man in description diesen Tatbestand nochmals beschreiben.

Mit der Argumentation könntest du auch Waldwege vom NRW-Atlas abmalen und als tracktype=grade5 taggen. Wenn man durchfahren will, kommt man schon durch, man muss bloß groß genug sein (Harvester statt Personengruppe), dann ist der Weg auch offen (nur halt nicht für jeden).

Ein stillgelegtes Bahngleis kann man recht einfach in Betrieb nehmen, es muss ggf. nur freigeschnitten und vom Gleismesszug befahren werden. Trotzdem kann ich da nicht einfach einen Tag vorher beim Betreiber anrufen und sagen “Ich will da morgen mit meinem Zug durchfahren. Kann ich das?”

Damit veränderst du die Bedeutung des ursprünglichen amenity=restaurant. Wie wäre es denn mit disused:amenity=restaurant + disusage_state=open_on_request?

Wenn ich das als ernste Antwort werten würde, wäre meine Antwort folgende:
access=* ist ein Key, der sehr sehr häufig verwendet wird. Neue Werte, die die Bedeutung des Haupt-Tags (amenity=, highway=, …) invertieren, sollten unbedingt vermieden werden.

Du willst doch wohl nicht ein Restaurant, welches man problemlos ohne “freischneiden” nutzen kann, mit einem zugewachsenen Bahngleis vergleichen…

Übersetze bitte mal “disused” … fällt was auf? Das Restaurant wird aber genutzt!

Techniker…tse…denk mal pragmatisch… :wink:

Im Übrigen passt Dein obiges Beispiel mit dem “umsonst zu einem Gruppenrestaurant laufen” nun überhaupt nicht. Wenn Öffnungszeiten nicht angezeigt werden, dann laufe ich auch so “umsonst” zu dem Restaurant z.B. an Ruhetagen…

edit: Doppelter Post

Wenn dein Ausgabegerät nicht das tut was du willst, oder dein Rendering dir Dinge anzeigt, die nicht vollständig sind…na, was machen wir da? Etwa die Datenbank ändern, so das sie für genau deinen Anwendungsfall passt? Sozusagen “taggen für den Renderer?” … ( dramatische Musik ab! )

Das glaub ich dir aufs Wort, und ich kann mir auch den Ton und die Wortwahl lebhaft vorstellen :stuck_out_tongue: No, konnte ich nicht. Die PN hat einen angenehmen Ton, wie ich finde.

SCNR

Ein Restaurant, das grade nicht offen hat, ist immernoch ein Restaurant. Eins, das nur nach Anmeldung offen hat, ist genauso eins wie eins, bei dem grade alle Tische besetzt sind. Es ist auf jeden Fall nicht disused.

Das Tag, was man neu erfinden könnte, wäre was in der Art von “Laufkundschaft erwünscht”. Ob das sinnvoll ist, weiss ich aber grad nicht aus dem Stehgreif.

Wie wäre es denn wenn man etwas wie opening_hours=limited hat und dann opening_hours:limited=… ? Oder auch resevation, appointment etc.

group_only=yes

ist auch bei einigen Jugendherbergen/Landschulheimen anzutreffen.

Das Problem ist, dass die meisten Karten und Apps das nicht beachten werden.

Naja, es gibt viele Tags, die von Karten und Apps nicht beachtet werden. Das darf nicht hindern, etwas detailliert zu beschreiben.
Group_only finde ich gut. opening_hours sollte trotzdem mindestens mit “nur mit Anmeldung” angegeben werden.

Das Problem hat man aber immer.

Ist es überhaupt ein Restaurant, wenn es in einem beliebigen Gebäude nach Anmeldung was zu Essen gibt?
Wenn ich Geburtstag habe, gibt es bei mir für angemeldete Gruppen auch was zu Essen und zu Trinken.
und wehe, einer trägt meine Wohnung als Restaurant ein.
Also theoretisch bin ich ja bei Thoschi, aber praktisch eher bei Nakaner.

Deshalb schlage ich jetzt folgendes Tagging vor:

amenity=restaurant
access=no
groups=yes

Wir erwarten doch von guten Karten/Apps, dass sie access=* auswerten, auch bei POIs, oder? Siehe hierzu auch den Fall der Höhlen und des Vandalen vom Dienst in den bayrischen Alpen.

Das Restaurant ist da, falls jemand eine Wohnumfeldanalyse machen will und Lärmquellen vermeiden möchte. Das Restaurant ist nicht da, wenn jemand als Laufkunde es sucht.

Hat jemand bessere Ideen?

Viele Grüße

Michael

Ich hätte jetzt fast geschrieben, eine Restaurant wäre bauordnungsrechtlich genehmigt (Restaurant != Wohnung) ist. Aber das muss nicht bei allen Lokalen richtig sein. :slight_smile: Außerdem kann man das höchstens in Ländern mit Informationsfreiheitsgesetzt prüfen.

Viele Grüße

Michael

Sach mal Michael,
bist Du Dir über die Sinnhaftigkeit Deiner Vorschläge wirklich im klaren? Access=no?? Sorry, aber hier erntest Du absolute Verständnislosigkeit! Sagst Du auch bei einem Arzt welcher nur nach Anmeldung Termine vergibt access=no?
Mir ist klar, dass Du Angst hast, 500 Meter umsonst zu laufen, aber irgendwo muss man in der Realität bleiben.
Da das Tag “group_only=yes” bereits existiert, wäre ein neues “group=yes” ja wohl Quatsch. “group_only” beinhaltet sowohl group=yes und impliziert gleichzeitig einen access-Tag.
Warum das Rad zweimal erfinden, nur weil man mit dem Kopf durch die Wand will?

@CADdog63: Ja, es ist ein Restaurant. Es ist doch unerheblich, ob es eine Einschränkung für die Nutzung gibt. Bei uns gibt es ein sehr hoch gelobtes Restaurant, welches nur 2mal die Woche öffnet und zwingend Reservierungen verlangt. Trotzdem ist es ein Restaurant. Was ist bei einer erforderlichen Anmeldung anders?
Wir haben ein Jugendzentrum, welches an bestimmten Tagen nur für Mädchen öffnet, aber es ist doch ein Jugendzentrum und kein Mädchenzentrum mit access=no oder Jungs=no…das regelt man über die opening_hours…

Also die sog. Besenwirtschaften sind somit keine Gaststätten? Hmmm…sollte man den Leuten mal sagen, dass sie in ihrem Wohnzimmer keine Getränke ausschenken dürfen…