Navigatie en de juiste weg tot op het perceel. Analyse. Positie adresnode BAG

Ik dacht laat ik hier even de navigatie testen, mede denkend aan de Veiligheidsregio, aanrijroute, eerder kwam ik op de parkeerplaats uit boven adres nummer 97 op een eenrichtingsweg. ( nu even de rode icoon vlakbij gezet, om screenshot omrijroute te maken)

Nadat ik de driveway had ingetekend was het wel correct na een tijdje.


Mooi, maar laat ik de rode icoon nu eens verschuiven, naar 5a, dit is niet goed.

Bij 5, wel, die lat/lon is wel heel erg bepalend. De positie in de BAG is wel heel erg bepalend.

Navigatie kijkt welke weg (OSM highway) ligt het dichtste bij, haaks vanaf het lat/lon punt (adresnode, als daar op wordt gezocht) tot een weg

Ik vroeg me dan ook af, kunnen we deze mogelijke navigatie potentiële fouten op een bepaalde manier opsporen. Inzichtelijk maken.

Daarbij keek ik even naar Geofabrik adressen inspector.
afbeelding

Elk adres zou eigenlijk gescanned moeten worden op dichstbijzijnde navigatie weg (OSM highway) way en ook op een met naam, dat overeenkomt met de adresnode. Zie je daar koppelings lijnverschillen, met een bepaalde afwijking, stel 30 graden, of lengte verschil lijnen, dan is het mogelijk dat zaken nog niet helemaal zijn ingetekend of adresnode verplaatsen.

Het omgekeerde, driveway intekenen. Garage behoort bij bovenste huis.
Dat je hier voor een dichte garagedeur zonder poort staat is niet wenselijk met de auto, foot en bicycle gaat goed, die komen op het fietspad uit.

Welke methode zouden we kunnen toepassen, om te analyseren?

Foot routering

Als ik hier naar kijk, de eindbestemming van een huis, de adressnode kom ik ook op plaatsen uit achter of naast het huis, de alley, waar vaak alleen footway staat.
Foot navigatie algoritme, doet weinig (?) tot niks met alley tagging.

Ook hier is de BAG node bepalend, zo heb ik de bagnode meer bij de voordeur gezet of verder vanaf het achterpad, alley of zijpad. De Bagnode kwam uit op het rechtse pad.

Ook de driveway ingetekend, maar ik zag laatst ook het gebruik van footway=residential op dat deel van het erf. De buitenste huizen van een blok hebben in potentie meer afwijkingen dan gewenst. Deels onvermijdelijk, wegens zijpaden langs het huis.

Nu had ik dus zelf een testje gedaan. Zou het graag op een andere manier inzichtelijk hebben.

1 Like

Vraag is of je naar de adresnode wilt navigeren of het pand waar de adresnode zich in bevind?
En dan weet je nog niet waar de voordeur en achterdeur zich bevinden. Deuren zijn als het goed is bij de gemeenten bekend vanuit de bouwtekeningen. Een uitbreiding voor BAG 3.0 zodat we op de pandcoutouren entrances kunnen mappen?

Denk dat de eisen van de hulpverleners verder gaan dan we in OSM kunnen vastleggen (uitzonderingen waar dit al gebeurd is bevestigen de regel dat het op veel plekken dweilen met de kraan open is). Vroeger geen probleem, want was ‘iedereen’ lokaal voldoende bekend, tegenwoordig zijn de verzorgingsgebieden zo groot dat dat onhaalbaar is dat iedereen de snelste weg weet te vinden.

Het gemakkelijkst op te lossen door bij het instellen van de navigatie het doel te bekijken met recente luchtfoto oid en het aanrijpunt op een logische plaats neer te zetten. Een meldkamer zou dit als onderdeel van de intake van het incident kunnen pushen naar de navigatie van de aanrijdende hulpverleners.

Voor ons als gewone burgers waar tijd een minder kritische factor is bereid je je iets beter voor of rijd je gewoon nog een rondje en kom je er uiteindelijk ook wel.

Als bedrijven die er baat bij hebben om zo min mogelijk tijd te verliezen (pakjesbezorgers?) kunnen ervoor kiezen om externen in te huren om betere navigatiesoftware te maken en/of de benodigde micromapping uit te voeren. Maar het meest valt daar te winnen als mensen het juiste huisnummer doorgeven en bedrijven dat ook juist vastleggen. Je wilt niet weten hoe vaak hier mensen op de stoep staan omdat een toevoeging A of B niet is opgegeven of een paar regels hoger/lager staat op de adressering waardoor ze eerst bij ons aanbellen.

Hoe je het ook doet er komt een punt uit, vandaar een berekening tot waar, welke wegen nemen we mee of kijk je naar de weg die alleen een naam heeft. Bij een gebouw kan ook de centerpunt worden berekend om tot een punt te komen voor routering. Zo kun je verschillende variatie berekeningen maken voor de vervoersvormen.

Mijn insteek is om de probleem gevallen er uit te filteren, waar we met betere tagging/mapping, dat laatste stukje beter laten navigeren, als het algoritme van routering ook goed genoeg is, wat zeer bepalend is. Neem je bijvoorbeeld alley wel of niet mee.

Zo keek ik naar dit topic met een analyse en een link naar een kaart met meerdere gebiedsvergelijkingen. Helaas niet voor Nederland.

Zo dacht ik vanuit het adrespunt, lijnen naar.

  • dichtsbijzijnde weg
  • dichtsbijzijnde weg voor bepaald vervoervorm
  • dichtsbijzijnde weg voor bepaald vervoervorm met uitzondering van bepaalde wegen

Daarnaast filtering

  • lengte van de lijn
  • de richtingverhouding tot andere lijnen.

Omdat Nederland een van de landen is met de meeste adressen, kijkend naar volledigheid, is het resultaat ook nauwkeuriger.

Om zo te komen tot meer inzicht.