(mogelijk zien julie nog een niet gecorrigeerde (geupdate) versie van de locatie, waar ik geëxperimenteerd had met het toewijzen van de twee amenities aan twee areas binnen een grotere area die het adres bevat. Dat is nu weer ongedaan gemaakt, gaf fouten (credits: eggie).)
Advies voor het mappen van een dergelijke situatie?
Jans suggestie zou ik volgen in het geval er ook twee ingangen zijn. Voor de hoofdactiviteit houd je het adrespunt aan waar de gegevens over bouwjaar e.d. in vermeld zijn. Zoiets?
Een iets uitgebreidere versie is bv. een supermarkt bij mij in de buurt.
De supermarkt is 7 dagen per week open. Er was een inpandige bakkerij (maar deze was niet open op zondag),
een cafe/cafetaria (andere openingstijden), PostNL servicepunt.
Ze zitten allemaal in hetzelfde gebouw, maar zijn aparte bedrijven.
Een andere voorbeeld is het Trefcenter in Venlo. Er ligt 1 gebouw met een tiental bedrijven (AH, big bazar, kruidvat, etc.), die allemaal hetzelfde adres hebben.
Gewoon de adresnode kopiëren en daar mee werken. Zorg er dan wel even voor dat de BAG-tags maar op één adresnode blijven staan. (Met BAG-tags bedoel ik source=BAG en source:date=*)
Voor mij zijn de bakkerij en de cafetaria en het postservicepunt aparte amenities, te mappen met elks een eigen node. Ook al hebben ze eenzelfde straatadres, dat is in deze context bijkomstig.
Samenvattend, in dit geval kan ik het beste twee nodes (points) gebruiken, een met en een zonder adres, elk met een eigen amenity? Heb ik dat goed begrepen?
Beide amenities hebben dezelfde ingang. Ivm corona is echter alleen de bakkerij open.
Elk een eigen amenity, met elk een adres indien van toepassing (eigenlijk bijna altijd). Het kan dus voorkomen dat adressen vaker voorkomen. Zeker als het bedrijf op de eigen website dat adres hanteert hoort het bij hun contactgegevens.
Als je een bestaande adresnode kopieert, dan kun je op de kopie de tags source=BAG en source:date=* weglaten. Die tags worden door de BAG importer aangemaakt om aan te geven dat het een (semi-geautomatiseerde) import betreft.
Apart geval inderdaad, die heeft maar een adres.
Wat ik ook vaak zie is winkels in een verzamelpand die elk een eigen adres hebben met hetzelfde nummer, maar met een volgletter. Op hun eigen website laten sommige dan deze huisnummertoevoeging weg. Dan is het even puzzelen om te vinden welk adres bij welke winkel hoort.
Staar u maar niet al te blind op “hoe het hoort”, osm heeft een lange traditie van breeddenkendheid en zo hoort het ook voor mij. Er kan heel wat, en als je al eens iets manifest fout doet dan hoor je het wel
Mijn raad zou zijn om te bekijken wat er al is, en om daarop verder te bouwen.
Idealiter is het gebouw reeds gemapt als “way”, met adres en alles erop en eraan. Dan volstaat het om elke handelsactiviteit apart toe te voegen als “node”, met naam en toenaam en openingsuren en tijdelijke covid-info en wat nog al niet.
Zo is het bv. gedaan in de bijzonder complexe omgeving van het trein+metrostation “Schuman” in Brussel, daar zitten ook allemaal winkeltjes in en die zijn (ten dele) individueel gemapt als node (maar zonder adresaanduiding).
Duidelijk. Meerdere malen zelfde adres is OK, zolang er maar één keer gebruik wordt gemaakt van de source tag (met waarde BAG) en source:date tag.
Wat is de OSM community toch prettig.
Hoe zit het met een routeplanner gebaseerd op de OSM database, wordt deze niet gelimiteerd als er geen adresaanduiding op zit? Of kan deze uit de “way” (u bedoelt “line” denk ik?) die de node omvat gehaald worden?
Dat is een zinnige vraag, maar het is niet echt onze bezorgdheid. Wij van OSM zijn bezig met het opmaken en onderhouden van een database van geografische informatie. Wat anderen met die informatie doen dat is niet onze zaak, al vind ik wel dat we horen te zorgen en ook echt bezorgd te zijn om de kwaliteit van de informatie die we aanbieden. Dat komt er heel erg op aan dat we konsekwent moeten zijn met de tagging.
Dat gezegd zijnde stel ik me voor dat routingsoftware vroeg of laat toch zal uitmaken “van coordinaten A/B naar coordinaten Y/Z”| en dat dan gaat invullen naar beste vermogen, in functie van de verdere parameters (fiets? helicopter? enkel tolvrije wegen? te paard? … ) Hoe we de ene winkel of de andere faciliteit taggen zou daarbij niet mogen uitmaken, lijkt me.
PS enne, nee, ik bedoel niet “line”, zo’n database entry is me niet bekend, ik weet enkel van nodes en ways en relations (al hoor ik wel geruchten dat we ook “area” gaan krijgen als een vierde soort entry). Ik bedoel wel degelijk “way” als de aangewezen manier om een gebouw te mappen. Zie https://www.openstreetmap.org/way/560159751 voor het eerste het beste voorbeeld dat voorbijkwam.
