Uit een eerder discussie op dit forum heb ik begrepen dat vakantieparken worden getagd als tourism=chalet. Vaak is dat op een way die de omtrek van het park beschrijft en soms op een enkele node als de parkomtrek niet op de kaart staat als zodanig.
Het kan ook voorkomen dat parken aan weerszijden van een weg liggen en in dat geval zie ik ook dat een relation gebruikt kan worden die de omtrekken van de parkdelen bevat als outers. Zie bijvoorbeeld:
Heb deze query gebruikt om de parken te vinden
{{geocodeArea:Netherlands}}->.a;
(
relation["tourism"="chalet"](area.a);
);
out geom;
Zelf viel mij een park op (niet uit bovenstaande query) dat ook gesplitst is maar waar beide ways de tags voor het vakantiepark dragen:
Het lijkt me dus goed om deze ways aan een nieuwe relatie (multipolygon) toe te voegen en daarop de tags over te nemen. Vervolgens deze tags dan verwijderen van de ways. Dan is de situatie hetzelfde als het ‘voorbeeldpark’.
Nu staan sommige parkgegevens ook nog op de BAG-adresnode:
Dat lijkt inderdaad het adres van het park te zijn. Is het nog nodig daar informatie over het park te hebben of kan die weg van de adresnode?
Nu is dat waarschijnlijk ook het adres van het hoofdgebouw / receptie. Dus vraag me af of we hier nog iets mee zouden moeten doen. Is het wenselijk of juist niet als de adrestags ook op de relatie komen te staan? (om alle info over het park op 1 plek te hebben). Of zou de adresnode aan de relatie toegevoegd kunnen worden?
Het is ook nog mogelijk de adresnode als receptie te taggen met tourism=information en information=office. Voorbeeld:
Ik kwam toevallig hetzelfde elders tegen, en kreeg van JOSM een melding dat er een tourism=chalet binnen een tourism=chalet lag: de receptie binnen de way die de (buiten-)grenzen van het park aangeeft.
Om eerlijk te zijn vindt ik de receptie als punt wel een waardevol punt voor navigatie, dus ik heb het zo laten bestaan. Maar mogelijk is er een betere manier om één of beide te taggen?
Receptie / hoofdgebouw nog een keer als tourism=chalet taggen vind ik ergens overbodig als het park ook al op een andere manier in OSM staat (way of relation omtrek(ken)).
Losse voorzieningen binnen het park zoals een zwembad, winkel en snackbar op de kaart zetten lijkt gebruikelijk (denk ook wel wenselijk). Een receptie hoort eigenlijk ook wel in dat lijstje. De receptie als name=Receptie en tourism=information etc. heeft dan weer als nadeel dat je deze niet zult vinden als doel voor navigatie wanneer je zoekt op de parknaam. Mogelijk name=Receptie {{parknaam}}?
Wat je eigenlijk zou moeten hebben, is een oplossing zoals bij scholen, schoolgegevens op de adressnode en het speelplein en andere grond van de school landuse=education
Bij bungalowparken en campings kun je dan op een adressnode alle gegevens taggen (vaak is dat de receptie) en de omtrek geef je dan een landuse, alleen welke?
Wil het zelf ook niet meteen gaan omgooien maar waar ik vooral mee zit is het dupliceren van de informatie. Misschien dan goed om de adresnode dan op de name=* en tourism=chalet na zo minimaal mogelijk te houden qua tags en alle uitgebreide tagging op de way/relation (way of relation is puur bepaald door of het park uit gescheiden gebieden bestaat). Indien het park alleen met een losse node is aangegeven dan (indien bekend) sowieso die tags naar de receptie / BAG-adresnode verplaatsen.
Wat goede tags zouden zijn voor de receptie hangt denk ik ook van het park af. Kleine parken hebben soms niet eens een echte receptie (misschien een huisje waar soms een beheerder is) terwijl in sommige grote parken de receptie als een soort VVV fungeert. Daar kun je bijvoorbeeld kaarten kopen en dan is het ook interessant als POI wanneer je geen parkgast bent. In dat geval is het ook echt een toerisme-informatiecentrum.
Landal Coldenhove vind ik daar wel een goed voorbeeld van. Daar is nu dus wel de parkinformatie (gedeeltelijk) gedupliceerd op de adresnode en de omtrek (waar tourism=chalet niet lijkt te renderen trouwens). En de adresinformatie is dan ook weer op de omtrek aanwezig.
@dvdhoven Ja zoiets zou ook goed kunnen werken, alleen wordt dat nu volgens mij nergens toegepast. tourism=chalet op de omtrek(ken) lijkt wel de meeste voorkomende manier van vakantieparken taggen (in Nederland). En je mag het eigenlijk niet zeggen maar het rendert opzich ook wel mooi op Carto nu met dat vakantiehuisicoontje en de naam van het park …
Waar ik het heb gezien is het juist precies omgekeerd.En het adres hoort sowieso op de (BAG-)node aan zoals je zelf al aangeeft - dus het voelt wel logischer voor mij om de rest daar dan ook bij te zetten.
Het adres ook op de way zetten levert een duplicate address op. Als je de overige informatie wel op de way zet, vind je die weer niet bij het adres (wat voor iemand die niet weet hoe dat komt weer tot twee verwarrende POI’s/zoekresultaten leidt: “Welke is de juiste? De ene heeft het adres maar de andere alle informatie zoals de website.”).
Omdat de geschikte landuse er nog niet voor bestaat.
Alhoewel, eigenlijk is het een (vorm van) leisure=resort?
Die suggestie is afkomstig uit deze discussie van de mailinglist uit 2020, die sowieso interessant is om door te lezen. Er lijkt twijfel te bestaan of het überhaupt de bedoeling was om hele resorts parken op deze manier te taggen en/of of het niet een historische “edit fout” in de wiki-pagina van tourism=chalet betreft.
Die rendering zie ik niet, als ik bijvoorbeeld jouw voorbeeld bekijk?
Het probleem met de way-versie vind ik sowieso dat de rendering en locatie waarop het icoon gezet wordt onberekenbaar. Alleen al op basis van wat ik zie als ik Carto, OSM And en OrganicMaps bekijk - en in alle drie de gevallen kon ik de way alleen vinden via de zoekfunctie, niet omdat het op een duidelijke, vindbare/logische manier op de kaart wordt weergegeven (wat toch best prettig is als je een kaart gebruikt om accommodatie te vinden ).
Grrr … ik had een reactie in voorbereiding maar op de een of andere manier heb ik die weggegooid, toch per ongeluk op discard gedrukt
Maar goed jij bedankt voor de uitgebreide reactie! Door het onderzoek ben ik alleen maar meer gaan twijfelen over de juiste aanpak m.b.t. vakantieparken. De adresnode als primaire plek voor informatie over het park is misschien toch niet zo gek nee. Twee keer tourism=chalet met de parknaam is voor zoeken gewoon ongelukkig. Welke van de twee elementen (adresnode vs way/relation) ook primair is. Een lege way achterlaten lijkt me ook niet netjes omdat het dan niet meer duidelijk is dat dit de parkgrens is. Ga sowieso even de discussie over resort lezen
Overigens was Landal Coldenhove meer een voorbeeld van een plek waar nu informatie gedupliceerd is. Daar rendert tourism=chalet inderdaad niet op de parkomtrek, waarom zou dat zijn? Zie het wel vaker niet renderen overigens.
Nog een interessante voorbeeld (zowel van niet renderen als van elementen in het park) is Huttenheugte:
Inderdaad niet twee maal tourism=chalet/leisure=resort beide horen wat mij betreft op de omtrek thuis. Wat dat betreft is je voorbeeld van de Huttenheugte goed gemapt.
Het is goed om op de omtrek een entrance=main te mappen zodat duidelijk is waar een router op aan zou moeten sturen.
Maar waar zou het adres moeten komen? Nu staat het adres op de parkeerplaats. Misschien niet verkeerd maar op deze adresnode staat nu niets: Node: 714123564 | OpenStreetMap
Volgens mij bedoelt @erik1984 niet het letterlijke adres, maar de vakantiepark-gegevens. Die zijn toegevoegd aan deze parkeerplaats (terwijl ze op de adres-node ontbreken) en zouden m.i. inderdaad het best verplaatst kunnen worden naar de betreffende adres-node.
Evt. kan de parkeerplaats wel een duidelijke naam krijgen, zodat mensen weten dat ze daar bij aankomst kunnen parkeren, maar ik vermoed dat bebording ter plaatse dat ook vroeger of later duidelijk maakt als ze richting receptie/gebouw navigeren.
Ja wat @roelant zegt, de adresgegevens kun je ook zien als onderdeel van de parkgegevens. Reindersdijk 55 is volgens de website het officiële adres van het park.
Nogmaals blijf ik een beetje zitten met het dupliceren van tags. Als de parkgegevens op de omtrek komen dan hoort het adres daar eigenlijk ook bij toch? Maar dan dupliceren we het. In dit geval is het ook niet 100% duidelijk dat het gebouw waar huisnummer 55 op staat de receptie is (en als het ware het toegangspunt voor bezoekers), die lijkt zich in het grote gebouw links van 55 te bevinden volgens de node met amenity=reception_desk. Dus om op de adresnode dan tourism=chalet te plaatsen lijkt me hier nog meer verwarring zaaien.
Zelf ga ik hier ook even niets aan veranderen. Ben een beetje op zoek naar consensus. Taggen op de parkomtrekken lijken wel een beetje de impliciete consensus te zijn in NL omdat het het meest voorkomt, vooral bij grotere parken. Misschien is dit toch iets te complex en moet ik er even vakantie van nemen
Een node op de omtrek als entrance=main taggen (op een kruispunt met de toegangsweg dan neem ik aan?) klinkt ook niet verkeerd als extra hulp voor routering maar is dit al ergens toegepast?
name/adress op dit parkeerplaats is naar mijn idee gewoon fout, name zou operator moeten worden.
Ik zag op de kaart een een hek en zo vond ik dat de omtrek was al gemapt door @Geim.
Op de website van het vakantiepark is een plattegrond te vinden met (9) Receptie / Info Desk, het is niet het eerder gelinkte gebouw.
Ja, ik dit geval zou ik adresgegevens op de omtrek zetten, de website staat daar al en de Wiki vermeld het ook. Mochten er huisjes in het park zijn met een adres dan zouden die ook gemapt kunnen worden met tourism=chalet op de adres node.
Nou, dat mappen door mij viel nogal mee hoor, hooguit wat aanpassingen
Maar Center Parcs De Huttenheugte is meer dan alleen maar het park. Het is ook dagrecreatie. Daar verwijst nu het adres naar, lijkt me niet verstandig om dat te verwijderen.
edit:
De node staat op een pand, waar geen bezoeker komt. Maar dan nog is verwijderen geen optie, bij een bag import staat hij er zo weer op.
Mogelijk. Wat ik bedoel is dat Aquamundo veel dagtoeristen trekt die niet in een chalet zitten. Voor beide gebruikt Center Parcs hetzelfde adres.
Maar al met al maakt het m.i. weinig uit waar de adresnode op staat. Op het pand sowieso, anders komt hij er bij een import er wel weer op te staan, op de outline van het park is ook prima, hoewel ik er niet van houd om een adres node dubbel te gebruiken.
Persoonlijk zie ik liever de tagging zoals die ook bij scholen in gebruik is.
).
