Of het een grote klus betreft bevalt over te twisten; maar in ieder geval was ik al weer even bezig met de planetenwijk in Duivendrecht. Een vóór heb ik niet gemaakt; maar een tijdens en na wel. Wat je niet op de kaart ziet is dat ook de snelheden, en wegbreedtes nu erin staan.
Lekker bezig! Ik zie dat jij niet doet het leggen van paden onder polygonen zodat routers er ook wat meekunnen?
ehm nee… ik ga ervanuit dat een router zo slim is om te begrijpen dat als een pad verbonden is met een pedestrian area deze dan hierover overheen routeert.
Vanuit het principe dat een pedestrian area een voetgangersgebied is en net zoals een plein kris kras overgestoken kan worden. Paden “eronder” leggen voelt een beetje als ‘tagging voor de renderer’ 
Toch verstandig om het wel te doen. Anders moet je een heel pedestrian area in de route relatie gooien als er een route langs loopt.
Nu loopt er hier geen route relation doorheen; maar wat zou het bezwaar zijn om een pedestrian area op te nemen in een route relatie als die daaroverheen loopt?
Gezien de verve waarmee hier doorgaans het ‘tagging for the renderer’ wordt bestreden; verbaast het me eerlijk gezegd dat jullie hier zo een uitzondering voor de router maken
Een routerelatie kan niks met een area.
In de relatie editor krijg je de routelijn niet sluitend.
Er blijft een gat in de route.
Knooppuntnet geeft ook direct een foutmelding voor een knooppuntroute met een area erin. Zal een onderbroken route melden.
Dit heeft niks met tagging for de renderer te maken.
Verwar renderen niet met datagebruik
Tagging for the renderer is bijv. een bepaalde landuse gebruiken om een specifiek kleurtje te krijgen.
Routes worden op de standaardkaart niet eens gerenderd.
Maar de users van de route willen een duidelijke aansluitende routelijn en die geeft de area niet.
1 Like
Ik ben het er zelf niet mee eens dat het nodig is. Ik ken alleen geen enkele router die over polygonen kan routeren. Dus snap ik wel dat mensen er paden onderleggen om te zorgen dat je nog gewoon een normale wandelroute krijgt en niet eentje “om het plein heen”.
Maar je hebt volkomen gelijk, dit is gewoon tagging voor de router, wat niet hoort.
Uhm, renderen is ook datagebruik? Dit is gewoon simpelweg tagging voor de router. Routers en ook routerelaties moeten dit gewoon kunnen gebruiken. We hebben ook niet voor niks de regel “one feature, one element”.
1 Like
OSM moet m.i. ook werkbaar blijven dus is het soms schipperen.
Ooit ben ik met OSM begonnen om aan een routeerbare kaart voor m’n fietstochten te werken.
Ieder heeft toch z’n eigen insteek.
Ik zie er geen bezwaar in om over een highway=pedestrian met area = yes een highway=pedestrian in te leggen. Bij de winkelstraten in mijn stad heb ik dat ook gedaan.
Je krijgt anders bv routes via de huizenrijen.
Hulpdiensten maken ook gebruik van OSM. Die taggen ook emergency accesstags op de paaltjes. Dat zou anders niet werken met vlakken.
Ook de routerelaties zijn een ‘dingetje’.
Je ziet op de kaart lijnelementen niet eens liggen. Ik ben het dan ook eens met Dvdhoven.
Er zijn wel meer uitzonderingen op de regel binnen OSM.
We kunnen het appmakers van kaarten natuurlijk het helemaal onmogelijk maken om nog routekaarten te maken. Dat lijkt me niet de bedoeling.
In Duitsland lag ik regelmatig met een mapper in de clinch die wegen op slot zet voor fietsers omdat er highway=track en/of lane is getagd.
De kaarten maker zoekt het maar uit… Jammer dit soort acties.
En ik ken zelfs een mapper die het het helemaal onnodig vindt dat de OSM kaart routeert. Inmiddels geblokkeerd.
Leven en laten leven zal ik maar zeggen.
1 Like
Daar heb ik 2 dingen over te zeggen:
a. Het gaat niet om een bepaalde routeerder, maar om alle routeerders. Je mapt en tagt het zo dat het routeerbaar is. De stand van zaken nu is zo dat routeren over area’s in de praktijk niet inpasbaar is in de bekende routers. Voor routerelaties is het zo dat area members bij datagebruik een breuk in de route veroorzaken.
b. Alle wegen en kruisingen zijn eigenlijk areas maar worden als lijnen gemapt. Ook watervlakken worden (aanvullend) als lijnen gemapt voor renderbaarheid en routeerbaarheid. Dus het trekken van lijnen over area’s vanwege rendering en routering is niet uitzonderlijk; het mappen van een verkeerselement als area is juist de uitzondering.
1 Like
Natuurlijk willen we dat OSM kaart bruikbaar blijft en kan je kijken hoe je het renderers, app makerss en routers makkelijker kan maken; maar ik ben ook van mening dat we daarmee niet de kaart moeten vervuilen en hen ook moeten aangeven hoe ze daar rekening mee moeten houden.
De pedestrian street als area heeft - net als een plein - het nut dat het een volledig overloopbaar oppervlak geeft en niet dat je een soort van spaghetti aan voetpaden krijgt. Wat is anders het nu van een pedestrian area als we daar alsnog allemaal pedestrian streets of andere paden overheen gaan tekenen?
Een router kan hier ook iets slims mee doen door te kijken naar het entry en het exit point van de route op de area en daar dan een virtuele lijn tussen te trekken voor routing purposes.
Het enige is dan dat je moet zorgen de paaltjes op de randen van de area staan en dat wijkt dan mogelijk af van waar de paaltjes daadwerkelijk staan. Alternatief is dat je daar waar paaltjes staan een scheiding tussen twee areas maakt.
Kan je hier een voorbeeld van laten zien? Dan kan ik het eens bestuderen.
Ik heb even gekeken; maar GraphHopper heeft geen enkele moeite om te routeren over een area:
Net als OSRM of Valhalla; waarbij die laatste de route zelfs voor fietsers over de pedestrian area heen doet.
Dit zijn toch de drie standaard routers die OSM zelf aanbiedt.
Dat is voornamelijk omdat het een paar dagen kan duren voordat de routerings graaf geupdate word, uit mijn hoofd was er één router die daadwerkelijk area routering doet.
Zelf zou ik dit niet taggen als highway=pedestrian, ik hou highway=pedestrian liever over voor straten. En highway=pedestrian+area=yes als het loopbare vlak binnen een place=square.
1 Like
Ander voorbeeld: Brink, Deventer met routerelaties en een keuzepunt voor het wandelnetwerk
Ik had een link naar Waymarked Trails ingevoegd, maar die werkt maar 1 kant uit, je kunt na aanklikken, vanuit WMT niet meer terug naar hier. In WMT is vorige en volgende pagina uitgeschakeld.
Deze link en alleen rechtsklikken en dan nieuw tabblad oid
WMT Brink Deventer
1 Like
Omdat wanneer je de hele binnenstad als 1 grote pedestrian area mapt je niet de juiste (uitgezette/beborde) route krijgt, maar iets wat de router gegenereerd heeft. Ergens ga je vanaf een weg (laatste in de routerelatie voor de area) de pedestrian area op en dan neemt de router de kortste weg naar de volgende weg in de routerelatie. En dat is niet altijd de uitgezette route.
1 Like
Het schijnt dat sommige dan via het randje gaan (die beschouwen de highway=pedestrian dus als een weg, niet als de omtrek van een loopgebied).
Ik heb nog geen enkele router gezien die dit niet doet.
Volgens een commentator die ik denk het wel weet, was het rond een jaar geleden zo dat er maar één router ‘omnidirectioneel’ met areas om kon gaan, dus een lijntje van punt A aan de rand naar punt B aan de rand routen. Daarom is het nog steeds noodzakelijk om bijv ‘link’ wegen bijv highway=footway + footway=link te mappen over een gebied (niet veel maar vind er toch 21K in TagInfo) over een plein bijv maar de meesten mappen toch normale wegen/straten, stoepen etc in zo’n gebied.
Met Pedestrian area wordt het interessant, zeker met Carto. Als je er één zou intekenen met gebouwen erin dan wordt het een grijs vlak, geen gebouw meer te bekennen. Om die gebouwen, in Carto, terug te krijgen zou je ze dan een inner rol moeten toekennen in die voetgangers zone. Blijft natuurlijk dat zulke zone’s uitzonderingen hebben voor bewoners, toelevering verkeer etc. Voor hen dus nog steeds die wegen intekenen en dacht dat daarover toch wel consensus bestond.
Het belangrijkste is niet de routers, die het wel of niet doen.
Het belangrijkste zijn de routerelaties, die moeten lijnelementen hebben.
Zie ook het voorbeeld dat ik heb gegeven van de Brink in Deventer, daar lopen routerelaties van het wandelnetwerk en midden op ligt een keuzepunt (knooppunt). Daar ontkom je niet aan lijnelementen, anders ligt er een keuzepunt in het niets, onbereikbaar voor de routerelaties, die moeten naar het keuzepunt lopen.
2 Likes