En dat lijkt me precies het probleem voor de router: in verschillende gevallen verwachten verschillende mensen verschillende dingen en vinden ze verschillende dingen logisch. Software heeft zulke dingen als informatie nodig, om er regels op los te kunnen laten. De router kan niet raden wat willekeurige gebruikers willen, en als het gezocht of afgeleid kan worden moet de informatie over wat, waar en hoe wel voldoende bruikbaar, betrouwbaar en uniform aanwezig zijn in de OSM-data.
Verder, als je routing alleen in NL hoeft te werken kan je de Nederlandse regels en gewoontes zowel op de weg als in OSM als gegeven beschouwen - maar die zijn op vele punten anders dan elders in de wereld.
Och, moeten… maar als de router mbv een bepaald verifieerbaar gegeven op een bepaald object betere uitkomsten kan bieden voor de OSM eindgebruiker, dan zou ik daar wel naar kijken.
Maar dan wil ik eerst van de routeerder horen waar het probleem ligt, wat-ie nu kan en wat-ie eventueel extra nodig heeft om het algemeen op te lossen, en niet alleen voor een bepaald geval in een bepaalde context.
Tot nu toe hoor ik veel gevallen met telkens een ander probleem, en mogelijke oplossingen die niet doorgedacht zijn naar andere situaties, bijvoorbeeld andere landen en andere doelen van de gebruiker.
Zelf ga ik vaak met de auto fietsen afzetten/ophalen op allerlei plekken zonder huizen, waarbij parkeren geen nut heeft en het dichtstbijzijnde woonadres ook niet. Maar even vaak is een parkeerplaats een eis. Om maar een voorbeeld te geven.
Is het dan niet een logische stap om JASMein03M‘s routeringsfout voorbeeld voor te leggen bij Carto ? Kan Carto aangeven waardoor de routering is fout gelopen met een mogelijke toevoeging aan OSM database om de fout niet meer te laten gebeuren als dat de oplossing is.
Als het echt een bug is in Carto dan Carto dit op laten lossen…
En in het laatste geval incasseren dat er nog zoveel bugs openstaan bij Carto daar dat je moet rekenen op in ieder geval een jaar om het opgelost te krijgen…
We hebben in Nederland afgesproken dat we de adres nodes apart inladen via de BAG; dus het is neit de bedoeleing dat je het dan óók op een entrance gaat zetten.
Maar zoals gezegd verwacht ik dat de router slimmer is. Misschien zijn mijn verwachtingen te hoog. Ik verwacht immers ook dat ze netjes over een pedestrian area heen kunnen routeren.
Ok daar heb je gelijk in mijn fout.
Ik heb wel eens contact gehad met Carto maar welke & hoe deze router dan aangeschreven moet worden weet ik dan niet.
Zie OP: Flitsmeister. De search is photon (da’s van komoot denk ik) en levert een geolocatie op. Daarna volgt routing+navigatie naar dat punt.
Dus als het niet goed gaat zou de oplossing kunnen liggen in photon search, die zou een ander punt kunnen leveren, of de routing zou anders gestuurd kunnen worden, dwz andere mogelijkheden of andere wegingen.
Op de osm website worden drie routers aangeboden: valhalla, osrm en graphhopper. De search is daar Nominatim, maar VZIW zijn de routers daar niet aan gekoppeld.
Die routers hebben dezelfde verschijnselen bij sommige punten. Maar op de website verschuif je dan gewoon je doel-druppel een beetje tot hij beter uitkomt.
Ik denk dat wij iets zoeken tussen photon en de navigatie in. Wat photon levert is correct. Deze geeft de locatie van de gevonden hit. Voor navigatie is dat alleen niet altijd het handigste punt.
We gaan bij adresnodes en gebouwen op zoek naar een entrance.
Bij gebieden naar parkeerplaatsen en/of entrances.
En ook niet meer stoppen op een snelweg. Tenzij je bestemming echt op de snelweg ligt. Bijvoorbeeld bij het plaatsen van een pin op de kaart
Als we deze stappen doen gaat het waarschijnlijk stukken beter zijn en in heel veel geval correct. IKEA/dusseldorf/die adressen in Amsterdam zijn dan opgelost.
Dat is interessant! De zoekmachine of een pin leveren een locatie af, die eigenlijk los staat van een kaart. Dan analyseer je de locatie in context mbv de kaartdata, je past regels toe waarmee je zonodig de locatie kan aanpassen/vervangen, en dan geef je de aangepaste locatie doellocatie aan je routeer-engine. En dan draait je navigatie op het routeer-resultaat. Zo heb ik hem goed?
Dan lijkt me entrance=main verkeerd gemapt, dat oplossen dat betekenen OSM bijwerken.
Het enige probleem van wat ik me kan voorstellen is dat iemand (als bijrijder) een route wilt plannen terwijl je op dat moment op de rijksweg rijdt, maar dat geldt alleen voor het beginpunt van de route.
Zoals anderen al aangegeven hebben, geen adressen mappen op een entrance. Een router zou moeten kijken welk gebouw bij een adres hoort en dan op dat gebouw de dichtstbijzijnde entrance kiezen als die überhaupt gemapt is. Dat (bijna) alles adressen gemapt zijn is denk ik uniek voor Nederland, ik ken geen andere landen die iets als een volledige BAG import doen dus ik verwacht dat de meeste routeplanners die met adressen kunnen omgaan non-OSM functionaliteit gebruiken om het adres om te zetten in een coördinaat.
Hebben we een dingetje te pakken die wel kan maar in dit geval niet handig is ?
Misschien is dit hele draadje een onderwerp die we in de volgende online meeting kunnen bespreken ?
Met als doel:
Uitvinden wat wel en niet handig is m.b.t. het routeringsprobleem.
Routing voor alle doelgroepen formuleren zoals Peter al eerder aangestipt heeft in dit draadje: [quote=“Peter_Elderson, post:40, topic:111002”]
Maar dan wil ik eerst van de routeerder horen waar het probleem ligt, wat-ie nu kan en wat-ie eventueel extra nodig heeft om het algemeen op te lossen, en niet alleen voor een bepaald geval in een bepaalde context.
Tot nu toe hoor ik veel gevallen met telkens een ander probleem, en mogelijke oplossingen die niet doorgedacht zijn naar andere situaties, bijvoorbeeld andere landen en andere doelen van de gebruiker.
Zelf ga ik vaak met de auto fietsen afzetten/ophalen op allerlei plekken zonder huizen, waarbij parkeren geen nut heeft en het dichtstbijzijnde woonadres ook niet. Maar even vaak is een parkeerplaats een eis. Om maar een voorbeeld te geven.
[/quote]
Wellicht komen we er al pratend uit, kunnen we er een samenvatting van maken en richting router sturen.
Als er dan in OSM nog dingen vastgelegd moeten worden om de router te helpen met benodigde info kunnen we dat opstarten en vastleggen in Wiki.
Edit1: quote toevoeging van Peter Edit2: plan van aanpak na online meeting
Ja mijn inziens is een OSM wiki pagina na een goede online meeting een goed begin omdat als er extra OSM-info nodig is voor de router dit dan breed gedeeld kan worden binnen OSM NL middels deze documentatie.
Een goed begin lijkt mij ontwikkelen & testen op Nederlands grondgebied en bij succes pas overleg met andere Europese OSM-groepen want je wil niet de Franse toestanden van een paar dagen terug waarbij een Franse OSM gebruiker ook Nederlandse amnities middels een automatisch testproces op zeer grote schaal incorrect aanpaste zonder overleg met OSM NL.
Deze post gaat deels over dit probleem. associated_entrance discussie is hier meer gewenst.
als een node een relatie heeft tot een entrance zou deze koppeling kunnen maken, en zou de navigatie deze node als eindbestemmingsberekening kunnen gebruiken.
Een gebouw met twee ingangen, waarbij binnen het gebouw de loopwegen niet zijn ingetekend, bepalend is dan de plaats van de adresnode (poi) en de meestal in de berekening de haakse afstand tot een highway. Bij aangeven entrance relatie, zou men de kortste afstand entrancenode kunnen kiezen als bestemmings node (ingang van het gebouw) en niet laten lopen om het gebouw heen.
(Let op: het wordt op twee plaatsen beschreven met en zonder _ in de value) keuze voor met _
Dit heeft zich niet doorgezet, omdat algemeen men relatie gebruik moeilijk vindt en dan eerder tegen stemt.
Ik vindt dit een goede oplossing hoor !
Alleen relaties leggen via ID niet…
Als het goed is krijg ik begin mei eindelijk mijn laptop dus dan zou ik dat wel willen testen uiteraard dan niet met ID.
