Mijn mening als (ex-)mapper is niet dezelfde als mijn mening als “gebruiker”.
Zelfs in de jaren dat ik 300 uur per jaar besteedde aan mappen, was ik in de eerste plaats gebruiker: 400 uur op de fiets en 100 uur BaseCamp (voorbereiding en resultaat verwerking).
In deze discussie ben ik gebruiker: “gebruikersperspectief”. Of zo je wilt: “klant”.
De feitelijke vaststelling “Als gebruiker interesseert het me niets hoe OSM vindt dat dit getagd moet worden”, is vrijwel gelijk aan de feitelijke vaststelling dat slecht weinig autorijders willen weten hoe een auto wordt geproduceerd. Verwacht wordt dat deze betrouwbaar, veilig en mooi is. Of zo iets.
Als gebruiker verwacht ik van een OSM kaart dat deze minimaal 80% van de voor mij relevante POI’s bevat. Juist én volledig.
De vraag is:
Nee! Want de [name] tag is bedoeld voor de “name” en niet voor [designation], gebruik, functie: [highway=cycleway] + [name=fietspad] is vergelijkbaar en gewoon fout.
Ook bevat [name] lang niet altijd “Hotel Restaurant”. Laat staan “Hotel Restaurant Café”. Vaak bevat [name] alleen “Hotel” (en toch óók restaurant), soms ontbreekt ook “Hotel”.
Dat staat er niet! Er staat dat als iets een hotel is, je dat dan dient te taggen als hotel: “the main tag to use is tourism=hotel”.
Er staat niets over hoe een object moet worden “getagd” dat twee (of meer) hoofdfuncties heeft.
Maar dat is nu juist het probleem. Als je hotel, restaurant, winkel(s), bar, café, wasserette, wifi, zwembad, sauna, fietsenstalling, fietsverhuur ziet als functies van een hotel (wat het ook zijn) dan kun je deze functies allemaal, als afzonderlijke tag, toevoegen aan het object. En dat gebeurt vaak al (dus: correct gemapt).
Maar zodra beide - in deze discussie - relevante tags ([amenity=restaurant], [tourism=hotel]) op een object staan, wordt uitsluitend [hotel] gerenderd op de kaart en doorzoekbaar gemaakt vanuit de index.
Als een renderer dat kan aanpassen zodat beide worden gerenderd én beide doorzoekbaar zijn (bijvoorbeeld: “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)”) dan zou het mooi zijn als de renderer bereid zou zijn om zowel hotel als restaurant te renderen.
Maar daarmee is slechts het probleem voor deze twee tags opgelost. Wat te doen als er meerdere tags gerenderd moeten worden? Afzonderlijke POI-nodes voor (1) hotel én (2) restaurant, (3) café, (4) sauna, (5) fietsverhuur (indien deze openstaan voor non-residents)?
Maar helaas:
Een hotel-restaurant is één object, met één naam, met één eigenaar en met één hoofdfunctie. En één object dien je niet als twee (of meer) verschillende POI-nodes te mappen.
Maar… mappen als afzonderlijke POI-nodes wordt wél gedaan (net als de kapper en de bakker in het winkelcentrum) én werkt wél!
Maar… dat is “taggen voor de renderer”?
En daarmee is het probleem onoplosbaar geworden!
Mijn conclusie:
Ik kan een restaurant niet vinden als dat restaurant - toevallig - óók een hotel is.
Ik kan een hotel niet vinden als dit als uitsluitend restaurant is getagd.
Huidige situatie:
De twee tags ([amenity=restaurant], [tourism=hotel]) staan hetzij op een node, hetzij op een area (building). Op beide heb ik (nog) niet gevonden.
Indien beide tags op één object (node of area) staan wordt door minimaal twee renderers (OSM en OFM) uitsluitend [tourism=hotel] op de kaart getoond en wordt vanuit BaseCamp uitsluitend [tourism=hotel] gevonden.
Indien van een hotel/restaurant vanuit BaseCamp zowel [tourism=hotel] als [amenity=restaurant] wordt gevonden, dan staan deze tags op twee verschillende POI-nodes.
In dat geval zie je op OSM/OFM óók de kakofonie van twee verschillende icoontjes. De “kakofonie van icoontjes” bestaat al.
Oplossing is simpel: maak alle niet relevante icoontjes (scholen, bushaltes, stations en winkels) onzichtbaar (typfile).
Is er iemand voor wie meer dan 3 scholen relevant zijn? Omdat mijn kinderen die bezoeken? Maar dan weet ik ook de locatie!
We zijn volgens de GPS nog nooit langs een school gereden en zeiden toen: Hé, leuk een school! Zullen we even kijken of we daar een kopje koffie kunnen scoren?
Evenmin heeft de aanwezigheid van een bushalte ons ooit op het idee gebracht om de bus te pakken. En als we de bus willen gebruiken dan zoek je op bushalte, je vindt de dichtstbijzijnde bushalte, je ziet ook op de kaart waar deze is, voegt deze vervolgens als waypoint toe en je routeert naar dit waypoint.
Winkels? Die zie je in real life als je door een winkelstraat loopt (zichtbaarheid op GPS voegt niets toe) en als je er een nodig hebt: zoek! (“Winkelstraat” op OSM zou ik wel weer op prijs stellen. Nuttiger dan “residential street”)
Wat overblijft zijn de leuke icoontjes die kunnen leiden tot een “impuls actie” gebaseerd op de zichtbaarheid op de GPS. De GPS vertelt mij dat er een uitzichtspunt is achter die bomen. Of een restaurant. Ik kan dat zelf niet zien.
Op City Navigator zie je één POI (restaurant), maar zodra je deze selecteert worden wél twee verschillende tags getoond.
Als een hotel-restaurant niet op beide tags wordt getoond/gevonden dan betreft dit:
- [name=Hotel X] + [amenity=restaurant], maar zonder [tourism=hotel]: onjuist gemapt.
- [amenity=restaurant] zonder [tourism=hotel]: onjuist gemapt.
- [tourism=hotel] zonder [amenity=restaurant]: onjuist gemapt.
- [tourism=hotel] én [amenity=restaurant] beide op hetzelfde object (node of area): juist gemapt, onjuist gerenderd.
- [tourism=hotel] én [amenity=restaurant] op twee verschillende POI-nodes: onjuist gemapt (immers gemapt voor de renderer), maar dientengevolge wél juist gerenderd.
- (en nog wat leuke uitzonderingen: [name=restaurant])
Overdrijf ik als ik nu stel dat er véél te veel hotel-restaurants onjuist zijn gemapt en/of onjuist worden gerenderd?
Overdrijven is weliswaar ook een vak, maar overdrijving is hier nauwelijks mogelijk. Het zijn er veel!
Ik vind dit puur slecht en dit is voor ons voldoende reden om volgende vakantie toch weer - ook - met City Navigator op pad te gaan. Want Garmin doet dit wél goed.
