Hier is het logischer om het pad inderdaad af te buigen en (haaks) aan te laten sluiten op de weg. Wat betreft jouw cirkel theorie (welke interessant klinkt), een router kan zien dat de eerste twee nodes relatief dicht op elkaar zitten. Deze zou dan de hoek kunnen pakken van het wegdeel tussen node 2-3 ipv 1-2. Als je in nog kleinere stukjes gaat splitsen kan een router (voor instructies) nog steeds kijken naar bijvoorbeeld het wegdeel tussen node 4-5 door te zoeken naar het eerste wegdeel met minimaal een afstand van 10m (ik noem maar even een getal). Tevens zou die wegdelen kunnen samenvoegen als de hoek bijvoorbeeld tussen 175-185 ligt (bijna rechtdoor).
Ik denk als je zo over dit soort problemen na gaat denken en een serieuze router wilt maken, je de tijd wel neemt om alle weg(delen) te analyseren in een statistische analyse om uit te zoeken wat de beste lengte en hoek is om naar te zoeken voor bepaalde type wegen.
Zeker. Het punt is ook wel dat de router engine er geen enkel probleem mee heeft, die heeft alleen aansluitingen van geschikte wegstukjes (edges, schijnt dat te heten) nodig. Het raakt meer de navigatie-aanwijzingen voor de reiziger tijdens het rijden/lopen, plus het detailplaatje dat ze eventueel bij tonen.
Voor het plaatje wil je als reizende graag de wegindeling en de randen zien, met daarbinnen de lijn die zo precies mogelijk de gewenste bewegingen van het voertuig aangeeft, soepel afgerond dus.
Tegelijkertijd wil je dat de aanwijzingen vóór de manoeuvre wat meer globaal zijn (“sla linksaf via de rotonde”), maar wil je een heel precieze alert op het moment dat het moet gebeuren (“Neem de afslag rechts”.).
Ik denk dat de cirkel het wat complex maakt. Denk dat voor de router het relevanter is welke nodes tot één kruispunt behoren. Dan kan je bepalen welke way(delen) intern zijn en welke uitgaand. Dat is soms erg complex, zoals deze kruising:
Ik denk dat voor navigatie het beste is om dit in twee kruizingen op te splitsen boven de fietsoversteek van de Houtlaan. Maar een router gaat dat niet automatisch kunnen bepalen.
Dat snap ik , maar ook die aanwijzingen zullen vanuit een router komen.
Omdat helemaal perfect te maken zal het belangrijk zijn om de weg ook als vlak te definiëren. Zo kan er zowel een route rechtdoor worden gemaakt als eentje die scherp afbuigt, waarbij beiden zich over het vlak bewegen ipv een rechte lijn tussenbeide.
Mijn mening is vooral map het zo precies als je wilt. Dat door de meer gedetailleerde mapping problemen ontstaan voor de router is aan de router om op te lossen. Er zijn/waren voorstellen voor tags om de routers hierin te helpen. Zo was er bijvoorbeeld Proposal: highway=junction
Hoewel ik het er niet mee eens ben dat het als area gemapt is kan het wel nuttig zijn voor een router om te bepalen wat wel en niet tot het kruispunt behoord. (Ik zou zelf een relatie doen met de interne wegen en/of nodes van het kruispunt)
Ook is er Relation:manoeuvre die voor OSRM een uitgesproken instructie overschrijft. Het lijkt niet overgenomen door andere routers dus dit is wel een voorbeeld van tagging voor de router.
Mee eens. Maar voor mezelf wil ik wel rekening houden met wat je redelijkerwijs van de doorsnee router/navigatie mag verwachten. Als er dan verschillende opties zijn om eea te mappen, dan kan dat de doorslag geven.
UIteindelijk zijn problemen voor de router ook mijn problemen, als gebruiker van de router.
In OSM mappen we de werkelijkheid. En die moet je mijns inziens niet aanpassen aan de functionele wensen van de applicatiebouwer. Zoals de routeerder van het straatnetwerk een afgeleide dataset maakt (een graaf) om over te routeren, zal de routeerder ook een afgeleide dataset maken voor de navigatie aanwijzingen. In het maken van die afgeleide dataset kan je zaken regelen als maak een haakse hoek van een opeenvolgende reeks van opeenvolgende flauwe hoeken, en maak van een T-kruising die minder dan X (5?) meter van elkaar ligt een ‘gewone’ kruising, etc. Dus mijn punt: probeer niet in de data de problemen op te lossen van de softwarebouwer. Het enige valide argument zou zijn als die bouwer meer ‘real-world’ info nodig heeft (zoals bij routeerders zaken als eenrichtingsverkeer etc) die er nu niet zou zijn, maar dat is in dit geval niet aan de orde.
In principe ben ik het daar natuurlijk mee eens, maar het is toch een iets te eenvoudige voorstelling van zaken.
We mappen de werkelijkheid, maar in het geval van wegen mappen we een lijn (of meerdere lijnen) ipv het gebied dat de weg in beslag neemt. Die lijn is er meestal niet in werkelijkheid; het is een abstractie. Waarom doen we dat? Omdat dat functioneel werkbaarder is voor data users én mappers.
Als je zegt "zal de routeerder een afgeleide dataset maken voor de navigatie-aanwijzingen, bedoel je dat routeerders dat zowizo al doen, of bedoel je: dat kunnen ze gaan doen?
En als ze het al doen, worden jouw twee voorbeelden daarmee (in het heden, door bekende routers/navigators) opgelost, dus dat het in de praktijk voor de navigatie niet uitmaakt of ik heel precies afrond of een haakse hoek laat staan?
Je zegt dat meer real-world info niet aan de orde is, maar ik heb op mijn vragen over wanneer de afronding dan wel de verhoeking in de navigatie gaat werken, en hoe hij dan de afstanden of de grootte van de hulpgebieden bepaalt, nog geen duidelijk antwoord gekregen.
Dit is voor brouter en daarvan ken ik de details enigsinds maar de implementatie is anders voor andere routers. Als alternatief kan je gestructureerd gaan testen en kijken hoe dingen werken. Doe dat daarna voor alle andere routers en misschien kom je tot een duidelijk inzicht hoe te mappen voor routers maar ik denk weet dat als je het serieus doet je eerder op een andere conclusie.
En … heeft dat mappen voor de router geen nare consequenties voor andere gebruikers?
Ik heb soortgelijke overwegingen bij het mappen van wegen in steile bergen, zoals bijv. dit pad Way: 799107262 | OpenStreetMap Je zou de korte zigzagbochten kunnen negeren en het kunnen mappen als een rechte lijn, maar die lijn is dan een stuk korter dan de werkelijkheid, en het pad lijkt dan een stuk steiler dan het is. Hoe preciezer je het mapt, hoe langer het pad wordt. Wegen in bergen volgen vaak de hoogtelijnen, zodat ze vlak zijn of geleidelijk stijgen. Maar het verplaatsen van een node in zo’n weg met een paar meter links of rechts betekent ook een hoogteverschil van een paar meter, en dan heb je ineens een bult of kuil in je weg gemapt die er in werkelijkheid niet is, maar wel bijdraagt aan de berekende stijging en daling in zo’n weg. De precisie van de GPS track legt een grens.
, maar ook die aanwijzingen zullen vanuit een router komen.