Wikipagina over node networks

Ah, goed punt inderdaad, dat geval had ik nog niet eens bedacht. Lijkt erop dat dat idd ook gewoon goed gaat, ik zal daar in de code ook meteen nog even een testcase voor toevoegen zo.

Inmiddels heb ik het sorteren ook werkend (mits ik geen bijwerkingen tegenkom). Daar heb ik een vergelijkbaar principe toegepast: Sorteren doet ie in feite door zomaar ergens (eigenlijk net iets slimmer dan dat) te beginnen en ways aan te sluiten tot ie niet verder kan, en dan de andere kant op ways aan te sluiten tot ie niet verder kan. Als ie een oneway member tegenkomt, gaat ie eerst de ene tak maken, totdat ie een punt tegenkomt wat een merge zou kunnen zijn, dan gaat ie de andere tak maken (vanaf hetzelfde beginpunt als de eerste tak), totdat ie het mergepunt vind, of niet verder kan.

Als ie bij het maken van de ene tak op een gegeven moment niet verder kon, hielt ie gewoon op. Met mijn wijziging gaat ie proberen om toch de andere tak nog te maken, zelfs al weet ie dat ie niet op het merge-punt gaat aankomen (en dan krijg je dus twee open eindjes, precies wat je wil).

Ik vermoed dat er wel een kans is dat dat mis gaat (bijvoorbeeld als het splitspunt eigenlijk twee splitspunten is, dus als je twee “open eindes” hebt met in het midden 1 common node, ipv een common way ertussen, dan kan het zijn dat ie de ways “kruislings” sorteert (OTOH heeft de sorter geen idee welke “beginpunten” bij elkaar horen, dat zou je wellicht in kunnen bouwen, maar dan moet JOSM ineens wel veel meer weten van de inhoud van de tagging).

Nou, ik had soms het idee dat het sorteren zowizo vaker misgaat dan goed… maar dan heb ik het vooral over hele lange wandelrouterelaties. Voordat je die in hun geheel goed sorteerbaar hebt ben je behoorlijk lang bezig!

@Matthijs Kooijman Kan ik jouw code testen op een paar echte relaties?

@dvdhoven Kan jij hier wat mee?

Nu ik de rondbreimethode eenmaal snap, zie ik dat die voor de meeste situaties “vanzelf” de juiste oplossing geeft.

Die eenvoud van instructie en de handige weergave in wmt heb ik voor de clustermethode nog niet gevonden.

Of een duidelijke instructie van “in dit geval doe je rondbreien en in dat geval clusteren”.

Als er een instructie komt die dat idio^H^H^H^Hlastige punt met 7 x 24 aankan dan gaat de vlag uit!

Ja! Ik heb mijn [PR](https://github.com/openstreetmap/josm/pull/61) net nog weer geupdate met alle wijzigingen wat opgeschoond (en testcases toegevoegd). Een build van de laatste versie heb ik hier geupload:

https://www.stderr.nl/static/tmp/josm-pr61-58b4eb415.jar

Ik kan deze runnen (na downloaden) met java -jar josm-pr61-58b4eb415.jar op de commandline, wellicht dat dat op jouw systeem hetzelfde werkt.

Update: PR is inmiddels gemerged, dus met de josm-latest versie (en in de toekomst de josm stable versies) vanaf r16886 kun je dit gebruiken.

Hm, intuitief zou ik zeggen dat rondbreien juist lastiger en onoverzichtelijker is, omdat je makkelijker een stukje vergeet, of een stukje meeneemt dat eigenlijk niet in de route hoort. OTOH kan ik me wel voorstellen dat het in de meest gangbare gevallen wel vanzelf een goed resultaat oplevert. Nou moet ik toegeven nog niet echt knooppunten in de praktijk te hebben aangelegd (ooit wel eentje per abuis vernaggeld, misschien weet @dvdhoven dat nog wel :-P), dus wellicht moet ik me er niet teveel mee bemoeien :slight_smile:

Het staat me niet zo bij Matthijs :slight_smile:
Rondbreien werkt gewoon het fijnst, stukjes vergeten is er niet bij, want dan klopt de routelijn niet en stukje buiten de route, daar kan ik me niet zoveel bij voorstellen. Je moet gewoon een kruising of een rotonde over en het kan soms lastig zijn om een goede route te vinden.

Die plannner is wel een hele grote hulp, je kan van alle omliggende punten naar elkaar plannen en de omkeerknop gebruiken, dan kan je de aansluitingen perfekt zien. Als er eentje niet klopt dan plant hij hem via Verweggistan-aan-zee, dat kan je niet missen!

Ik heb als “rotondetest” Fkp 45 bij Grou herzien. Het is een rotonde met drie wegen met aan twee kanten fietspaden. Twee wegen en de hele rotonde hebben dubbelzijdige fietspaden. Eén weg heeft enkelzijdige fietspaden tot aan de rotonde.

Er zijn drie knooppunten 45. Twee routes zijn dubbelzijdig en landen/vertrekken elk op een deelknooppunt. De derde route landt op 1 deelknooppunt en vertrekt van een ander.

De tagging was een mengeling van tentakels en rondbreien, waarbij de rotondestukjes in 1-3 routes voorkwamen. Niet alles werd goed in beide richtingen gerouteerd.

Ik heb nu de drie deelknooppunten in een kringetje om de rotonde heen verbonden in een aparte ‘cluster-route’, en alle rotonde-stukjes uit de drie afzonderlijke routes gehaald. Ze landen/vertrekken nu dus op het dichtstbijzijnde deelknooppunt, en elk stukje route komt maar in 1 relatie voor.

Zie https://cycling.waymarkedtrails.org/#?map=18!53.0916!5.8257
Even op Routes klikken en dan het pijltje over de routelijst laten gaan, dan zie je hoe het nu zit.

Ik denk dat ik wel een voorbeeld zou kunnen construeren, maar ik vermoed dat dat dan misschien niet meer lijkt op een echt kruispunt (Anders gezegd: Dat de methode in praktijksituaties wel (nagenoeg) altijd goed werkt), dus laten we het er verder niet over hebben :slight_smile:

Ziet er wmb goed uit, lekker overzichtelijk met elke way maar in 1 route. Dit zou wat mij betreft wel de aanbevolen methode mogen zijn.

In ander nieuws: Mijn PR aan JOSM is inmiddels gemerged, dus met de nightly build (josm-latest) vanaf r16886 kun je deze verbetering nu al gebruiken.

Ik heb meteen even getest op het knooppunt 45 bij Grou, de gesplitste relatie 30-45 werd al goed getekent omdat de splitsing onderaan zit, maar als je hem reversed wordt ie nu met josm-latest ook goed gerenderd. Sorteren van de relation gaat nu ook goed, onafhankelijk van de beginvolgorde.

Mocht er iemand nog een andere (knooppunt)route tegenkomen die met deze nieuwe versie nog niet goed weergegeven of gesorteerd wordt, laat het me dan vooral weten (evt in een nieuw topic of privébericht), dan kan ik kijken of dat ook nog op te lossen is (of ik kan er iig in Josm een bugreport en testcase voor toevoegen zodat het in de toekomst opgelost kan worden).

Alleen geeft knooppuntnet.nl nu een foutmelding overbodige segmenten op route 45-45 en die wil ik asap weg hebben.
Alsjeblieft, please ga knooppuntnet.nl niet vervuilen met eeuwige foutmeldingen.
Wat mij betreft, terug naar de oude foutloze situatie.

Ik begrijp echt niet waar dit voor nodig was. Alles was goed en nu zitten we weer met een foutmelding

Toptoptop, @Matthijs!

Ik ben nog een beetje terughoudend, want tot nu toe heb ik niet de moeilijkste dingen gedaan. Met name als er eenrichtingsstukken op het kruispunt zitten ben ik er niet zeker van of je het eenvoudig kan houden en tegelijk alles goed routeerbaar van alles naar alles met de juiste route over het kruispunt.

Ik heb vmarc gevraagd of Knooppuntnet een probleem heeft met dit schema. In de planner zie ik geen probleem, maar de analyses heb ik op dit punt nog steeds niet helemaal door.

Het lijkt me ook goed om even goed te kijken naar de analyse die knoppuntnet.nl uitvoert. Is de foutmelding die gegeven wordt terecht, of moeten de checks van knooppuntnet herzien worden? Dan is het met name de vraag wat de onderliggende voorwaarden zijn die je aan je netwerk wilt stellen.

In dit geval lijkt het me dat er, volgens knooppuntnet een stuk van de 45-45-route uit kan, omdat je nu op twee manieren van elke 45-node naar de andere kan (linksom en rechtsom) en dat is volgens knoopuntnet overbodig. Je zou dit misschien kunnen oplossen door:

  • alle members role=forward te geven, maar dan zou je forceren dat je altijd de rotonde linksom rijdt en als ik het goed zie is deze rotonde voor fietsers twee-richtingsverkeer, dus dan zou je een onnodig lange route krijgen.

  • de 45-45 route op te splitsen in 2 of 3 losse routes, maar dat is IMHO weer minder overzichtelijk.

  • één segment van de route (tussen 2 subknooppunten, maakt niet uit welke) weg te laten. Route-connectiviteit blijft gewaarborgd, maar dan krijg je niet de altijd kortste of aangegeven route. Nu is de “aangegeven route” uberhaupt niet haalbaar omdat je daarvoor informatie mist (tenzij je de tentakelmethode gebruikt om echt alle routes in te voeren zoals aangegeven), maar meestal zal de kortste route ook de aangegeven route zijn.

Misschien dat de laatste optie wel een hint geeft naar wat er nou mis gaat: Er zijn inderdaad meerdere routes tussen de verschillende subknooppunten, afhankelijk van waar je precies vandaan komt en heen wilt zijn andere stukken de kortste. Wellicht dat knooppuntnet dat zou kunnen doen: Plan een kortste route van alle knooppunten naar alle andere knooppunten binnen de route, en markeer alle ways waar je dan overheen komt als “used”. Ik vermoed dat ie dit nu doet maar alleen met routes tussen wat ie als start node(s) en end node(s) heeft gemarkeerd. Sterker nog, wellicht is dat eigenlijk het probleem: Deze route heeft geen aparte start en end nodes, alle nodes kunnen start of end zijn.

Hoe dan ook: ik bedacht me dat het wellicht te overwegen is om dit soort “intra-node-routes” nog apart te taggen. Het zijn eigenlijk bijzondere “virtuele” routes, omdat ze niet echt een route op zichzelf zijn, maar overbruggingsroutes tussen andere echte node routes. Dat feit kun je nu afleiden uit de ref (als die nn-nn is ipv nn-mm), maar dat is niet echt heel robuust, en ook niet altijd waar (er zijn blijkbaar ook rondes van een knooppunt terug naar hetzelfde knooppunt, die echt anders zijn: https://github.com/vmarc/knooppuntnet/issues/2)). Dus een expliciete (extra) tag zou kunnen helpen, ook om bijv knooppuntnet en andere routers meer inzicht te geven in hoe deze routes te gebruiken.

@Dick Ik snap dat je je zorgen maakt als je foutmeldingen ziet waar ze eerst niet waren, maar dat knooppunt routeerde eerst niet alles goed en nu wel, dat vind ik dan toch belangrijker. Ik snap ook dat jij vindt dat jouw methode prima werkt, dat doet-ie ook en ik heb daar respekt voor, nu ik het eenmaal doorheb!

Tegelijk merk ik wel dat het voor anderen bijna net zo lastig te begrijpen is als het tentakelgebeuren.

Het rondsluiten van het clustertje geeft denk ik de foutmelding, ik zal even kjken of ik dat kan verhelpen zonder het ingewikkelder te maken. vmarc heeft het nu druk en dit is niet urgent, maar in de toekomst zou hij misschien een rondsluitertje kunnen toestaan zonder “feit”.

Er zijn geen feiten meer. Het kwam door het rondsluiten. Ik heb de rotonde nu in twee routetjes gezet. Voor nu is de regel dus: je mag de verbindingsroutes in je clustertje kombineren, maar ze moeten a. 1 aansluitende keten vormen, en b. niet rondgesloten zijn. Dan werkt het met de huidige checks van Knooppuntnet samen. PS ik gebruik alleen nog de nieuwe versie, binnenkort komt die voor iedereen beschikbaar.

Bedankt! :slight_smile:

Dat zou het ingewikkelder maken ipv makkelijker. De Knooppuntnet Planner behandelt nu alle knooppunten en verbindingen (na het parsen) hetzelfde, het gaat er alleen maar om of de verbindingen ergens instaan (en nog een paar ‘kleinigheidjes’, zoals toegang en eenrichting). Aangezien dat vooralsnog de enige OSM-knooppuntplanner is is die maatgevend voor wat er nu kan!

Ik denk dat het niet heel moeilijk is om een rondgesloten clustertje te detecteren en goed te keuren op voorwaarde dat alle nummers gelijk zijn, maar ik wil daar niet op vooruitlopen. Ook ik vind dat we moeten werken met wat er nu is, en het foutloos tevredenstellen van het knooppuntnet checker is heel belangrijk voor het onderhoud.

Het moet ook geen doel zijn om alles wat al werkt anders te gaan doen, dat zou zinloos zijn. Dit is een optie voor nieuwe kruispunten of voor plekken waar andere methoden niet of heel moeilijk (dus foutgevoelig) uitkomen. Dit proefpunt had ik uitgekozen omdat het niet van alle kanten goed routeerde, en ik kon met streetview goed zien dat alle stukjes fietspad langs de rotonde tweerichting zijn.
Een rotonde met eenrichtingsstukken, daar zoek ik nog een vergelijkbare uitdaging voor waar het nu niet goed gaat of totaal onbegrijpelijk is.

Dit komt bij mij heel raar over.
Er is maar 1 knooppunt, dus ook maar 1 relatie [45-45], met alle onderdelen (ways) van het knooppunt.

Ik zou het dus samenvoegen tot 1 relatie.

Een knooppunt kan over twee rotondes (kruisingen) gaan dan behoort alle wegen van de kruising en tussen de kruisingen tot de relatie.

Dat gaf ik eerder al aan, logisch is 1 knooppunt = 1 relatie. Hier 45-45.

Volgens mij is hier helemaal geen sprake van een gesplitst knooppunt. Als ik goed op GSV kijk, zie ik rond de rotonde geheel andere routes dan op OSM. Helaas mogen we deze informatie niet gebruiken om OSM te bewerken, en vind ik ook geen beelden op Mapillary. Ik zal hier verder geen ‘verboden’ informatie plaatsen, om iedereen zelf de keuze te laten al dan niet zulke informatie te bekijken.
Naar mijn idee is hier eerst een survey nodig.

Ben ik met je eens, maar op dit moment geeft dat een vervelende fout. Ik vergelijk het met de situatie waar via de tentakels die stukjes in verschillende afzonderlijke routes opgenomen zijn, en dan vind ik het met twee clusterroutetjes al beter. Zodra het in 1 relatie 45-45-45 kan zonder fouten te genereren zal ik dat ook doen.

Op zich moet de checker niet de tagging bepalen, maar het is geen dringend probleem, ik ben nog maar aan het testen, en we kunnen het best eerst even afstemmen.

Goed punt! Ik heb aangenomen dat de bestaande informatie juist was, en die alleen op een andere manier gearrangeerd in de routes. Ik heb wel gecontroleerd waar de fietspaden eenrichting of tweerichting zijn: de gehele rotonde is inderdaad tweerichtingfietspad.

Nog een keer kijken… ik zie in mei 2018 de paaltjes wel staan bij de logische knooppunten! Die ene vlak bij het water is wel een beetje verborgen in het riet.
Survey hoe het nu is kan geen kwaad, maar voor mij is dat ietsjes te ver weg.

Na opmerking van aplhensebezorger
Bij tweerichting fietspaden.
Zou eigenlijk dit stuk way fietspad ook bij de relatie behoren knooppunt 45-45
https://www.openstreetmap.org/way/200574749
evenals https://www.openstreetmap.org/way/279084738
https://www.openstreetmap.org/way/6491983
en die ene 45 verschoven naar https://www.openstreetmap.org/node/2105432530

Dus waarschijnlijk moeten er nog meer ways aan de relatie toegevoegd worden.
Dat punt beslist men welke volgende knooppunt nummer ze nemen.
Omdat fietsers, ook dat stukje fietspad gebruiken. Kortste route.

Totaal 3 nodes met 45.