Pedestrian areas & routing

Communities Nederland (Netherlands)
, ,
61

@Geim, @multimodaal Ik snap best dat het soms wenselijk/handig is om een weg / voetpad door een pedestrian area aan te brengen. In jouw voorbeeld is het overigens gewoon een weg die van de Zwiserse Ambasade naar de Lange Houtstraat loopt.

Maar eigenlijk zou het niet nodig hoeven zijn en zou de router de ‘kortste route’ zelf moeten plotten. Bijvoorbeeld als ik bij De Posthoorn naar buitenloop om mijn dessert bij Cottontree City te genieten; dan steek ik gewoon het plein over. Heb ik daarna een afspraak bij Hairdreams, dan steek ik weer het plein over . In plaats van de route van de router die me via het Toernooiveld laat lopen.
image

Van Lange Voorhout 31 naar Cottontree City wordt je zelfs helemaal via ChiqueauLatte gestuurd. 200m lopen i.p.v. 100m lopen.

image
image641×624 183 KB

Kom ik van het monument voor Bob Oosthoek, dan steek ik daar de trambaan over en loop schuin over naar ‘Stil even, Haai & Krab’.

Het mooie van een plein is dat er een web aan routes mogelijk zijn. En natuurlijk loop ik dan even een om die boom of dat bankje heen.

Het voorbeeld van het water is eender; dat is ook en gebied waar je kriskras doorheen kunt gaan; waarbij er volgens het reglement overigens wel zoveel mogelijk aan stuurboord gevaren en zo haaks mogelijk overgestoken dient te worden. Maar laten we die discussie even parkeren. We hebben het niet over boten, maar over voetgangers.

Dat (de meeste) routers dit erg ingewikkeld vinden en dat we daar vanuit de kaart een mouw aanpassen door de meest voorkomende routes dan maar als weg alsnog aan te geven; is dan nog steeds een workaround en zou eigenlijk niet nodig moeten zijn.

1 Like
62

Lange voorhout is een goed voorbeeld van het probleem. Er lopen 2 tot 4 rijbanen overheen die het plein in stukken delen. Ter plekke loopt de voetganger overal dwars, schuin en recht overheen, maar zhij steekt dus wel altijd een paar wegen over. Wat moet de wandelrouter dan doen? Vrij oversteken? Dat doet-ie bij gewone wegen met aan weerszijden voetpaden toch ook niet, ook al mogen voetgangers dat in de praktijk wel.

Nou weet ik toevallig dat er een aantal rolstoelholletjes zijn, dus dat geeft enige houvast voor getekende oversteken, waartussen je ook paden kan leggen. Het centrale pad in de lengte heeft zelfs een naam: Schelpenpad. Vrij breed pad, maar in OSM kan je dat gewoon als pad intekenen, met verbindingen naar de rolstoeloversteekjes.

Maar goed, in andere gevallen heb je die uitvlucht niet, en tekenen we dus gewoon paden in voor de routes die over het plein lopen. Routeren tussen bestemmingen op het plein lijkt me redelijk nutteloos. Waar het gaat om een voetgangersgebied dat een aantal straten beslaat, of een langwerpig ‘plein’ met hoeken en bochten, lijkt intekenen van een centraal pad mij zowizo terecht.

Als er gemarkeerde routes over een plein lopen, zullen wandelaars die gemiddeld redelijk voorspelbaar lopen, en dat kun je zien aan de markeringen bij en op het voetgangersgebied. Ook hier vind ik het daarom terecht om het gebruikelijke/gemarkeerde pad in te tekenen.

In al deze gevallen gaat het niet om willekeurige dwarsverbindingen op een plein, en zonder een way kan de router het niet weten.

Toch zijn er zeker gevallen waarin het prettig zou zijn als de routers een goede route over een areaal zouden kunnen berekenen. Wat mij betreft hoeft dat dan niet eens een echte route te zijn die alle obstakels vermijdt, ik zou het ook prima vinden als er een “ongesnapte” stippellijn verschijnt van ingang naar uitgang, waaraan je kan zien dat je zelf je weg over de vlakte moet vinden, ongeveer volgens de lijn. Dan heb je wel een aaneengesloten route, maar een deel moet je zelf terplekke navigeren.

Voor een vastgelegde gemarkeerde routerelatie is dat vaak geen optie want de markering schrijft de route voor, zodat er juist niet meer gerouteerd wordt onderweg.

Kortom, zelfs als routers intelligent over gebieden zouden kunnen navigeren, zou ik voor de meeste gevallen nog steeds ways intekenen.

2 Likes
63

Dit zou inderdaad de betere optie zijn. En dan kan je dus ook direct vanaf een willekeurig adres aan het plein naar een willekeurig adres aan de andere kant van het plein worden geleid. En bovendien hoef je dan alleen maar te zorgen dat er een verbinding is tussen de weg, het areaal en de ‘rolstoelholletjes’ (mooi woord voor scrable/galgje) om aan te geven dat dit een prefered verbinding is.

Begrijp me niet verkeerd, ik zeg ook niet dat het inteken van een weg over een areeal nooit nuttig is; er zijn situaties waarin dit nuttig is of zelfs noodzakelijk bijvoorbeeld daar waar een uitgezette route dwars door een winkelgebied loopt.

Maar neem de dam, waar je bijvoorbeeld het momunment alleen van één kant kan benaderen; omdat daar toevallig een weg naar toe getrokken is. Dat klopt gewoon niet, maar ik vind het ook geen oplossing om á la “voor de renderer/router” dan maar een spinneweb van paden over het plein te leggen.

1 Like
64

En daar ligt het probleem. de router plot idd de kortste route, maar dat is niet altijd de route die de netwerkbeheerder over de pedestrian area heeft uitgezet.

Neem deze route. Als er geen wegen door de pedestrian area waren getekend, zou de route links bij het gemeentehuis langs zijn gegaan als je het aan de router overliet.

image
image996×1067 299 KB

65

Voor de renderer hoeven er geen paden over het voetgangersplein te liggen, lijkt mij.
Er lopen geen voorgebakken routes op dat gedeelte, dus daarvoor hoeft het ook niet.
Voor de routeerder dan, wandelprofiel. Als je naar het monument wil lopen dan lijkt het mij voldoende als je naar de dichtstbijzijnde rand genavigeerd wordt.

De trapstoep om het monument heen is met kerb-cirkels gemodelleerd, niet gek. De bovenste tree heeft een voetpaadje rondom, begrijp ik ook; je zou ook kunnen zeggen dat elke tree een rondlopend pad is, maar het zou een tikseltje overdreven zijn om dat te mappen.
Op de trap zijn wel een soort trap-paden uitgezet dmv andere bestrating, en een enkele daarvan heeft ook rolstoelholletjes. Die zou je wmb ook als aparte way kunnen taggen. En dan is het ook niet gek om die naar de dichtsbijzijnde footway rond (dat deel van) het plein te verbinden. Maar dat is nu niet gedaan.

Het enige pad vanaf de omtrek naar het monument dat er nu is ingetekend loopt vanaf een zebrapad via de rolstoelopgang naar het monument. Niet gek, want voor een rolstoelnavigatie is de route over het plein belangrijk.

Kortom, ik vind het helemaal niet gek hoe de Dam nu gemapt is. Hier is over nagedacht!

66

Precies; maar dit is heel specifiek voor een uitgezette route; prima om daar een ‘routerings pad’ voor te leggen.

Het gaat mij er meer om dat het niet nodig zou moeten zijn om alle andere mogelijk verbindingen over een areaal te hoeven leggen. De router zou dit zelf moeten kunnen; zonder daar specifiek nog lijntjes voor nodig te hebben,

1 Like
67

Dat is waar ik het de hele tijd over heb :innocent:

1 Like
68

Eens; het is best netjes gedaan om - met de beperkingen die de router heeft - toch een soort van nette oplossing aan te bieden vanuit de kaart.

Maar het geeft wel gekke instructies waarvan ik vind dat de router dit slimmer zou moeten doen; zonder dat wij dit vanuit de kaart gaan oplossen.

Natuurlijk een beetje gek dat als je vanuit de Warmoestraat komt; de router je 180m laat omlopen voor een stukje wat rechtstreeks nog geen 50 meter lopen is. Puur en alleen omdat de router niet snapt (of niet wil snappen) wat een voetgangersgebied is.

En de enige oplossing is om er dan maar vanuit de kaar er voetpaden overheen te laten lopen; is niet echt een elegante oplossing.

image
image881×755 170 KB

Hier nog zo’n voorbeeld; loop je de bijenkorf uit en je wilt bij Bistro Berlage een kopje koffie drinken; dan kom je er niet.

image
image552×607 72.4 KB

En natuurlijk is dit iets waar jij en ik in de echte wereld nooit een routeplanner voor zouden gebruiken. En Apple, Google etc… lukt dit ook niet.

Maar misschien leg ik de lat hoger; van wat het zou moeten zijn en waar we naartoe zouden moeten werken.

Stel nu dat jij blind bent en onbekend in de stad. Hoe mooi zou het zijn als de OSM planner via geluid jou wél die rechtstreekse route over het plein aan kunt geven; inclusief waarschuwingen voor een stoeprand, een prullenbak etc…

Wellicht dat dit wordt opgelost met een camera-bril en een AI (zoals Mapillary al doet) die dingen realtime omzet naar auditieve instructies. En toch, als de basis goed is, kunnen dan soort dingen alleen maar beter zijn.

69

:+1:t3:

Maar daar ging/gaat mijn initiele vraag niet over :wink:
Die ging over een navigatie over een pedestrian area en dat het daarvoor nodig is dat er naast de area óók nog paden overheen moeten lopen.

Als je een hele specifieke manier eroverheen wilt lopen (omdat een wandelroute slingerend over de area heen loopt); ja dan zal je dat aan moeten geven; maar anders niet per se. Terwijl dit nu wel het geval is.

70

Voor de duidelijkheid, dat is niet willekeurig. Die route is de enige route waar je geen stoeprand tegen komt.

Ik snap ergens wel dat het wenselijk is dat routes gegenereerd kunnen worden op basis van vlakken. Maar dan zou het wel fijn zijn als je er zelf wat in verdiept, want nu klinkt het heel erg als dat je iets conceptueel wilt zonder dat je enig idee hebt wat daarvoor technisch behaald moet worden.

1 Like
71

Toch benieuwd: kan je aangeven waar in het Binnenvaartpolitiereglement staat dat je op open water zoveel mogelijk stuurboord moet varen en haaks moet oversteken?Die kende ik nog niet en lijkt me als watergebruiker om meerdere redenen vaak onwerkbaar op open water.

Maar laten we die discussie even parkeren. We hebben het niet over boten, maar over voetgangers

De werkwijze voor waterways is hier juist erg relevant, omdat er wat misverstanden lijken te zijn over de gebruikelijke werkwijze in OSM en wat de uitzondering.

Bij waterways al langer ervaring is met het vlakken naast lijnen dan bij highways. Een zo consequent mogelijk aanpak voorkomt terugkomende discussies over uitzonderingen, die moeten goed worden onderbouwd.

Bij waterways is het gebruikelijk om de de waterway-lijnen die uitkomen op een open water-vlak met elkaar te verbinden met waterway-lijnen, het vlak komt niet in plaats van de lijnen. Modelleren om de vorm van zaken weer te geven (vlakken) en om routeerbare netwerken weer te geven (lijnen) bestaan naast elkaar, niet in plaats van elkaar (zie de algemene uitzondering daarvoor op het One feature one element-principe.

Waarom zou dat bij highways anders moeten zijn?

En welke vlakken zouden dan allemaal in de plaats van highway-lijnen komen?
Ook een man_made=bridge als het brugdek gelijk is aan het wegdek of een area:highway=footway of area:highway=motorway ?

Het is goed om daar een helder beeld bij te hebben voordat andere mappers die gebruikelijke modellering volgen toch een vorm van “mappen for the renderer / router” wordt verweten.

72

Okee, hier valt bij mij een kwintje wat nog niet gevallen was: als je je doelpin op het monument zet, dan zoekt de router door tot hij er zo dicht mogelijk bij is, en omdat er vrij selectief paden zijn getekend (met reden) zal hij zeggen dat je die moet nemen. Dat doe je natuurlijk niet, want je ziet je doel al staan, maar in andere gevallen kan het vervelender of nog vreemder zijn. Dan zou je willen dat de router ofwel bij de rand zegt: je bent bij het juiste voetgangersvlak, kijk zelf maar hoe je eroverheen loopt. Of: hier is een gislijn, volg dat zo goed en zo kwaad als het gaat.

Persoonlijk zou ik dat voor wandelen willen oplossen door de router bij de rand te laten stoppen. Maar ik zou dan niet weten hoe de router het verschil kan weten met een ingewikkelder voetgangersgebied wat niet geheel te overzien en te doorkruisen is. Iets met een (virtuele) zichtlijn of zo?

PS je weet als router wel wanneer je op moet gaan letten, want het entrypoint is een knoop. Als er dan geen bijbehorende exit is, ben je er eigenijk al.

1 Like
73

De vlakken waar ik zelf van mening ben dat het overgaat, zijn pedestrian squares. Ik ben van mening dat de enig lijnen die hier ingetekend horen te worden, zijn de lijnen voor route relaties. En dat als je geen route relatie volgt de router je een soort hulplijn zou moeten geven hoe je van het ene uiteinde van het plein naar het andere moet lopen. Zonder dat wij daar als mappers misschien wel tientallen lijnen voor moeten mappen.
De dam is hier een goed voorbeeld voor als open plein. Maar zo zijn er nog heel wat meer pleinen over de wereld die een goed voorbeeld hiervan zijn.

1 Like
74

In mijn beleving zijn vlakken in het algemeen meer voor het visuele aspect.
De ‘ways’ zijn voor het navigeren/routes volgen.

Bij een open en vlak plein kun je zelf lopen waar je wil. Maar als er barrieres zijn, of trappen (bij hoogteverschil) zijn de keuze hoe je loopt al beperkter.
In de praktijk zullen er bepaalde paden over een plein zijn (voor het oversteken van de ene weg naar de andere). Als het grasveld zou zijn, dan zou het zichbaar worden, maar dat gaat bij een verhard plein niet op.

Het moet geen verplichting zijn om lijnen in vlakken te tekenen, maar het kan een verfijning zijn. Dus ook geen ‘verbod’.

75

Ik wil hier geen discussie over het BVPR starten (daar zijn andere fora en post voor ;-)); en ik ben zeker geen expert op het gebied van het BVPR en dat is nogal uitgebreid en er zijn vele uitzonderingen. Het is mij altijd aangeleerd vanuit de pleziervaart en iirc ook de wateralmanak; maar verwacht geen artikel kennis tot in detail.

Een snelle zoektoecht op wetten.overheid.nl geeft artikel 6.30:

Een varend schip moet zo veel mogelijk aan de stuurboordszijde van het vaarwater varen.

Hierop zijn allerlei uitzonderingen en voorziet het reglement er ook in dat er schepen zijn die dat niet doen/niet kunnen (immers ‘zo veel mogelijk’); maar ook dan " moet het schip dat niet de stuurboordszijde van het vaarwater volgt voorrang verlenen aan het schip dat de stuurboordszijde van het vaarwater volgt".

Het zo recht mogelijk oversteken van een vaarweg volgt uit het zo min mogelijk hinderen van andere schepen en het zoveel mogelijk suurboord houden. Het staat volgens mij niet expliciet aangegeven in het reglement. Wel staat het vaak bij kruizingen van groot vaarwater met klein vaarwater aangegeven.

Bijvoorbeeld bij het uitvaren van het Smal Weesp bij de sluis Driemond en je vaart richting de Vecht staat aan beide zijde voordat je het Amsterdam Rijnkanaal opvaart het volgende bord:
image

Eérst het kanaal opvaren naar stuurboord het kanaal volgen todat je zo haaks mogelijk over kunt steken om dat weer aan stuurboordzijde terug te varen naar het Smal Weesp.

76

Ik zou het jammer vinden als we in de wereld (en dit forum) alleen maar iets mogen bespreken als we ook alvast de technische oplossing hiervoor bedacht hadden. Gelukkig is dit ook niet zo; want anders zou ik snel zonder werk zitten en mijn collga’s ook.

Ik heb technisch geen idee hoe dit te programeren is; maar juist door de use case te beschrijven denkt wellicht iemand die dat wel heeft; hé daar had ik nog niet aan gedacht, eens kijken hoe ik dat werkend kan krijgen.

Ik heb best een idee hoe het zou kunnen werken (en veel routers doen dat al als ze geen weg kunnen vinden) en dat is door wat hier ook door andere al als oplossing gegeven wordt het geven van een gislijn. (apple/google doen dit als stippelijn bijvoorbeeld)

Je zou daar nog iets slimmer mee om kunnen gaan als de router zich bewust is van het vlak; dan kent deze ook het middelpunt van het vlak, of de in- en uitgangen van het vlak (een node gedeeld met een weg, of een voordeur van een gebouw of…). De router kan dan een virtuele lijn trekken tussen deze twee nodes over het midden van het vlak. Zoiets.

Hoe je dat technisch exact op moet lossen; hoop ik op de slimme koppen die dat uitwerken. De kracht van de mens is samen werken om mooie nieuwe dingen uit te vinden.

1 Like
77

Helemaal mee eens. Ik heb verschillende theoretisch oplossingen en zelfs een werkend proefmodelletje voor routeren over een plein zonder paden gezien. De vraag is wel: kun je precies definiëren wat de router geacht wordt te vinden, en wanneer de router dat moet gaan doen? Waar ziet de router software dat precies aan, wat is zijn trigger? En wanneer moet-ie dat juist níet doen, bijvoorbeeld als er een route via een “onzichtbaar” pad loopt maar die geeft een ongewenst resultaat, hoe kan de router dat weten?
Als je doel niet op het plein ligt, maar een eind verderop, wat is dan de exit van het plein? Of moet-ie alle omtrekpunten als mogelijke exit beschouwen? Of moet-ie alleen routes tussen bestaande nodes op de omtrek overwegen?

78

Goede vragen @Peter_Elderson.

Primair zou je de entry en exit punten kunnen laten zijn daar waar een andere weg op de area aangesloten is, danwel een adres/deur node. Alle omtrekpunten is niet altijd mogelijk; immers een gebouw wat grenst aan de area kan geen entry/exit zijn, tenzij daar een deur in zit.

Binnen de area kan je in theorie willekeurige navigeren; behalve dat je rekening zou moeten houden met obstakels zoals bomen, prullenbakken etc…

79

Als je dit bij een router wil aankaarten moet je het heel goed definiëren.
En beginnen met een enkele geval, niet alles tegelijk willen.
Dus voor nu beperken tot pedestrian area. Struingebieden dus nog even buiten beschouwing laten.
Punt-obstakels zoals prullebakken en bomen zijn MI niet interessant, die hoef je voor een benaderende lijn niet mee te rekenen. Kan een latere verfijning zijn. Wel: uitgesneden dingen, dus het moet op een MP kunnen werken, en vlakken zoals gebouwen en water (ook als ze niet uitgesneden zijn).

Wegen en paden moeten met een node op de omtrek aangesloten zijn om connectiviteit te hebben.
Voor adressen en entrances binnen het gebied geldt dat dacht ik niet, die kunnen gewoon los binnen de area voorkomen. Ik weet niet of dat het een ander geval maakt, routeertechnisch gezien.

Pedestrian area’s kunnen aaneengeschakeld zijn, dat is misschien nog een apart geval.

Output: visueel wil je de berekende “beste” virtuele lijn zien, die obstakelvlakken vermijdt, en wel herkenbaar is als virtueel. Wat zou de (stem)navigatie-aanwijzing moeten zijn? Moet die gewoon zeggen “zoek je weg over het plein” of moet die ongeveer de richting van de lijn en eventuele bochten aangeven? Of heel specifiek “passeer het stadhuis aan de linkerkant, loop om de fontein heen en dan rechts aanhouden naar de Sloddervoslaan”.

80

Dank je Otto! Ik ben weer gerustgesteld, dacht even dat ik iets had gemist in het BPR en toch mijn veronderstellingen moest bijstellen, zowel in gedrag op het water en mogelijk ook in mappen van waterways op open water. Je hebt zeker een punt met je constatering dat BPR complex kan zijn.

De aangehaalde bepalingen van bij voorbaat aanhouden stuurboordszijde gelden alleen in hele specifieke omstandigheden. Bpr artikel 6.30 is onderdeel van Afdeling VI. Slecht zicht en daarvan is in art 6.29 bepaald:

Deze afdeling is alleen van toepassing bij slecht zicht.

Een soortgelijke valkuil zit er bij de “zo veel mogelijk aan stuurboordszijde van het vaarwater varen”-bepaling zit ook bij artikel 9.04, dat geldt alleen op een beperkt aantal aangewezen vaarwegen en dat is ook geen open water, maar dat zijn kanalen of delen van rivieren.

Voor deze discussie hier is dus van belang dat voor verkeersdeelnemers op open water in beginsel eenzelfde soort “vrij om te gaan waar je wil” principe geldt als voor voetgangers in een voetgangersgebied.

En daarom is het goed om de consistentie met de modellering in OSM van die twee situaties in het oog te blijven houden (waarbij afwijken ook een mogelijkheid kan zijn, maar daar moet dan wel een goede reden voor zijn).