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:
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
Het staat me niet zo bij Matthijs
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.
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
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
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.
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.
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.
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.
Dat is wel heel precies… ik heb zulke doorsteekjes heel erg vaak gezien, als je die allemaal heel precies wil doen dan heb je een hoop extra werk. Volgens mij wordt het er dan niet duidelijker op. Ook in de gaten houden dat we een model maken, niet de precieze werkelijkheid op de vierkante meter.
Dus je blijft altijd precisie afwegen tegen de toegevoegde waarde voor de gebruiker, en je blijft altijd de keuze houden welke intersectie je precies als knooppunt kiest om zo dicht mogelijk bij het paaltje te blijven en tegelijk zo duidelijk mogelijk de richtingen aan te geven voor alle mogelijke routes in twee richtiingen.
In dit geval gaan menselijke fietsers er geen moeite mee hebben om het juiste doorsteekje te kiezen, lijkt mij. Ik denk als het er niet was dat een hoop vanzelf al over het gras zouden gaan… Stel dat er in de toekomst zelfrijdende fietsen komen dan wordt het anders. Dan kom je hier niet mee weg.
Wat er gedaan moet worden is de ene 45 verschuiven naar het stukje fietspad en de route 45-46 over het stukje fietspad leggen en dan de Burstumerdyk op.
Als je met straatkijk kijkt, dan zie ook dat de bordjes zo staan.
Ik heb het nu ook zo aangepast
En ja, je moet wel de fietsroutes aanhouden, dus voor mij moet het ook precies en dat is nu een van de punten waar ik al vaker tegenaan loop, sommige kruisingen zijn zo complex dat dat een hele toer wordt.
Hoewel het anderzijds niet nodig is om alle mogelijkheden aan te geven, er zijn soms zaken, die wel mogelijk lijken of zijn, maar toch niet zo goed passen. Je hoeft op de kruising Burstumerdyk/Tjallinga geen knooppuntnetwerk te leggen. Best mogelijk dat strikt geredeneerd fietsers daar mogen komen, maar raadzaam is het zeker niet.
Het fietspad langs de rotonde is een G12a en de discussie, die je kunt voeren, geldt dat verplicht zijn nu alleen voor de rotonde zelf of ook voor de aanliggende wegen? Het lijkt erop dat de wegbeheerder heeft gevonden dat je vanaf de rotonde naar de Burstumerdyk en de Tjallinga via dat fietspad moet rijden, maar komend vanaf Grou voert de kortste route naar de Burstumerdyk gelijk de Tjalliga op en dan de Burstumerdyk. Alleen is dat een gevaarlijke route en een stukje door over de rotonde en dan links het fietspad op is wat minder gevaarlijk, maar ook niet fijn
Heb jij een andere straatkijk dan ik? Het onderste knooppunt staat op WMT nu juist niet waar het echt staat. Fietsers van 46 naar 30 moeten nu een hele rare hoek maken, terwijl het paaltje rechts voor ze volgens mij rechtdoor wijst. Er staat een infobord bij dus het is echt een knooppunt.
