Tagging: Hotel Restaurant Café

Als je een Hotel Restaurant Café wil taggen, hoe kun je dit het beste doen?
3 nodes in het pand zetten (waarvan 1 gemerged met de adresnode) of zijn er andere opties?
In dit voorbeeld heeft het pand 1 adresnode.

Deze vraag geld eigenlijk voor meer functies van een pand.
Natuurlijk kan ik me voorstellen dat er meerdere adressen in een pand kunnen zitten, dan is het ook niet zo moeilijk, dan zet je het op de bewuste adresnode.

Het gaat erom als je 1 adresnode hebt en dan meerdere functies.

Samenvattende conclusie:*

Een gebouw met 1 adres met meerdere functies kun je het beste als volgt taggen:

1. Gebouw
2. POI Hotel + adres + naam + aanverwante tags voor het hotel
3. POI Restaurant + adres + naam + aanverwante tags voor het restaurant.
4. POI Café + adres + naam + aanverwante tags voor het café

Voorstel: Laat de naam uit de OpenKvK bepalend zijn, meestal is dat de naam in de contactgevens op de website van het bedrijf.
Mocht een (of meerdere) functies een aparte ingang hebben, tag deze dan op de juiste posities dmv entrance=main (evt door entrence=yes)

*Mocht het zijn dat er bijvoorbeeld een speeltuin en midgetgolfbaan aanwezig is, kun je deze het beste op de betreffende positie plaatsen, als je een restaurant zoekt zal je deze vinden en als je een speeltuin zoekt zal je deze ook vinden. *

*Voordeel van bovenstaande tagging:

  • Makkelijk voor de render en eerder zichtbaar voor gebruikers, (simpele render structuur)
  • Alles enkelvoudig per poi getagd, gevolg op alle node een adrestag.
  • Offline rendering (capaciteit rendering device) wel meer data voor opslag.
  • Openingstijden zijn per functie te vinden.
  • Wat niet in de database zit, kan ook niet worden gerenderd. (bovenstaande tagging is dus een voordeel tov andere tag methodes)*
  • is dat je kunt vinden wat je wil vinden, en een tweede voordeel is dat je de aanverwante tags, bv openingstijden per functie kunt aangeven op de POI.*

*Nadeel van bovenstaande tagging:

  • Grote kakofonie van icoontjes op de kaart, dit is extremer bij een geschiktgemaakte OSM kaart voor GPS. Er zal door de renderer een (altijd) keus gemaakt worden wat wel en wat niet visueel zichtbaar is op de door hem/haar gemaakte kaart. Het is geen belemmering om het middels voorgestelde bovenstaande methode te taggen. Zo kan een renderer de keuze blijven maken. In bovenstaande methode worden middels de zoekfunctie, de POI’s namelijk wel gevonden ook al worden ze niet op de kaart gerenderd.
  • Alternatieve tagging amenity=restaurant;cafe worden niet alom gewaardeerd, o.a. niet door Osmose.*

Een methode om een relatie te maken ivm redundant (overbodige/dubbele) tagging (adres en naamsvermelding) is een overweging, dit zal complexer zijn voor een “beginnende” mapper. Of dit verstandig is zal eerst besproken kunnen gaan worden.

Misschien de primaire functie (‘hotel’) als tag gebruiken en in de naam in dit geval Hotel café restaurant?

Nee!
Waarom niet? Denk even vanuit gebruikersperspectief…

Volgens http://wiki.openstreetmap.org/wiki/Tag:tourism%3Dhotel dien je de hoofdfunctie aan te duiden.

Maar wat houd je tegen om alle drie functies aan het pand te taggen; hoe e.e.a. rendert - maar we taggen toch niet voor de renderer - moet je dan maar eens checken?

Gebruikersperspectief:

  • Een gebruiker is geen renderer.
  • Als gebruiker interesseert het me niets hoe OSM vindt dat dit getagd moet worden.
  • Als gebruiker zoek ik een restaurant (om te eten) en kan dat niet vinden omdat ik dan niet op naam zoek maar op POI categorie. Een hotel is niet (altijd) een restaurant.

Dan tag je toch alle drie de functies?

Ik weet trouwens niet of er een zoekfunctie bestaat voor alleenetende zeurpieten ;-)Maar ja: laten we de reactie van de TS maar even afwachten.

Ik ben het niet eens met de classificering “zeurpiet”
Persoonlijk denk ik met AnkEric mee, dit heeft namelijk ook mijn voorkeur.

De argumentatie vind ik daarin bepalend.

Wel blijft dan de vraag of je op alle 3 losse nodes ook het adres mag plaatsen.

Hier suggereer je om de primaire functie (‘hotel’) als tag gebruiken en in de naam in dit geval Hotel café restaurant.
Je suggereert hier dus niet: “Dan tag je toch alle drie de functies?”
Dus “restaurant” wordt niet getagd als afzonderlijke POI, maar staat alleen in de naam. En dus kan ik niet zoeken op restaurant.

:rage: :rage: :rage: :rage:

@Moderator:
Iemand die wel wil kunnen zoeken op een restaurant en dat niet kan omdat dit onjuist/onvolledig is getagd op OSM (hoeveel praktijk voorbeelden wil je hebben?) is een “zeurpiet”?
En “alleenetend”? Goh, bijzonder, Anke is de verantwoordelijke navigator (en gebruiker) die in ons geval op de tandem tegen dit - praktijk - probleem aanloopt.

Mee eens,…

en ook wanneer het restaurant gesloten is, de keuken dicht gaat. Na die tijd is alleen het cafe open.

Dat is wat een gebruiker wil zien en niet aan een dichte deur komen.

Ik zou niet op drie verschillende nodes hetzelfde adres plakken. Dat zou drie plekken met een identiek adres opleveren in de database en dat is toch niet de bedoeling?

Maar wat is er mis om aan dezelfde node waar ook het adres aan hangt de drie functies H, C, R te plakken? Drie functies aan een enkel object gekoppeld is toch wel mogelijk en syntactisch juist? Zoek je de functie, dan vind je de node en dus het adres?

Alles 'mag' in OSM, niet alles is nuttig en vandalisme (wat hier niet aan de orde is overigens) wordt snel rechtgezet.. en "Als gebruiker interesseert het me niets hoe OSM vind [sic!] dat dit getagd moet worden." vind ik een beetje zeurderig, maar dat zal mijn opvatting wel zijn...

Als draait weer om de rendering. Ook in offline modus. Gebruikers vriendelijk.

Maar ik wil wel alle functies op de kaart zien. Niet over elkaar heen geprojecteerd.
Per functie zijn er openingstijden.

Binnen het gebouw zijn de functie’s vaak op verschillende plaatsen. Soms met een eigen ingang.

Martin, voorgaande opmerkingen zijn al behandelt als niet ter zake doende,

Dat verbaast je na de BAG import toch niet bv een pand met 2 nodes krijgt twee adressen conform BAG en de ondernemer noemt bij adres 31 - 33 beide panden dus. De toevoeging horeca, cafe - restaurant levert hem nog een adres op hetzelfde pand. Om van de aanliggende minigolfbaan aan de achterzijde (te regelen aan de bar) maar niet te spreken ! In dit geval dus wel 4 nodes op een pand en dan blijft de golfbaan achter de zaak onvermeld.

Jammer dat het “persoonlijke” af en toe de overhand krijgt. Het lijkt me dat er met argumenten gestreden kan worden.
Dat vingerwijzende geeft zo’n akelig beeld, maar dit terzijde.

Lijkt mij ook.

Adres op een hotel poi, de ander twee niet.
Dan moet de render daar toch al de koppeling maken voor deze twee.

Dan kan je net zo goed een losse node voor adres handhaven, en voor de drie poi’s de koppeling maken.

Of je doet dit, of je zet op alle poi het adres.

Is het een idee als de topic starter de argumenten verzamelt in de openingstopic.
Met deze gedachte loop ik al langer, bij het terugzoeken naar …en dan het hele topic doorlezen.

Argumenten:

  • makkelijk voor de render en eerder zichtbaar voor gebruikers, (simpele render structuur)

    • alles enkelvoudig per poi getagd, gevolg op alle node een adrestag
    • offline rendering (capaciteit rendering device) wel meer data voor opslag
  • plaats poi activiteit in het gebouw of er buiten

  • plaats poi ingang activiteit in het gebouw

  • openingstijden per poi activiteit getagd

Allroads, goed idee 'k ben benieuwd.

Het is iig op meer plaatsen een vraag…met een suggestie:
https://help.openstreetmap.org/questions/26625/buildings-with-more-than-one-amenity

Re ‘zeurpiet’ @ martin & anserik
Gaarne reacties niet op de man alsmede online een dikkere huid aantrekken. Dat maakt discussiëren over meningsverschillen een stuk prettiger. Bedankt!

Re tagging.
Anserik: de osm kaart op www.osm.org is slechts 1 (een) realisatie van de data en er wordt bewust niet alles weergegeven. Dat kan ook niet, dan zou je een grote kakofonie van icoontjes zien en als gevolg is deze kaart niet geschikt voor elke toepassing. Als je specifieke zaken op de kaart wilt zien dan dien je er een verzoek voor in of je maakt een eigen stylesheet. Je in bochten wringen en taggen voor de renderer is de verkeerde oplossing.

Dit is zeker een idee, in Gathering.tweakers.net is dit succes imiddels al lang bewezen.
Het zou handig zijn om een aantal moderators hiervoor aan te wijzen, die op een objectieve, chronologische wijze structuur geeft aan een topic. Het voordeel is dat een bestaand topic behouden kan worden, waar een inmiddels zeer goed uitgewerkte topic makkelijk te lezen is door een (nieuw) forumlid.

Misschien dat Lambertus en Ligfietser hierover kunnen brainstormen.
Het zou dan “getest” kunnen worden in het users:Netherlands gedeelte.

Het is immers lastig voor een topic starter om een samenvatting te maken. Deze heeft (op dit moment) alleen de rechten om de openingstopic te muteren. Dit kan overruled worden door aangewezen moderators.

Als hier plaats is voor [sic!] reacties daar waar een “t” ontbreekt: de naam is niet “anserik”.

Ik dien een “een dikkere huid aan te trekken”?
Dus voor “alleenetende zeurpiet” worden uitgemaakt is de normale omgangsvorm op een gemodereerd forum? Ja, dan is inderdaad een “dikkere huid aantrekken” een vereiste voor het geven van een mening als gebruiker op dit forum. Of in feite voor het geven van “gebruikers feedback”.
Alweer: :rage: :rage: :rage: :rage:
Edit: “alleenetende zeurpiet” moet waarschijnlijk/mogelijk worden gelezen als: “zeurpiet, die in een hotel alleen wil eten”. Blijft een voorbeeld van slecht formuleren (“taggen”) en beledigend. En [sic!]: dan ontbreekt er wel een spatie.

Dit is volstrekte nonsens!
OSM is iets anders dan www.osm.org.
OSM is de database en deze bevat wel of geen object/aanduiding/property/kenmerk" (hoe dan ook) voor hotel, restaurant.
Dat betekent dus geen “grote kakofonie van icoontjes” (dat is de keuze van de renderer, bijvoorbeeld: www.osm.org). Als je niet meerdere icoontjes in één gebouw wilt opnemen in OSM (de database) ga dan eens beginnen met de grote winkelcentra. Daar zie je niets anders: bakker, slager, drogist, kapper, allemaal in één gebouw. Allemaal met hun eigen icoontje.

Zinloos, been there done that. Antwoord: “dan maak je toch je eigen kaart”.
Bovendien: wat niet in de database zit, kan ook niet worden gerenderd. Ook niet als ik mijn eigen kaart maak.

Stylesheet heeft geen enkele invloed op hetgeen niet wordt gerenderd. Stylesheet kan alleen POI’s onzichtbaar maken die wél worden gerenderd, maar die ik niet wil zien. Bijvoorbeeld: scholen, bushaltes enz.
Maar een stylesheet kan niet zichtbaar maken hetgeen niet in OSM (de database) zit en kan niet zichtbaar maken hetgeen niet wordt gerenderd.

Maar ik begrijp inmiddels dat ik niet mag verwachten dat ik een restaurant kan vinden als dat restaurant - toevallig - óók een hotel is. Ik heb er nota van genomen.
Gewoon weer een Garmin kaart kopen, of mijn oude City Navigator gebruiken!

Trouwens, in reactie op degenen die wél bereid zijn te zoeken naar een oplossing voor een gebruikersprobleem.
Soms wordt een molen “dubbel” getagd:

  • [historic=monument]
  • [man_made=windmill]
    De rendering leidde hier (in het verleden, mei 2013) niet tot twee icoontjes, maar slechts één icoon was zichtbaar: [historic=monument].
    Dat is vervolgens op OFM gewijzigd: het renderen van windmill gaat vóór historic. Dus geen kakofonie van icoontjes. Slechts één icoon wordt getoond (windmill), maar je kunt wel op beide zoeken.
    OFM: “oplossen door de regel met man_made=windmill (en ook lighthouse zie ik) vóór de history regels te plaatsen (evt met continue, zodat beide tags worden gerenderd)”.
    Zie ook het voorbeeld hierboven van City Navigator: hotel is blijkbaar primair, maar restaurant is - onderliggend - wel aanwezig.
    Dat lukt in dit geval wellicht ook op één node (of: pand), immers het zijn verschillende tags:
  • [tourism=hotel]
  • [amenity=restaurant] (maar café is óók amenity en meervoudige key values ([amenity=restaurant;cafe]) worden niet alom gewaardeerd, o.a. niet door Osmose)

Nog een overweging:
In Jersey, Guernsey heeft een hotel + restaurant soms nog een extra property: “residents only”. Ben benieuwd of dat wordt gehonoreerd op OSM en zo ja: hoe?