Ik ben blij met deze discussie, we denken mee, net zoals bij verkeerborden topic aan de hand van voorbeeld, wordt er diepgravender gewerkt en komen zaken naar voren. Wat lijdt tot nieuwe taginzicht.
En komen we tot conclusies, juist deze conclusie in begintopic samenvatten. ?
Een voorbeeld helemaal uitwerken, en dit als het voorbeeld te gaan gebruiken. Met de conclusies, waarom zo
Conclusie:
Openingtijden en functies
Bij meerdere functies, deze op een apart element zetten om verschillende openingstijden tagging mogelijk te maken. Gevolg meerdere nodes tagging gewenst.
Ook hier de zoektocht, “conclusie, mening, gedachte, vraag” alles in een zin, zwaartepunt verschilt per zin.
Herhalen, nee, staat goed, want het is de hoofdfunctie “Restaurant”, want een restaurant heeft meer betalende bezoekers dan het hotel. En zal daarom vaker op adres gezocht worden binnen navigatie programma’s. Ik bezoek vaker een restaurant dan dat ik een hotel bezoek. Krijg dan ook bij mijn afspraak, adres en naam. Dit wil ik invullen in mijn navigatie, dat bepaalt de kwaliteit van de navigatie.
Dat in de naamgeving vaak van vroeger uit HOTEL-restaurant staat maakt niks uit, marketing truck, om je te onderscheiden van de rest.
Zegt niks over de hoofdfunctie.
website contact
Ik heb het idee dat het de zoektocht is om meerdere website url in te vullen.
Je wilt namelijk de zoekende direct doorverwijzen naar de juiste pagina, dit is bij sommige website best wel eens een probleem.
contact:website is dan mijn inziens ook echt naar de contact pagina waar all informatie over vestiging en invulkader aanwezig is.
website is de informatieve deel van de website, de plaatjes hoe mooi het daar is. de belevingspagina.
Dit blijft een dillemma, dubbele waardes binnen een gebouw lijkt mij niet te voldoen aan one feature one element. Wat één van de grondwaardes van OSM is.
Ook het taggen voor de renderer is niet de bedoeling en een van de grondwaardes.
Ik moet zeggen dat ik het wel eens ben met deze grondwaardes, hoe vervolgens een gps kaart gemaakt wordt is aan de renderer.
Het “probleem” dat je de naam niet zou kunnen vinden, lijkt mij een probleem die de renderer zou moeten/kunnen oplossen.
Volgens mij moet er een truukje zijn om binnen de contouren van een gebouw meerdere nodes te koppelen aan het adres van dit gebouw.
Hierover zou ik graag een renderer aan het woord willen zien die kaarten voor gps aparatuur maakt, of het überhaupt mogelijk is om “de perfecte” gps kaart te maken.
Op de internetkaarten lijkt me het wel (visueel) duidelijk, het probleem doet zich alleen voor op gps gerelateerde kaarten.
Het is geen verwijt aan Eggie, wat ik probeer te zeggen is dat je natuurlijk verbeteringen mag aanbrengen, evt in overleg met de vorige aanbrenger. Dat er niets verwijdert mag worden dat door een ander is aangebracht ben ik het niet mee eens, we streven ernaar dat iedereen de neus dezelfde kant op heeft staan. Vandaar dat we bijna alles vastleggen in de wiki.
En ja er zijn natuurlijk altijd belangen die tegenstrijdig zijn met deze wiki. Neem alleen het (goede) voorbeeld van AnkEric dat je de naam (op dit moment) niet kunt vinden van een restaurant als je in je GPS aan het zoeken bent naar restaurants.
En ja de ref:bag=* is een tag die met de BAG import op het pand is geïmporteerd.
Conclusies in begintopic op een forum is onvoldoende en betekent - alweer - redundant informatie.
Maar het is wél een stap in de goede richting. Nu zie je dat sommige forum discussies eindigen met een volstrekt onzinnige laatste post, die dermate onzinnig is dat niemand er nog op wil reageren.
De wiki lijkt me de enige echt juiste plaats!
En nog belangrijker: een papieren conclusie levert niets op, tenzij deze wordt vertaald in tagging. Zoek alle nodes met hotel én restaurant (Overpass) en corrigeer. Helaas is het corrigeren van een ontbrekend restaurant veel lastiger. Van de meeste bezochte hotels weet ik niet eens of dat ook een restaurant is. Het expliciete “open for non-residents” kom ik, buiten de Kanaaleilanden, zelden tegen.
Maar helaas: een van mijn (vele) redenen om niet meer actief te mappen is dat OSM foutjes gewoon laat bestaan. [highway=footway] + [foot=yes]. Vroeger verwijderde ik dat nog wel eens. Binnen een paar maanden staat er weer: [foot=yes]. En om mij te pesten is er dan ook nog [motor_vehicle=yes] toegevoegd aan de naastgelegen [highway=unclassified].
Conclusie: een goede conclusie impliceert een implementatie plan. Wiki docu is daar een onderdeel van.
De conclusie "want het is de hoofdfunctie ‘Restaurant’ " is nog niet getrokken. Tot nu toe zetten Commodoortje en ik [hotel] op de BAG adresnode, omdat (?) we hotel als hoofdfunctie zien. Maar dat zien we weer omdat (…?) de huidige renderers [hotel] een laag hoger renderen dan [restaurant]? En ik sluit graag, ook bij veranderingen, “een beetje” aan bij de al bestaande praktijk.
Vraag: “Ik bezoek vaker een restaurant dan dat ik een hotel bezoek”.
Is dat relevant? Dan is “shop” niet de hoofdfunctie van een shop, maar: “pedestrian”, of “viewpoint”, of …
Vraag: Zit het restaurant in het hotel, of zit het hotel in het restaurant? Ik denk: restaurant zit in het hotel.
Stelling: je ziet vaker dat “Restaurant” ontbreekt in de naam: “Hotel Post”. Je ziet nooit “Restaurant Post” en dan blijkt dat het óók een hotel is.
Vraag: “En zal daarom vaker op adres gezocht worden binnen navigatie programma’s?”
Ik heb in mijn hele GPS leven (15 jaar) hooguit een paar keer op adres gezocht. Inwoner wist wél het adres van het restaurant én het restaurant ontbrak als POI op de GPS (of: het zat verstopt onder hotel… :/).
Als je het adres persé wilt hebben, toon gevonden POI op de kaart en kijk op de kaart wat het adres is.
Ik vind het éénmaal vermelden van deze informatie méér dan voldoende.
Bovendien kun je verwachten dat luie mappers (goede mappers zijn luie mappers) de adres informatie “vergeten” toe te voegen.
Ga je die adresinformatie dan óók op alle andere POI-nodes (café, fietsverhuur) zetten?
Helemaal mee eens, ik heb dit nieuwe inzicht om deze reden ook niet gebruikt in Bilthoven.
Maar… Key:contact:website
2014 - Although many applications support both, the old tags (phone=, fax=, url=* and website=*) remain more popular after four years (including in main editors presets).
type=site (“Relation to group elements of a site such as a school together”. Helaas: (toegestane) elements zijn uitsluitend ways, geen area, geen nodes. Types_of_relation)
name=van der Valk Hotel Dordrecht
members: building area, BAG adresnode, Hotel node, Restaurant node, … enz.
JOSM accepteert dit.
Dus: [name] alleen op de relation, [Addr:…] alleen op de BAG adres node.
Hè, BAG adresnode en [tourism=hotel] zijn weer losgeweekt?
Waarom zet jij eigenlijk [tourism=hotel] op de BAG adresnode? En waarom ben (was?) ik het daarmee eens? Waarna Alroads de hoofdfunctie ter discussie stelt.
Zo jammer: ik zou nu dolgraag [Save]…! JOSM is al akkoord en dan kunnen we morgen zien wat Osmose hier van vindt.
Zo langzamerhand begin ik wel te hopen dat deze discussie meer nut heeft dan alleen hotel-restaurant. Want er zijn nu meer woorden gebruikt dan er hotel-restaurants in Nederland bestaan.
Tuurlijk weet ik dat het zo nog niet goed is. 'k heb ook gezegd “voorlopig”.
Het enige wat ik heb gedaan is van het gebouw een hotel gemaakt. Nu wil ik even wachten wat het op de OFM doet de komende update. https://www.openstreetmap.org/#map=19/51.77404/4.65202
BAGeraar en Katana doen de BAG import in mijn buurt en de gebouwen. Daar blijf ik even vanaf. Zelf kijk ik vanuit mijn huis trouwens op de snavel van de toekan en heb vanuit de bouwput het hotel gemapt. Daarna toch kennelijk geïmporteerd vanuit de BAG.
Ben nu meer bezig schade te herstellen in de Hoekse Waard. Daar worden nogal wat relaties van fietspaden en bus-routes verbroken. Dat is denk ik ook de frustratie van Eric. Het was goed en nu nu weer steeds spaghetti. Een busstation bij Blaakse Dijk dat een vliegveld is geworden, want overal taxibanen. Die liepen tot Oud-Beierland door. ;k Zie dat hopelijk de mapper zelf de boel al heeft teruggedraaid. Het busstation heb ik maar zelf gedaan.
Dan probeer je toch maar weer de moed erin te houden. Kan wel tegen een beetje tegenslag…
edit: In Ierland vorig jaar een Pubtocht gemaakt. Niet vanwege de Pubs, maar dat zijn daar de Lodges. Toen zat ik er ook al mee. https://www.openstreetmap.org/#map=19/53.11596/-9.14776
'k Zie nu dat de hele Pub verdwenen is. Restaurant en Lodge. Het is dus een Pub en bijna elke pub in Ierland heeft ook de functie van lodge. Bovendien kun je er altijd eten.
Het blijft een dilemma. En… wat doe je met een eetcafe? Geen geintje… ik weet echt niet hoe dat te taggen.
Ik begrijp dat je nu reageert op: “Zo langzamerhand begin ik wel te hopen dat deze discussie meer nut heeft dan alleen hotel-restaurant. Want er zijn nu meer woorden gebruikt dan er hotel-restaurants in Nederland bestaan.”
Knap, want jouw reactie stond er eerder dan mijn post
[moderated]niet ter zake doende opmerkingen[/moderated]
En dan staat er dus een Cafe POI op de kaart (kopjekoffie-symbool). En dan mag ik begrijpen dat je daar óók kunt eten.
De eerste die ik vind is trouwens: [cuisine=coffee_shop].
Een hotel-restaurant tag je - uiteraard - met [tourism=hotel] en [amenity=restaurant]! En uiteraard op één node, of één area (building).
Einde discussie wat mij betreft. Ik ben er weer klaar mee.
Eric … hoe krijg je consensus?.. dat is even de vraag. Hoe doet een garminkaart dat dan? Daar moet het toch ook ergens dubbel instaan. Of heb je daar een categorie Restaurant/hotel. Dan moeten we dat als OSM community toch ook voor elkaar krijgen. 't lijkt me geen zinloze discussie zo.
… ja … en zie discussie Ierland. Daar is een pub dus ook iets anders als in Nederland. Een coffee_shop is daar voor koffie. … en in Nederland is een Lunchroom ook een niet bestaand Engels woord. 's Lands wijs 's lands eer.
Het is nu roeien met de riemen die we hebben, maar het klopt natuurlijk niet. Fout taggen lijkt nu “beter” dan volgens de regels taggen. Als daar enige verbetering in kan komen altijd meegenomen.
Natuurlijk, dat ik daar nou niet aan gedacht heb in de hele discussie!
[tourism=hotel] + [amenity=restaurant] is gewoon mogelijk.
zetten we de amenity=cafe er als losse node naast. (zonder naam en zonder adres)
Het gaat in de discussie over zaken die niet dubbel zijn te taggen (2x amenity=*)
Ik heb inmiddels andere kaarten dan OSM mijn GPS weggezet [verstopt in map].
Wanneer ik nu zoek op restaurant en dan bij naam Valk of Mc invul: dan komt daar netjes [zonder herhalingen van andere kaarten als b.v. CN] alle Valk-kersjes in de regio tevoorschijn.
Dat dan mogelijk het icoon niet klopt is voor mij geen probleem: Alle treffer die ik nodig heb, vind ik.
In het verleden met een groep fietsers in buitenland een lunchlokatie buiten het zicht van de GPX-route opgekregen: Je zoekt onder restaurant op naam van restaurant en ik kon meteen het roer overnemen om de groep aan tafel te leiden.
Dus zowel bij Valk als lunchstop zoek ik niet met adresinfo, maar in feite op POI.
Om deze reden lijkt een naam op het POI als ‘Van der Valk Vianen’ mij dan ook beter dan ‘Hotel Vianen’.
Vergelijkbare probleem:
Een parcours dat zowel voor wielrennen als skeeler wordt gebruikt: Wanneer ik in P2 leisure=track en dan sport=cycling; skeeler invul; dan wordt meer dan 1 waarde op deze tag - uiteraard - niet geaccepteerd. Daarmee doe ik 1 van de 2 sporten te kort.
Wat is wijs?
Ik begrijp van ligfietser dat hij de reactie van ankeric gemodereerd heeft omdat hierin zonder toestemming de inhoud van een prive mail gekopieerd was. Dat valt in nederland (waar dit forum gehost wordt) onder de copyright wetgeving en mag dus niet. Gelieve dus geen prive mails kopieren, je mag wel in eigen bewoording de strekking er van vermelden: http://forum.openstreetmap.org/viewtopic.php?id=20545
Eric, ik zeg dit met de best mogelijke bedoelingen: een verhitte discussie voeren leidt tot ieders frustratie. Ik snap dat het moeilijk is maar probeer rustig te blijven en je standpunten op een andere manier te verwoorden als je het idee hebt dat je niet begrepen wordt (soms lijken mensen het met je oneens te zijn terwijl ze simpelweg je punt niet begrepen), van boze reacties wordt niemand wijzer. We zijn hier allemaal vrijwilligers en geen alwetende professionals die je kunt dwingen een bepaalde dienst te leveren.
Je frustratie lijkt vooral uit de garmin kaarten voort te komen, ,misschien dat ligfietser kan uitleggen of restaurants en hotels op dezelfde nodes goed door de garmin stylesheets verwerkt kunnen worden?
Lambertus, even voor de goede orde, het stuk dat ik had gemodereerd betrof niet de inhoud van een privemail maar een persoonlijke aanval van hem op mij dat ik dit topic niet goed zou hebben gelezen/begrepen. De prive mail sloeg op de inhoud van het “spam report” die Eric op het forum had achtergelaten voor de moderators waarin hij letterlijk een mailtje van mij citeert.
Dit was de reden om toch losse nodes te taggen, voor mij is het één en ander wel duidelijk geworden, dank voor de input van allen.
Natuurlijk begrijp ik dat het voor een renderer zeer lastig is om naar de wensen van de gebruiker een map op een gps te maken, en allereerst wil ik de mapmakers de complimenten geven hoe de kaarten op dit moment zijn. Hoe ze in de toekomst zullen worden is mij niet bekend, en vermoedelijk lambertus en ligfietser ook (nog) niet.
Maar volgens mij kan de input van dit soort discussies vormgeven aan een nog betere (gps) kaart dan dat het nu al is.
De één is (helaas) sneller op de tenen getrapt dan de ander, vaak komt dit door onbegrip. Toch ben ik het zeer eens met Lambertus om niet in het persoonlijke te gaan maar op het punt te spelen. We zijn er met zijn allen bij gebaat dat er veel gemotiveerde OSM mappers aanwezig zijn (en blijven). Ik (probeer) vaak tussen de regels door te lezen om de grote lijnen vast te houden, en soms is het dan lastig om het te verwoorden. Wat door de ander dan opgepakt kan worden als een persoonlijke pijl.
Dat zou kunnen maar daar heb je meerdere pois nodig om één node te renderen
een poi voor een icoon met hotel/restaurant
een onzichtbare poi om het hotel te vinden
een onzichtbare poi om het restaurant te vinden
Aangezien Garmin maar een beperkt aantal pois beschikbaar heeft die we kunnen gebruiken, is dit een lastige kwestie.
Workaround is om eerst de poi van het hotel te renderen en daarbovenop de poi met het restaurant maar dan heb je weer die kakofonie.
De OFM rendert alleen het hotel en niet het restaurant als ze beide op een node zitten (dwz tourism vóór amenity)
Mkgmap default style doet precies het omgekeerde, eerst amenity, dan tourism. Dwz die rendert géén hotel als er ook een amenity=restaurant aanhangt.
