Wikipagina over node networks

Communities Nederland (Netherlands)
21

Paar opmerkingen:
Er staan 2 routes 63-63, die kunnen samengevoegd worden tot 1 route 63-63
In de routes 63-63 staan de knopen in de route, die kunnen eruit. Ze doen niets en zijn niet nuttig en kunnen problemen veroorzaken.

Deze situatie hebben we al in NL en die werkt goed, de grote pijnpunten zitten bij de forward/backward routes, omdat knooppunt.nl daar gaat denken in tentakels. Bij een route zonder forward/backward doet hij dat niet en kun je tich keer een knooppunt opnemen in 1 route, bijv een route 27-27-27-28-28 als ref=27-28 zal geen enkel probleem geven in knooppuntnet.nl, mits je de volgorde goed houdt, begint met de beginknoop 27 en eindigt met de eindknoop 28. 27-27-28-27-28 gaat wel problemen opleveren bij een route 27-28

Alleen kun je beter hiervan een route 27-27, een route 27-28 en een route 28-28 maken.

Zie ook:
kp 51 in Almelo: https://cycling.waymarkedtrails.org/#?map=17!52.3561!6.6685
kp 82 in Almelo: https://cycling.waymarkedtrails.org/#?map=15!52.3402!6.6534

Ik ben er ook sterk voorstander van om het op deze manier aan te pakken.

22

Gedaan. Was in een kwartier gepiept: twee nieuwe korte routetjes maken en in het netwerk zetten, dan die “overlapstukjes” uit de 5 routes halen.
De overlapstukjes hadden in de knooppuntroutes rollen backward en forward zonder dat er een terugweg in stond; die wegen zijn gewoon tweerichting. Dus ik heb die rollen gewoon weggehaald en er nette routetjes van gemaakt.

De OSM fietslaag heeft het nog niet verwerkt.
Knooppuntnet/Planner werkt precies hetzelfde
Waymarkedtrails: precies zoals verwacht: https://cycling.waymarkedtrails.org/#?map=17!51.899!4.5499
Knooppuntnet/Analyse: Geen fouten, geen subpunten a b en c meer.

Ik denk: operatie geslaagd.

23

Die overlapstukjes zijn dus de tentakels en die heb je nu keurig verwijderd en die forward/backward is omdat een tentakel per definitie eenrichting is, ongeacht wat de weg is.

Het basisidee achter de tentakelmethode is, dat je als je op een verdeeld knooppunt aankomt, de vervolgroute je komt “ophalen” met een eenrichting route over de rest van de knooppunten van het knooppunt heen. Dus alle routes krijgen een begin- of eindtentakel en dat levert een dikke bundel op en de nodige onderhoudsproblemen.

Prima actie en mocht je nog meer van deze situaties tegen komen, aanpakken.

24

Wat voor problemen? Kun je een voorbeeld geven?

Bij wandelnetwerken veroorzaakt het vziw nergens problemen. Door toepassingen worden ze genegeerd, maar ze zijn visueel heel handig in JOSM, vooral bij het uitbreiden van een netwerk. Bijvoorbeeld:

  • je selekteert een knooppunt, dan zie je de expected op 3 staan en daaronder staat dan: lid van: en dan staan er de netwerkrelatie en 3 knooppuntroutes.
  • In de relatie-editor zie je de ref-tag en die moet overeenkomen met de begin- en eindknoop.
  • Loop je in volgorde de memberlist door, dan zie je snel of de wegen goed aansluiten op de knooppunten, en in de tooltip zie je de tags.
25

Die knopen hebben de neiging te gaan “zwerven” door de route. Bij het toevoegen van een weg komen ze bijv. op een verkeerde plek. En vervolgens geeft knooppuntnet.nl een volgorde fout.

Ook bij uitbreidingen en aanpassingen zitten ze geregeld in de weg.
Ik hergebruik routes en maak ook nieuwe routes uit andere routes en dan heb ik alleen maar last van die knopen.

Maar zoals jij er tegenaan kijkt, kunnen ze weer handig zijn.

Dus ja, wat is wijsheid?

26

Dank je! Dat had ik wel ff nodig!

Waar het om ging: kan ik dit als voorbeeldmethode in die wikipagina opnemen? Dus als geval waar er een gesplitst knooppunt is maar geen gesplitste route. Dan is dat namelijk voor alle transportmethoden gelijk.

Dan resteert nog een standaardmethodiek voor fietsen met heen- en terugverschillen. Ik begin steeds beter te snappen wat jij zegt, maar het is voor niet-ingewijden echt een moeilijke puzzel die MI mappers afschrikt.

Hoeveel mensen in NL kunnen dit, vraag ik me af? Ik weet dat de Duitse knooppuntmappers er (nog) niets van snappen. Die zijn nog aan het ontdekken dat je niet de fysieke paaltjes mapt maar de intersections.

27

Nou, ik kan ze voor fietsen erin zetten bij uitbreidingen en omzettingen, en weer weghalen daarna. Heel veel zal het niet voorkomen, want ik heb aan het wandelgebeuren zat werk!

Bij uitbreidingen en aanpassingen van wandelnetwerken zet ik altijd eerst de knopen goed, en dan maak ik de wegen ertussen in orde. Als Knooppuntnet dan een volgordefout geeft, heb ik inderdaad iets niet goed gedaan, dus dat helpt mij. Ik ben helaas te slordig om het in één keer gegarandeerd goed te doen.

28

Dit is toch gewoon hoe forward- en backward-rollen binnen OSM werken? Als je het goed doet, zie je dat ook in het JOSM-relatievenster. Misschien een link toevoegen naar deze pagina?

29

Ja, dat kun je opnemen.

Prima, er zal een lijstje van links moeten komen, denk ik zo, er zijn ook nog helppagina’s voor de relation editor

30

Ik denk dat ik dat wel redelijk beschreven (jatwerk hoor) heb, ik kan jouw link er wel bijzetten.
Het gaat er nu vooral om hoe je dat dan doet als heen en terug op verschillende plekken van een complex kruispunt of rotonde landen, waar een gesplitst knooppunt is. Want alle beide richtingen van alle routes moet connectiviteit hebben met alle andere routes. En met zichzelf, want je kan in een planner heel makkelijk een knooppunt als omkeerpunt hebben.

Er zijn dus verschillende manieren om die connectiviteit te bereiken.

a. Het oude tentakelmodel, wat we nu denk ik aan het afschaffen zijn.
b. De methode van Dick, die zegt eigenlijk: laat de heenrichting landen op het eerste splitspunt, en vandaaraf maak je de terugrichting langs de andere deel-knopen van het gesplitste knooppunt.
c. De methode waarbij de deelknopen onderling verbonden zijn met korte tussenroutes, en waarbij de routes dus heen op een ander deelknooppunt landen dan waar de terugroute vertrekt.

a had, lijkt het nu, alleen maar nadelen. De checks moeten er tamelijk ingewikkelde uitzonderingen voor handhaven.

b garandeert de connectiviteit, je kan de duidelijkheid handhaven dat een fietsroute altijd een aansluitende/rondgesloten continuity line in JOM laat zien, maar er zitten tussenknopen in de node2node routes en veel overlappende stukjes route, wat dan weer niet zo duidelijk is. Ook hier geldt: De checks moeten er tamelijk ingewikkelde uitzonderingen voor handhaven. Maar die zijn er al en werken wel.

c bereikt de connectiviteit op basis van standaardmapping zonder speciale functionaliteit in de checks, maar de routes hebben gespleten eindjes, dus geen gesloten continuity lijn in de relatie-editor van JOSM.

Als er geen backward-forward speelt, levert c de eenvoudigste opzet, want heen/land- en terug/vertrekpunt pr route zijn dan altjjd gelijk, de continuity lijn in JOSM is goed, all checks kunnen uitgevoerd worden zonder speciale verwerking voor gesplitste knooppunten, en het werkt voor alle netwerken ongeacht transportwijze.
Aanvulling: helaas is de continuity line in JOSM nu niet goed! Het is meer dan alleen het niet meer samenvoegen aan het eind, hele takken hebben geen doorlopend lijntje terwijl ze goed ingevoerd zijn.

31

Dit is een relatie die alle knooppunten aan doet bij 25.

25-73

https://cycling.waymarkedtrails.org/#route?id=92298&map=17!53.2068!5.8005

Deze niet:
25-91

https://cycling.waymarkedtrails.org/#route?id=9721296&map=18!53.2059!5.8014

21-25

https://cycling.waymarkedtrails.org/#route?id=90302&map=18!53.2052!5.8017

Die laatste twee kruisen elkaar niet, is dat dan correct?

Hoor je dan eigenlijk de langste route er in te zetten? Dus alle afslag(knoop)punten van het knooppunt aan te gaan. Methodiek langste invullen.
of
Methodiek kortste invullen, er zijn van die knooppunten, waar je eerder kan oversteken of een twee richting rotonde kan nemen, dan heb je de mogelijkheid om de kortste route voor die afstand te kiezen. Niet toegepast bij 25-73.

Op knooppunt 25 zie ik twee methodieken door elkaar gebruikt.

Kan dat wel? Het door elkaar gebruiken van methodieken. Consistentie.

Problematiek: doorsteekjes binnen het knooppunt, kortste route mogelijkheid. Hoe die aangeven bij langste methodiek methode?

Stel mij voor, ik haal alle knooppuntenroute relaties op dan heb ik een database om te routeren En neem startknooppunt, via knooppunten, eindknooppunt. Berekend de kortste ( waarschijnlijk ook meest logische) route.

Of ik haal alleen op al die relatie die ik nodig heb, uit centrale database(overpass) en bereken dan de kortste route.
Dan gaat het mis. Voorbeeld boven. Niet rakende routerelaties.

32

Goede vraag!

Puur technisch:

Zolang het alleen om renderen gaat, maakt het niet zoveel uit.

Bij routeren/navigeren kijkt de software naar de wegen, eventueel kan het (zwaar) meewegen dat een weg in een fietsrouterelatie zit. Dan maakt het dus ook niet uit waar de wegen in zitten, als ze maar ergens inzitten.

Planners: er is 1 planner in ontwikkeling (best ver maar nog niet opgengesteld) die via het knooppuntennetwerk in OSM plant. Volgens mij vertaalt die alle subknooppunten naar aparte knooppunten, en alle connecties daartussen naar aparte routetjes. Zolang de omzetcode er wijs uit kan worden, werkt dat allemaal.

Knooppuntnet werkt op precies dezelfde methodiek als de planner en kijkt of hij er wijs uit kan worden. Zo niet, dan rapporteert hij een fout.
Omgekeerd is de eis dus: Als Knooppuntnet geen fout rapporteert dan is het goed.

Welke logika of stijl je daarbij hanteert doet er eigenlijk niet toe!

Dus het gaat meer om niet-technische kriteria.

  • Is het onderhoudbaar, hoe makkelijk/bewerkelijk is dat
  • Is het begrijpelijk ook voor anderen, om het taggen te leren (in mijn woorden: Kan ik het uitleggen?)
  • Is het begrijpelijk en eenduidig genoeg voor softwaremakers? (Wederom: Kan ik het uitleggen?)
  • Hoe groot is de kans dat het “beschadigd” wordt door toevallige mappers?

Ik denk: hoe simpeler hoe beter.

33

25 is bewust zo gedaan omdat - zoals ik al eerder gezegd heb, het erom gaat dat een bepaald stukje weg gekenmerkt wordt als onderdeel van het fietsknooppuntnetwerk. Tot dusver maken de planners geen gebruik van de routes zelf, alleen van de wegen, die gemarkeerd zijn door een of meer rcn routes.
En verder krijg je het eenvoudig weg niet voor elkaar om alle stukjes weg bij 25 door één route te laten rijden, dus zoek je uit welke route het ene deel kan doen en welke het andere.
En het zijn niet twee methodieken, maar een en dezelfde, rondbreien.

Net andersom de terugrichting doet de meeste knopen, de heenrichting stopt bij de eerste knoop.

34

O ja. Toch weer misgekleund!

Er is binnenkort dus dé enige OSM knooppuntplanner, die echt de knooppunten en de routes gebruikt. Ik weet de techniek niet precies, maar volgens mij ‘vertaalt’ hij alles eerst naar allemaal losse knooppunten en routes daartussen. De nummers doen er dan niet veel meer toe, die dienen om de gebruiker te plezieren want die willen dat in hun lijstje zien.

Als je kijk naar een los verbindinkje in een cluster subknopen, dan is de eis denk ik, dat het ergens in een van de rondgebreide routes voor moet komen, en dan komt het goed in de planner.

35

Wat ik als volgende graag zou doen is een twee op elkaar lijkende muliti-punten, die nu met de tentakelmethode getagd zijn, herzien. De ene met de rondbreimethode, en de andere met de tussenstukjesmethode. Die wil ik dan op dezelfde punten vergelijken als bij de vorige test, en dan ook met elkaar.

Weet iemand toevallig twee van zulke punten, liefst dicht bij elkaar? Punten dus die nu tentakel zijn dus die we zowizo willen verbeteren?

36

Er zit een hele lastige in het centrum van Rotterdam, 68, die is ook met rondbreien niet goed op te lossen.
En verder moet je in het centrum van Rotterdam maar eens snuffelen, 60 bijv. is ook een lastige, ik weet niet of die nu rondgebreid is.
En vlak bij 68 heb je 37 en 69, daar lijken zo op een eerste blik de tentakels nog hoogtij te vieren
https://cycling.waymarkedtrails.org/#?map=16!51.9169!4.488

37

68 was gedaan met de rondbreimethode, die heb ik nu omgezet naar de … ja, hoe noem je dat eigenlijk? Clustermethode? Want hij maakt eigenlijk een clustertje van verbonden knooppunten met allemaal hetzelfde nummer, en de aansluitende routes landen ergens op het cluster en de terugweg vertrekt ergens op het cluster, kan hetzelfde punt zijn maar kan ook verschillen.

Als er binnen het cluster eenrichtingsstukjes zitten of een stukje past niet in 1 rondje of sliertje, dan moeten dat aparte routerelaties worden. Alle clusterverbindingen die in 1 rondje of sliertje passen en twee kanten op bereden kunnen worden, kan je 1 relatie zetten.

Knooppuntnet verwerkt dit goed, de analyse geeft geen fouten en de planner plant goed over het cluster heen, van alle omringende nummers naar elkaar en ook omgekeerd. (Handig, die omkeerknop in de planner!)

JOSM is lastiger. Je kan de relaties precies zo maken als je wil met een gespleten eindje voor als de heenweg op een ander punt landt dan de terugweg begint. Maar zoals Dick al zei, dan is het continuïteitslijntje fout! Soms doet hij het goed, soms laat hij bij een toch echt goed ingevoerde sliert bij elk stukje een onderbreking zien. Dus ofwel ik snap nog niet goed hoe het werkt, ofwel er zit een fout of technische onmogelijkheid in JOSM hoe hij dat lijntje “berekent”.

Als het een fout is, dan meld ik dat bij JOSM aan en ga pas verder met deze methode testen als het in JOSM goed werkt of in ieder geval uitzicht geeft op verbetering. Anders kan je dit gewoon niet vlot doen.

Wat is beter?
Ik kan bevestigen dat alles beter is dan de tentakelmethode!
Voor zaken waar de rondbreimethode geen goede oplossing heeft, heeft de clustermethode ook geen oplossing. Er is dan namelijk geen redelijke verbinding tussen bepaalde clusterpunten. De clustermethode accepteert dat gewoon, en de rondbreimethode noemt het een fout of probleem. In de praktijk maakt dat voor een planner en voor de fietser geen verschil. Op de weg is de doorsteek niet aangegeven. De planner zoekt een omweg, en de fietser moet dat volgen of illegaal doorsteken.

Is clusteren nou handiger dan rondbreien (even ervanuitgaand dat het JOSM-lijntjes-probleem opgelost kan worden)?

  • Als ik naar waymarkedtrails kijk, die laat de routes zo mooi oplichten, dan is de clustermethode voor niet-ingewijden beter te begrijpen, omdat er niet al die overlappingen inzitten. Wél ingewijden kunnen bij de rondbreimethode beter zien hoe de continuïteit over het kruispunt heen is.

  • Als ik naar de knooppuntnet planner kijk, dan is er geen verschil.

  • In de OSM fietskaartlaag is er wel verschil, met name dat er bij de clustermethode bij elk lijntje maar 1 routeref staat, terwijl de rondbreimethode en de tentakelmethode een hele reeks van routerefs staat.

  • Voor gewoon fietsrouteren met voorkeur voor knooppuntverbindingen, ik kan dat niet testen maar met beide methoden zijn dezelfde stukjes weg onderdeel van minstens 1 knooppuntroute dus dan zou het resultaat precies hetzelfde moeten zijn.

38

Aangepast in mijn postje hierboven. Ik kom steeds dichter bij een bruikbare tekst voor aspirant knooppuntmappers.

39

Dat is denk ik hoe de Knooppuntnet planner het doet. Als alle mogelijke connectiviteit in de routerelaties moet worden opgenomen, zijn er geregeld punten waar dat domweg niet kan zonder bijkomende takjes in de relaties. Dat zou je dan ook we weer kunnen gaan beschrijven en toestaan in de editors en checkers, maar dan maak je het moeilijker in plaats van makkelijker.

40

Ik geef onmiddellijk toe dat de tentakelmethode behoorlijk ingewikkeld kan worden bij veelvuldig gesplitste knooppunten. En de uitleg op de wiki is ook niet ideaal, ik zou met wat simpeler voorbeelden/plaatjes beginnen. Maar wat wordt nu de alternatieve instructie om gesplitste knooppunten aan te pakken?

Bij een relatief simpel geval als dit knooppunt 75 (drie routes, een daarvan loopt over twee eenrichtingsfietspaden) blijft de tentakelmethode nodig? Of kun je hier rondbreien? Hoe dan?

Wanneer begin je met rondbreien? Bij drievoudige splitsing, vier, vijf? Dan heb je soms meerdere rondjes zoals in Leeuwarden hierboven. Welke route krijgt dan welk rondje cadeau? Wanneer kies je voor welke methode: rondbreien, tentakel, cluster?
En heb je soms zowel clusters als rondbreien nodig bij een knooppunt?

Ik ben bang dat de nieuwe instructies zo mogelijk nog onbegrijpelijker worden dan de oude. Voor simpele gevallen zal het misschien meevallen, maar daarna wordt het al gauw: het hangt van de situatie af, zie maar wat handig lijkt.

Als de enige eis is dat iedere wegdeel waar in werkelijkheid een route overloopt, in een route opgenomen is, zijn we bijna weer terug bij de ouderwetse methode: zet gewoon rcn=yes op het wegdeel en laat de gebruiker maar verzinnen hoe de route waarschijnlijk loopt.

Bovendien raak je steeds verder van de werkelijkheid verwijderd: er staan geen bordjes van 68 naar 68, je begint na je aankomstpunt de bordjes naar een volgend knooppunt te volgen. Er bestaat dus geen route 68 <-> 68. Hoe voorkom je dat een gebruiker denkt dat zo’n route echt aangegeven staat? route=virtual?
Expected_XXn_relations in OSM klopt ook niet altijd meer met het werkelijke aantal routes bij een knooppunt, door die fanatasieroutes.

Daarnaast is het natuurlijk onzinnig om te eisen dat de tentakelcontrole van knooppuntnet geen fouten oplevert als je de nieuwe aanpak gebruikt. Dan moet de controle natuurlijk gebaseerd zijn op de nieuwe aanpak. Zal ik anders vragen of vmarc gewoon alle controles uitzet, dan krijg je gegarandeerd facts: 0, en is het hele taggingprobleem ook opgelost :wink: