Kaart aanvullen met POIs: toevoegen aan adresnode of extra node maken?

Ian,

Het komt regelmatig voor dat de POI’s er al waren voordat de BAG adresnodes geïmporteerd werden. Vaak hadden die POI’s ook geen adresinformatie en stonden niet precies op de goede plek. Voor de BAG import mappers was het daardoor vaak heel veel werk om voor alle bestaande POI’s de bijbehorende adresnode te vinden.
Het wisselt per mapper en daardoor per regio, hoeveel moeite er voor gedaan is om dit uit te zoeken. In Amsterdam was het natuurlijk door de vele POI’s ook nog eens een stuk meer werk dan voor die ene bakker in Lutjebroek.
Hier ligt dus nog een leuke uitdaging voor wie ter plekke wil kijken op welk adres die bloemenwinkel zit.

Gertjan

Bedankt voor de toelichting, heren. Ik had een eenduidig antwoord verwacht, maar de waarheid ligt, zoals zo vaak, genuanceerder. :slight_smile: Het verschilt dus per mapper, regio en dus ook zelfs per land.

Mijn grootste zorg was dat er door mij toegevoegde gegevens in de toekomst mogelijk verloren zouden gaan bij geautomatiseerde BAG-updates. Ik heb echter begrepen uit de thread waar Marc naar verwijst dat dit niet snel zal gebeuren en dat men veilig data kan toevoegen aan de adresnodes.

Voor de duidelijkheid, is het ooit wenselijk om de praktijk te handhaven van POI-gegevens op de contouren van het pand zetten? Of is dat alleen maar een historisch overblijfsel?

Ik ben voornemens de adresnode te gebruiken voor panden met een enkele gebruiker, en pas aparte nodes in te zetten wanneer er meerdere bedrijven c.q. instanties in het gebouw zijn gevestigd.

Een laatste vraag. Marc, je zegt dat het zinloos is om de adresgegevens meerdere keren in te voeren bij alle POI-nodes die toebehoren aan een pand. Dat lijkt mij ook. Maar wat zorgt er dan voor dat routeringsprogramma’s aan de hand van bv. een winkelnaam weten in welke stad, straat en pand deze ligt? Zijn ze slim genoeg om de aparte adresnode te gebruiken die binnen dezelfde contouren zit als de POI-node?

Genoeg vragen. De leercurve van OSM is een beetje steil, en je moet er ook voor zorgen dat je de informatie tot je neemt in de juiste volgorde. Anders zijn er te veel verwijzingen naar zaken waar je nog geen kaas van hebt gegeten en komen er alleen maar meer vragen in je op.

Ook de losse nodes met de winkelnaam hebben een coordinaat. Totaal niet nodig dat je er een adres bij hebt. Dat kent een routeringsprogramma toch niet. Is er enkel maar om je als gebruiker te helpen om je bestemming in te voeren en het zal een routeringsprogramma in beginsel worst wezen of je wilt zoeken op adres, winkelnaam of wat anders. Zolang er maar een coordinaat is kom je er wel.

Zelf zet ik nieuwe POI’s altijd op een losse node, is veel gemakkelijker als een winkel verhuist naar een paar panden/straten/dorpen verderop. Verslepen en klaar.

Bedankt voor het heldere antwoord. Dat is fijn om te weten.

Daar zit wel wat in, ja. Dat vind ik een sterk argument voor deze praktijk.

Ik had verwacht dat er strenge regels zouden bestaan voor dit soort zaken om chaos te voorkomen, maar zo langzamerhand wordt het duidelijk dat de mapper bijna noodzakelijkerwijs enige vrijheid geniet om zelf te bepalen hoe hij of zij te werk gaat; als de werkwijze maar goed doordacht is en geen vernielingen aanricht.

Ik weet nu wel voldoende, denk ik. Nogmaals bedankt.

Maar zet je dan al de adresgegevens er ook weer bij Sander?
Want ik plaats alles op de adresnode, omdat dan data-consumers (zoals OpenPoiMap) er ook wat mee kunnen.
Zie hieronder. Links een pand met de winkelgegevens niet op de adresnode (in dit geval op de contour), rechts wel.
Je kunt dan dus ook het adres zien waar die POI is gevestigd:

En hoe vaak moet je nou een winkel verplaatsen? Opheffen komt vaker voor denk ik!

Daarom is het jammer dat in dit geval de chaos gewoon blijft bestaan omdat er teveel verschillende meningen bestaan over hoe we die POI moeten taggen.
Vooral als in een pand meerdere bedrijven zitten, allemaal met een eigen adres, is het veel handiger om die bedrijven aan hun adres te koppelen dan aan het pand waar ze in zitten.

En hier nog een voorbeeld uit dezelfde buurt:
Giftshop “Waar” staat op een multipolygon met 3 adressen:
Schoolstraat 22, en 20B en 20C. Maar wat is nu het adres van die Giftshop?

Daarom dus mijn pleidooi om de chaos terug te dringen: zet een POI op het adres waar hij bijhoort.

Ik dacht ook dat dat van belang was voor de routering, maar Sander heeft al uitgelegd dat dat dus niet zo is.
Zo leer ik ook nog eens wat… :roll_eyes: (Ik heb de welkomst-wiki aangepast)

Je zou het haast wel denken tegenwoordig.
Toen ik de winkels in het dorp ging mappen was al bekend dat ze binnenkort gingen verhuizen, de ene groter, de ander kleiner, dus het was behoorlijk stuivertje wisselen. Ook elders heb ik gemerkt dat winkels wel eens verkassen.

Ook zitten enkele formules (Albert Heijn+Gall&Gall en Intertoys+Marskramer) in 1 pand met 1 deur met 1 op 1 adres met 1 kassa (ok, AH wat meer :slight_smile: ) omdat ze toevallig dezelfde eigenaar/uitbater hebben.
En de ATM, geef je die dan maar als 3e ook het adres of prop je die bij de winkel erbij?

One feature one OSM element: is de winkel de POI en is het adres slechts een eigenschap, of is het adres de POI en is de winkel slechts een eigenschap? Wellicht morgen een andere winkel, maar het adres blijft hetzelfde, dus zou haast zeggen dat de winkel het vergankelijke element is, maar als de gemeente de adressen veranderd omdat er bijvoorbeeld een apparementencomplex tussen gebouwd wordt die nummers nodig heeft blijft de winkel weer hetzelfde en veranderd het adres. Het is maar net waar je naar op zoek bent.
Een datagebruiker moet dan maar wat slimmer worden en adresnodes in hetzelfde pand vinden en die erbij tonen (gemakkelijker gezegd dan gedaan). Bij winkel onder apartementencomplex is het bijvoorbeeld zoeken welk adres nou op de begane grond zit, zeker als er geen level tag op de adresnode staat waardoor er niet eenduidig 1 overblijft. De dichtstbijzijnde adresnode zal het ook niet altijd zijn, maar vast wel vaak.

Een relatie om adres en meerdere eigenschappen samen te binden zou een uitkomst zijn voor data consumers, maar een kleine ramp voor de meeste data invoerders.

En dan zijn we weer terug bij een eerder getrokken conclusie: er is helaas geen eenduidige en perfecte manier om te taggen.

Dat betekent dan dat in mijn voorbeeld uit #8 je te zien krijgt dat die giftshop in de schoolstraat 22, 22B en 22C zit?

In deze eerdere discussie kwamen veel van deze vragen ook al naar boven, en ook daar hebben we geen echte aanbeveling gezien.
Maar toch pleit ik nog steeds voor de methode van POI op adresnode zetten voor de simpele gevallen.

In dit geval zet ik waarschijnlijk het hoofdbedrijf (AH) op de adresnode, en zet de andere als losse POInodes neer. Evt. met toevoeging “in pand van AH”. Het blijft soms schipperen…

Een adres heeft een bepaalde functie in Nederland, je kunt er bv. een brief naartoe sturen of je kunt op dat adres aanbellen. Daarom zet ik een ATM in een winkel ook niet op de adresnode, want je stuurt nooit brieven naar een ATM. Ik zet de node van die ATM binnen de pandcontour en vermeld evt. in een opmerking “Naast de AH kassa’s”.

Hier heb je helemaal gelijk in, toch proberen we de volgorde een beetje te structureren.
Per land, per regio, per mapper. De volgorde net andersom. In de wiki’s worden dan ook richtlijnen gegeven welke een stuk structuur kan bieden in het mappen.

Dan heb je landen die een andere kant opgaan, dan heb je regio’s waar mappers elkaar proberen aan te vullen in het gebied waar zij OSM in kaart brengen, als laatst heb je de individuele mapper waar geacht wordt de hoofdlijnen welke in de wiki’s staan te gebruiken als leidraad. En ja er zijn mappers die hun eigen weg gaan. Soms is dit onwetendheid soms is het starrigheid en sommige mappers voelen het weleens als dwarsliggendheid.
Het gaat erom dat de kaartmakers, welke de data van OSM gebruiken om haar kaarten te produceren mbv taggings richtlijnen kaarten kunnen laten renderen.
En ja een renderer kan een losse node als poi en een losse node als adres zien als iets dat bij elkaar hoort.
Er is in dit draadje al geschreven dat de renderer de dichtstbijliggende adres node samenvoegd in de renderstyle.
Hier zit volgens mij de crux:
Als je de juiste adresnode samenvoegd met de poi node om zo 1 node te vormen, kan de renderer het juiste adres gebruiken in zijn rendering (zoeksysteem)

Ik ben dan ook voorstander om een poi samen te voegen op een adresnode.

Er is bij de grote BAG import afgesproken om extra tags (buiten de destijds 3dShapes import gebruikte tags) mee te nemen naar de BAG tags. Dit om deze extra tags niet verloren te laten gaan. Hiervoor zijn destijds een filters gemaakt om deze extra tags te kunnen ontdekken. Het voordeel is dat de historie blijft bestaan.
Ik weet dat er situaties zijn geweest waar de filters niet goed zijn toegepast, waardoor er panden verloren zijn gegaan met extra tags.
Dit werd in de BAG handleiding als volgt geformuleerd:
[

STAP 2. BAG panden en adressen voorzien van relevante bestaande data

](NL:BAGimport via ODS plugin - OpenStreetMap Wiki)

Er kunnen natuurlijk meerdere adresnodes aanwezig zijn met unieke adresseringsnummers.
Er kunnen (in theorie) meerdere bedrijven op 1 adresnode zijn gevestigd. (Dit heeft Sander H ook eigenlijk al geschreven lees ik)
Ik denk even aan het reeds failliete V&D en (inpandig shop in shop) Dixons
Deze laatste zou iedere mapper op zijn manier vermoedelijk oplossen. Persoonlijk zou ik dan Dixons zonder adresgegevens mappen maar wel op de positie van het pand waar het is gevestigd.

Hier ben ik het helemaal mee eens, dit raakt de kern.
Ja, hoe gedetailleerder je gaat, hoe meer tegengeluiden er kunnen komen. Het gaat om de hoofdlijnen, en dat iedereen dezelfde taal spreekt. Ook in Nederland hebben we dialecten, en als we goed luisteren verstaan we elkaar nog steeds. Er blijven uitzonderingen bestaan op de wereld, en dat is maar goed ook.

Waren ze allemaal maar zo goed als ik zou moeten zijn. :wink:

Af en toe voeg ik winkelinformatie toe en in mijn dorp heb ik alle winkels aangegeven. Of er nou wel of niet consensus bestaat over de beste werkwijze… ik wil graag een aantal opmerkingen plaatsen.

Ik begrijp het belang van routering en dergelijke en probeer daar rekening mee te houden. Maar is OSM niet in de eerste plaats bedoeld om weergave van een landkaart mogelijk te maken? In elk geval lijkt geen enkele service mij hoofdzaak boven kaartweergave.

Sander H heeft in dit topic al gepleit voor losse winkelnodes en geeft aan dat routering prima zonder adres kan.
Marczoutendijk pleit voor samenvoeging ten behoeve van o.a. OpenPoiMap.
Om het adres te zien bij OpenPoiMap moet alsnog de winkel eerst binnen de selectie vallen en vervolgens moet je op het icoontje klikken.

Zelf gebruik ik OSM als kaart. Ik bedenk zelf routes op basis van de informatie die ik zie. Wat betreft winkels wil ik graag de huisnummers kunnen zien. En dat is, op osm.org, niet het geval bij een samengevoegde node. Het gaat dan dus ten koste van de traditionele kaartlezer!
Misschien is het gemakkelijker voor een renderer om dit eventueel te veranderen dan voor andere services om informatie van losse nodes te koppelen…
Maar toch, ik vind dat de huidige opzet en werking van osm.org een hoge prioriteit heeft.

Dus ik plaats winkelnodes extra bij en als het even kan met wat tussenruimte zodat er grote kans is dat huisnummer en winkelicoon beide worden weergegeven op de kaart. Bijvoorbeeld: adresnode bij de ingang, winkelnode verderop in het gebouw.

OSM is in eerste instantie een database, pas daarna komen de kaarten, routers en andere toepassingen. Des te meer de gegevens samenhangen des te groter worden de mogelijkheden.

Ik zag zojuist een fietsenstalling (als node) met een lijn eromheen met de tag covered=yes erop. De router wijst je ernaartoe maar ziet niet dat je fiets onder de overkapping staat. Ook staat het netjes op de kaart aangegeven en een mens zal het correct interpreteren. Toch is dit een voorbeeld van verkeerd taggen.

Landkaart?
Dit is bijvoorbeeld een waterkaart uit de database van OSM

Zo keek ik er aanvankelijk -ook ingegeven door de naam van het project- ook tegenaan.
(daardoor plaatste ik bijvoorbeeld uitzonderlijke informatie over toegankelijkheid van paden in de naam, omdat ik dat als redacteur van op papier gepubliceerde papieren ook zou doen). Daarop werd ik gecorrigeerd en hoewel ik het argument “als het kaartbeeld je niet bevalt, dan maak je maar je eigen kaart” eerst onwennig vond, ben ik het ook zo gaan zien: de enige manier om te zorgen dat verschillende afgeleide producten goed kunnen worden gemaakt (ook dingen die je zelf niet bedenkt) is als je een consistente database hebt, de rest volgt daaruit.

Ook als je naar de formele licentievoorwaarden kijkt, dan zie je dat openstreetmap in eerste instantie een database is (die op hun site "toevallig"ook een paar mogelijke verschijningsvormen van die database publiceert.

Strikt genomen zou “openstreetdatabase” misschien een meer exacte benaming van het project zijn, maar ja, dat klinkt voor de meeste mensen ook weer niet echt aantrekkelijk :slight_smile:

Het verschil is dat een lijn met alleen de tag covered=yes geen betekenis heeft in OSM en een losse adresnode of winkelnode wel.

Volgens mij werken zo’n beetje alle IT-applicaties op één of andere manier met een database. Dat OSM eigenlijk een database is zegt dus op zichzelf niet zoveel. Het punt is dat men niet moet denken dat een bepaalde kaartweergave zoals op openstreetmap.org de enige toepassing is van de informatie in de database. Ik heb nauwelijks ervaring met routers maar die projecteren de aanwijzingen toch ook op een kaart? Het is daarom dat ik over ‘kaart’ spreek.

De vraag is wat beter past in een consistente database. In dit geval gaat het dan alleen over Nederland. De keuze voor losse adresnodes in plaats van adressen op gebouwen komt volgens mij vooral voort uit de BAG-imports.
Winkel- of bedrijfsinformatie toevoegen aan de adresnodes geeft problemen wanneer meerdere ondernemingen hetzelfde adres hebben. Dan sta je voor de keuze om dubbele adresinformatie in te voeren of alsnog adresinformatie en winkel- of bedrijfsinformatie los te koppelen. Dit zorgt dan voor inconsistente ordening van gegevens. Ik geef toe dat dit in een relatief klein deel van de gevallen zo zal zijn.

Een nadeel van losgekoppelde informatie is de kans dat pogingen van applicaties om de info te verbinden verkeerde resultaten oplevert (bijv. doordat standaard het adres van de dichtstbijzijnde adresnode wordt gebruikt). Maar het intekenen voor losse fietspaden langs een weg vergroot allicht ook de kans op verkeerde routering t.o.v. het aangeven op wegen dat er parallel een fietspad loopt.

Mijn wens om winkelicoontje én huisnummer te zien heeft ook te maken met consistentie. Als adressering van winkels en bedrijven zo belangrijk is dan is het toch gek dat juist daarbij de weergave van het huisnummer wegvalt.
Dit kun je wel bij de renderers neerleggen maar bij inleving voor de werking van routers mag dat ook voor renderers. In hoeverre er ruimte is om iets te renderen ligt mijns inziens wel degelijk ook voor een deel bij de mappers. Er kunnen bijv. twee POI’s zijn direct naast elkaar die beide echt wel belangrijk zijn om weer te geven. Dan is er naar mijn mening niets mis mee om ze iets verder uit elkaar te plaatsen dan in werkelijkheid het geval is.
Als standaard zowel winkelicoontje als huisnummer zou worden weergegeven dan heeft de mapper minder mogelijkheden om met micro-positionering de renderer een handje te helpen.

Zoals zo vaak met OSM, er zijn vele meningen en argumenten voor het één of het ander. Het is overigens slechts mijn bedoeling om de mijne te delen en niet om tegen de consensus in te zwemmen.

Dat klopt. Het grootste probleem vormen dan de afslagen/oversteken. En dat zie je ook in OSM en ook FB, die worden vaak vergeten. Je moet wel naar elke zijweg aan de overkant een oversteek tekenen, anders kan de navigator die oversteek niet maken.

Als een gebied hebt waar netjes aan beide kanten van de hoofdweg een fietspad ligt en alles is overal perfect symetrisch aangelegd, dan zou je die fietspaden niet in hoeven tekenen.

De praktijk leert dat het nooit zo perfect is. En dan krijg je een enorm complex tagging scheme wat ook niemand snapt.

Ook nu is het al een probleem dat een fietsstrook geen aparte way is, dus dan krijg je contructies als
bicycle:forward=use_sidepath. Geen probleem voor een ervaren mapper, maar niet echt toegankelijk voor een beginner.

En dan wel waar de oversteek is en niet dwars door een muurtje/greppel/heg/rand heen, dit houd soms in dat je 15 meter rijbaan moet nemen, knippen en route relatie aanpassen, om het correct in het landschap in te tekenen, kwam ik vooral tegen waar een wandelroute uit een track kwam en dan naar het fietspad hoort te gaan. Op de rijbaan deze 15 meter geen use_sidepath tags voor foot en alle andere. Of schuin de routelijn naar de kruisingspunt node vanaf de kant van de weg,

BGT omtrekgericht geeft veelal deze oversteken goed aan.

Oversteek linker track, klein stukje geen use_sidepath tags. Niet het wandelroute voorbeeld.
Situatie:
http://www.openstreetmap.org/#map=18/50.80643/5.92349

Wegen verspringen nu eenmaal.

Dan moet er met cycleway=track gewerkt worden, want voor de routeberekening in tijd voor de auto maakt het wel uit of er fietsers op de weg aanwezig zijn.
En bij de situatie boven: cycleway:right=track en cycleway:right=lane

Willen jullie alles terug draaien/om zetten?

Een gepasseerd station. De keuze is genaakt.

Die keuze is voor mijn aanvang gemaakt, wat ik wel een logische keuze vindt.

Routering en goed vertalen van de wet naar tags, vraagt nu eenmaal kennis.