Doordat ik object Fusion Plaza Zwolle wilde detailleren kwam ik er achter dat het restaurant concept: all you can eat nergens te definiëren valt
In de OSM wiki zie ik enige pogingen om het wel te willen definiëren (scroll helemaal naar onderaan de Tsjechische pagina)
all_you_can_eat=*
Maar wordt in ieder geval in de ID-editor als optie niet herkend en/of ondersteund.
Mijn mening:
Het restaurant concept ‘all you can eat’ laat zich het best definiëren als amenity=canteen met daarbij een tijdsduur restrictie.
Een ander kenmerkend verschil: een kantine is meestal veel soberder aangekleed (tevens vaak zonder formeel bestek sportkantine’s als voorbeeld nemend) dan in een ‘all you can eat’-restaurant.
Op de amenity=canteen pagina wordt verwezen naar de oplossing: amenity=fast_food + fast_food=cafeteria voor kantine maar is niet toepasbaar op het ‘all you can eat’-concept immers het eten betitelen als fast food is meestal niet toepasbaar op ‘all you can eat’-wok & grill bereidingen die daar vaak ook aangeboden worden.
Graag wat meningen en/of oplossingen voor het beter definiëren van ‘all you can eat’-restaurants.
Zelf dacht ik aan:
restaurant:concept= canteen; all_you_can_eat; fine_dining
Fine_dining staat nu onder cuisine=fine_dining en kan daar wat mij betreft blijven staan omdat fine_dining dan iets zegt over de bereidingswijze van het eten.
Restaurant:concept=fine_dining zegt dan iets over de aankleding en omgang met de klant die het restaurant hanteert.
Helemaal goed, snap alleen dan niet waarom binnen de ID-editor deze optie niet aangeboden wordt.
En doordat je als waarde alleen yes kan toevoegen kun je nu niet de maximale tijdsduur (kenmerkend voor het all you can eat-concept) op een nette manier definiëren.
Tags beginnen altijd klein; ID en Josm pakken ze pas op wanneer ze breder gebruikt worden. TagInfo is altijd handig voor zulke uitzonderingen die nog niet echt een breed gedragen tag hebben; je ziet dan wat andere mappers kozen en kan je dan aansluiten bij een die momentum lijkt op te pikken. Op een gegeven moment zet iemand hem wel op de wiki, en dan gaat het weer sneller, en bij 1000 keer gebruik kan hij zomaar eens bij een preset erbij komen. Het is maar net wie er tijd in steekt.
all_you_can_eat op een weg-definitie
Helaas kan de kaart niet laten zien waar dat zo gedefinieerd is, want dat maakt misschien duidelijk dat het wellicht helemaal niet slecht bedacht was.
Dat is verwarrend helaas. Een ‘way’ kan dus een lijn van nodes zijn die open of dicht kan zijn, of een lineaire weg.
Low-level gezien is een way een reeks van nodes. Of die dan open of dicht is wordt bepaald door de eerste en laatste node. Als dat dezelfde zijn, is de ‘way’ dicht, en is het mogelijk een vlak.
Of het een vlak is, hangt van de tags af, want een rotonde is ook een gesloten ‘way’, maar geen vlak, terwijl een building op een gesloten way altijd een vlak is.
In all you can eat restaurants is het meestal hoe meer je betaald hoe langer je mag blijven, dus ik weet niet of deze tag in deze vorm daar dan wel goed bij zou passen.
Cas, ik wilde de vraag net voorleggen aan de hand van dit object (Zelfde restaurantketen maar filiaal Almelo die 3 maxstay waarden hanteert).
Met de vraag of maxstay de ‘;’-tekens herkent en goed interpreteerd.
Dit neigt, naar mijn mening, naar een conditionele tariefsconstructie die in het leven geroepen moet worden als maxstay niet om kan gaan met meerdere waarden.
Wordt dit formaat ook zo aangehouden bij maxstay=* op andere objecten zoals parkeerplaatsen?
Los daarvan lijkt het me de standaardmanier waarop in OSM ‘subwaardes’ binnen een tagwaarde gescheiden worden. Het is dan aan (toekomstige) dataconsumenten om dit juist te interpreteren toch?
Dat is waar als dat de definitie verwachting is van maxstay.
Bij parkeerplaatsen is het altijd maar 1 waarde naar mijn weten.
Immers je mag daar bijv. vooraf vastgelegd alleen maar maximaal 2 uur staan, vooraf langer reserveren kan niet en daardoor een extra alternatieve waarde van maxstay zal daardoor nooit als veldwaarde ontstaan…
Als consequentie zal in de maxstay definitie nooit een keuze ‘;’-teken verwacht worden.
Bij all you can eat is dat anders want als je (verplicht) reserveert heb je 9 van de 10 de keuze voor een langere tijd waar je daar ook extra voor betaalt.
Het mooiste zou dus een tarief afhankelijke maxstay constructie zijn, met een andere naam want dan heb je en:
de tarifering en
de daarvan afhankelijketijdsduur en
de data processing verwachting
structureel goed gedefinieerd.
Maar naar mijn weten bestaat dat nog niet ?
Bijvoorbeeld tarifed_maxstay zodat dat ook breed toegepast kan worden op ook toekomstige andere activiteiten met verschillende tijdsduur & tariferingsrelatie.
Ik bedoelde het ook als mogelijke key waarden en inderdaad in goed beter best kwaliteitswaarde opsomming.
Wat mij betreft mag fast_food daar ook bij als waarde maar wil niemand een hartverzakking toebrengen kwa verandering ineens wetende dat er bij veel OSMers een kans bestaat dat er een soort van veranderingsallergie kan ontstaan.
Ben trouwens wel benieuwd naar hoe je dit draadje inhoudelijk vindt.
