Wikipagina over node networks

Communities Nederland (Netherlands)
41

Deze heeft zeker geen tentakels nodig.

Rondbreien:

  • de heenweg van 23-75 landt op de onderste 75, de terugweg begint daar ook en gaat via de bovenste 75 terug.
  • 66-75 en 67-75 pakken het stukje 75-75 er aan hun eind bij.

Klopt toch, Dick?

23-75 eindigt nu met een gespleten eindje, JOSM vindt dat goed en Knooppuntnet ook. Voor helemaal rondbreien zou 75-75 erbij moeten.

Ik denk dat het in de planner werkt, als 75-75 maar in 1 van de drie routes zit, boeit niet welke. De uitvoer van de planner laat in alle gevallen waar je beide paaltjes passeert, twee keer het nummer 75 zien. En dat klopt precies, je komt twee keer langs 75. Dat zou in de output misschien wel aangegeven kunnen worden, dat het om 1 knooppunt met verschillende paaltjes gaat.

De clustermethode zou hier 75-75 als een aparte relatie aanmaken.
23-75 blijft dan zoals nu, met gespleten eindje.
Het stukje 75-75 kan weg uit 66-75 en 67-75

Dit was op de wikipagina mijn volgende voorbeeld geweest.

42

Zo erg is het denk ik niet… de rondbreitechniek voorkomt dat je tentakelfouten krijgt, het is niet strijdig. De tentakels blijven gewoon geldig.
De clustermethode idem. Ze eisen geen nieuwe controles, maar maken slim gebruik van de bestaande controles.

Bij mijn testen had ik veel aan knooppuntnet, die gaf genadeloos alle fouten als feit terug.

43

Dat zijn goede vragen. Om dat te kunnen beantwoorden doe ik nu die testjes, zodat ik in de praktjk als beginner wb heen-en-weer fietsrelaties zelf tegen de dingen aanloop. Daarna begrijp ik pas wat anderen al die tijd al zeiden. Ik ga er zomaar vanuit dat als het bij mij niet meteen landt ook niet als ik de wiki’s lees, dat bij anderen ook het geval is.
Hopelijk levert dat een bruikbare handleiding op waar we allemaal achter kunnen staan en die aangeeft wat er allemaal kan en wat je in welk geval het beste kan doen, of dat het een kwestie van persoonlijke voorkeur is.

“Het hangt van de situatie af en suk6 ermee!” dat is natuurlijk zo, maar ik denk dat heel wat af te vangen is met de beschikbare technieken. Het hoeft elkaar niet te bijten en ik kan mee voorstellen dat sommige punten zo ingewilkkeld zijn dat je een kombinatie van de technieken gaat gebruiken. Bijvoorbeeld zo’n knooppunt met 6 keer 25, als het nu werkt moet je er vooral niet aankomen, maar zo’n situatie kan je misschien vereenvoudigen door een aantal 25’s te clusteren en de rest rond te breien.

NB ik praat nog steeds vanuit mogelijkheden verkennen, ik ben nergens speciaal op uit behalve het hanteerbaar, begrijpelijk en overdraagbaar maken.

44

Okee, ik weet nu hoe JOSM het ziet.

Knooppunten (nodes) in de routerelatie doorbreken de continuiteitslijn. Dus die moeten er niet inzitten, hoe handig het ook lijkt, en dat geldt voor alle methodieken.

Verder, de eindjes van routes mogen gesplitst zijn in de routerelatie, maar het begin niet. Er moet minstens een punt gemeenschappelijk zijn: dat is het splitspunt en wordt in de rest van de routerelatie als referentiepunt gebruikt. Ook dit geldt voor alle methodieken, maar in de “rondbreimethode” kan dit dus niet voorkomen.

68 was een gesplitst punt. Route 68-72 begint bij 68. Dan zou die in de clustermethode een gesplitst begindeel hebben, en dan krijg je de methode wel goed, maar de continuity line van de terugweg in de relatie-editor is bagger, daar heb je dan niks aan.

Met de rondbreimethode was het probleem eigenlijk hetzelfde: de 68’s liggen wel dicht bij elkaar, maar er is geen doorsteek, je moet een heel stuk om als je die wil verbinden. 72 is trouwens ook een gesplitst punt, dus eigenlijk zijn de heen- en terugweg volkomen los van elkaar. Dat levert bij alle methoden een probleem! Dus het wordt, inderdaad AlphenseB, kijken hoe je het rondkrijgt! Maar het helpt om te weten hoe de tools werken.

In dit geval werkt het dus allemaal prima, alleen de continuity lijn in de editor is niet goed.

72 was heel makkelijk door te verbinden, en als ik dan de relatie omkeerde was de continuity line goed. Verplichte volgorde hebben we een tijdje geleden losgelaten, dus dit is een mogelijke oplossing voor dt geval.

Om het ook voor JOSM goed te doen en ook nog de volgorde laag-hoog te houden kan je niet anders dan de 68-jes naar elkaar door te verbinden. Toevallig zat het derde 68-punt in het midden, dus heb ik daar de heenweg laten beginnen en ook de terugweg laten eindigen. Dat werkt ook en levert geen continuityfout meer op, terijl 72 een gesplitst eind houdt.

Kortom, hij is nu inderdaad een mengsel van rondbreien en clusteren.

https://cycling.waymarkedtrails.org/#?map=18!51.9181!4.4944

45

Goede discussie, dit! Ik ben toevallig net terug van twee weekjes fietsvakantie en kwam wat dubbele knooppunten tegen die met verschillende methodes gemapped, dus ik was van plan om daar eens naar te vragen hier, maar dat is nu niet meer nodig :slight_smile:

Maar is dit dan eigenlijk niet een bug of ontbrekende slimheid in JOSM? Ik zie idd dat wanneer je het beginpunt van een rondgebreide route weghaalt, dat het een bende wordt, maar in principe zou JOSM moeten kunnen uitvinden hoe het zit en netjes laten zien. Als ik het goed begrijp is de rondbreimethode eigenlijk alleen maar nodig omdat JOSM anders niet netjes laat zien dat het klopt, voor de kaart zelf heeft het geen toegevoegde waarde boven de clustermethode (sterker nog, de rondbreimethode is eigenlijk complexer en lastiger uit te leggen, denk ik). Zou het dan niet beter zijn om dit in JOSM te fixen? Het in de kaart fixen neigt een beetje naar taggen voor de render (of editor in dit geval)?

Iemand een idee of dat al bij JOSM gereport is? Ik heb net hun bug reports even doorgekeken, maar nog niets kunnen vinden.

Hier kun je een vergelijkbaar argument maken. Hierover is overigens wel een bug report bij JOSM: https://josm.openstreetmap.de/ticket/18645

46

Wat betreft de wikipagina zelf, ziet er goed uit. Is de bedoeling van deze pagina om de NL/BE netwerken te documenteren? Of globaal? Ik ben toevallig recent in Zwitserland ook wat van hun Wanderwege aan het taggen geweest, wat eigenlijk een wandelroute node netwerk is en misschien ook als node network gezien kan worden (ze taggen op dit moment nog niet met network:type=node_network, zie http://overpass-turbo.eu/s/WIA ). Zie https://wiki.openstreetmap.org/wiki/DE_talk:Switzerland/HikingNetwork (ook de discussiepagina).

Kijkende naar de “Tagging principles” op de wikipagina, dan is eigenlijk alles van toepassing op het Zwitserse netwerk, behalve:

Dit is niet zo voor het Zwitserse netwerk, daar hebben nodes namen (die volgens mij meestal uniek zijn, hoewel er misschien soms ook meerdere rondom een plaats oid staan met dezelfde naam, dat weet ik niet zeker), of soms zijn ze naamloos (de signposts geven meestal meerdere bestemmingen aan, niet alleen de eerstvolgende, dus signposts geven richting naamloze nodes dan alle achterliggende benaamde signposts aan).

In het Zwitserse netwerk worden de signposts (met details over bestemmingen en afstanden) bij nodes vaak wel getagged, de kleinere markers tussen nodes niet. Of de signposts wel of niet in de route horen, daar is nog wel wat discussie over.

Verder wordt er bij routes expliciet een from en to getagged, en ze gebruiken note ipv ref voor een “from-to” beschrijving van de route.

De zaken onder “Integrity and maintenance” (en ook de rest van de wikipagina) heb ik nog niet goed gelezen en zullen wellicht (nog) niet helemaal van toepassing zijn, maar ik ben nu even door mijn tijd heen.

47

Ik heb de rest van de wikipagina (tot aan het stuk over split routes) in iets meer detail gelezen, een paar typos gefixt en nog een paar opmerkingen hieronder gezet.

Werd het tentacle model niet soms ook gebruikt voor knooppunten die gewoon uit 2 nabijgelegen kruispunten bestaan, waarbij de way tussen de knooppunten in meerdere routes opgenomen wordt? Zoals bijvoorbeeld hier? Of noemen we dat niet het tentacle model? Indien wel, is het wellicht ook goed om die situatie hier ook even te benoemen?

Hier mist volgens mij “m for mountain biking”? Bij “network” wordt wel “rmn” gedocumenteerd, iig.

Misschien moet hetzelfde gezegd worden voor “name”?

48

JOSM issues over de coninuiteitslijn zijn er wel, maar niet voor dit specifieke punt. Ik ben er niet zeker van of het wel kan. Hij heeft nu een splitspunt nodig om de twee richting-kettingen aan “op te hangen”. Hoe doe je dat anders? Ik zou het dus geen bug durven noemen, maar een verzoek voor verbetering, en dan zou ik voor mezelf de zekerheid willen hebben dat het theoretisch mogelijk is. Misschien kan iemand het in python voor elkaar krijgen? Tot die tijd is het voor mij een gegeven. En áls het een issue wordt, is het nog afwachten of iemand bij JOSM het oppakt. Tot die tijd is het ofwel verdragen dat de lijn nit goed is (en dat is echt heel erg lastig, heb ik gemerkt) ofwel rondsluiten.

Helemaal voor de editor is het niet, want het levert wel de connectviteit binnen het knooppuntcluster die je nodig hebt.

Knooppunten zelf nog een keer in de routerelaties opnemen is niet nodig, want ze zitten er al in! De eerste knoop van de eerste weg en de laatste knoop van de laatste weg zijn de knooppunten. We doen het soms als visueel hulpje voor de mapper. Dat dat niet ondersteund wordt kan je eigenlijk geen bug noemen. Je kan het vragen, maar ik zou het zelf geen prioriteit geven, hoewel ik zelf zo’n knooppunteninderoutezetter ben. Als ze het voor de guidepost knopen op gaan lossen dan kan dit in één moeite door. Maar tot die tijd zet ik overal de knooppunten lekker in behalve in de fietsroutes.

Ondertussen heb ik even gekeken naar Alphensebezorger zijn punt 75 in Rotterdam. Een gesplitste route landt daar op het ene punt 75, en de terugweg begint op het andere. Dus niet rondgesloten. Er is ook geen 75-75 routerelatie. Dus geen clustermethode! En toch werkt het, in alle toepassingen gaat t goed! Hoe kan dat?

Nou, het stukje 75-75 zit aan de twee andere niet-gesplitste routerelaties geplakt. Dat kan je in waymarkedtrails mooi zien als je ze mouse-overt in de routelijst. Daarmee is de connectiviteit in beide richtingen geregeld. De knooppuntnet Planner kan er dan ook van alle kanten goed overheen routeren. De omdraaifunctie in die planner is hier enorm handig voor!

Vervolgens, om de theorie te checken, heb ik één van die extra stukjes weggehaald. En inderdaad: zo’n stukje hoeft maar 1 keer ergens in voor te komen, dan werkt het gewoon nog steeds! Als ik beide extra stukjes weg zou halen, dan zou het niet meer werken, totdat er een aparte 75-75 bijkomt.

Dus in dit eenvoudige geval kan eigenlijk alles. En tot zover was ik gekomen met mijn wikipagina!

49

Het is in ieder geval niet de bedoeling om alle aangetroffen praktijken te dokumenteren. Ik denk dat hier komt te staan hoe wij het hier in NL afspreken, en ook het waarom van de keuzes. Eventueel met een paar opties.

50

Ik ben met een Duitse mapper in gesprek over hetzelfde systeem met knooppuntnamen ipv knooppuntnummers. Op de handwijzers staat per richting een rijtje bestemmingen, de bovenste daarvan is altijd de naam van het volgende knooppunt. Het werkt dus als een bushaltenaam, zeg maar. Op zich is daar geen principieel probleem mee, het is echt een knooppuntensysteem, maar de toepassingen zouden wel ietsjes aangepast moeten worden. Niks fundamenteels.

Ik heb hun voorgesteld een testje te doen, en op basis daarvan support van de toepassingen te vragen.

Uiteindelijk denk ik dat voor de nodes alleen de definitie van rXn_ref verruimd hoeft te worden (ook namen toegestaan).
From en to ondersteunen ipv ref=* in de knooppuntroutes, of nog eenvoudiger, lege ref toestaan als de knooppunten niet numeriek zijn.
De handwijzers zelf als aparte feature mappen precies waar ze staan, maar de intersection nodes zo eenvoudig mogelijk als network node taggen.

Ik heb een testje gedaan: rwn_ref= ingevoerd bij een knooppunt en de routes die erop landen. Waymarkedtrails toont gewoon de naam (die maakt van het knooppuntrondje een knooppuntellips). Knooppuntnet planner toont de naam niet volledig op de kaart en in de resultatenlijst, hij lijkt hem op 3 tekens af te kappen. De planfunctie trekt zich er niks van aan. Knooppuntnet Analyse vindt dat de routenaam niet past bij de knooppuntref.

51

Misschien goed om dat dat even bovenaan de wikipagina te zetten, dat dit in principe de Nederlandse conventies zijn, maar wellicht ook dat andere regio’s uitgenodigd worden om deze conventies over te nemen (en zo nodig iets te verruimen)? Wellicht kunnen we, als deze wikipagina voor NL helemaal klopt, de pagina eens bij wat andere communities naar binnen gooien ter inspiratie of adoptie (wat je nu al en beetje bij de Duitse mappers aan het doen bent denk ik). Het feit dat je in de pagina ook allerlei overwegingen en recente wijzigingen documenteert, maakt hem daar bij uitstek geschikt voor.

Je kan toch prima hetzelfde doen aan de bovenkant als wat er nu aan de onderkant gebeurt? Gewoon beginnen met twee eindjes die verderop weer samen komen? Het feit dat het onderaan wel goed gaat en bovenaan niet is vrij arbitrair en zou voor mij reden zijn het een bug te noemen (maar bug of feature request maakt uiteindelijk natuurlijk niet veel uit).

Ik zal binnenkort wel eens in de source van JOSM kijken hoe ze dit nu doen en hoe ingewikkeld het zou zijn om dit te fixen, kom ik op terug.

Dat is waar, maar dat kan ook (IMHO overzichtelijker) met de clustermethode (dus korte extra routes die de knooppunten met hetzelfde nummer te verbinden), toch?

Dat werkt idd, maar ik zou persoonlijik de voorkeur geven om ook in dit soort gevallen toch de clustermethode te gebruiken, om dat het veel eenduidiger is (immers, aan welke route moet je die extra 75-75 plakken?) en de kans is kleiner dat iemand het later per ongeluk stuk maakt (omdat het explicieter is dat er daar iets “geks” gebeurt).

52

Van de week reed ik over een verkeersknooppunt. Toen vroeg ik me af, wat behoort er nu tot het verkeersknooppunt, de wegen, ( de bermen, sloten), of wordt toch alleen de wegen bedoeld.
Waar zet je dan de naam op, maak je een relatie voor het verkeersknooppunt.

Later bedacht ik mij, dat is hetzelfde als een fietsknooppunt, wat behoort er tot een fietsknooppunt.
Dan vindt ik het niet zo raar, logisch, om het knooppunt te benoemen met een relatie.

Elke A-B-A route, kortste methodiek, rondgaand, zou daar op aansluiten, het knooppunt.
Men zou zo’n route kunnen kiezen. Dan verwacht je niet een langere methodiek, route.

Ik weet het, het is deels vaak vernoemd.

Het ging mij om het aspect, wat is logisch? Hoe zou een ander dat zien. Als je vraagt.
Wat behoort er tot een knooppunt?
Hoe rij je van A-naar-B-naar-A?

53

Mensen kunnen paaltjes die bij elkaar staan rond een rotonde of kruispunt goed als 1 knooppunt zien. Probleem bij fietsknooppunten is dat de paaltjes met hetzelfde nummer vaak een heel eind uit elkaar geplaatst zijn, buiten zichtafstand, soms op verschillende hoogten, en soms kan je van het ene niet eens bij het andere komen op een logische manier.

Mensen kunnen makkelijk denken “o, staat vlak bij elkaar dus het telt als 1, dus ik kijk even wat er op die andere staat”. Voor een planner is dat een verbinding die je gewoon moet leggen, want je kan dit niet fuzzy of met een afstandsregel oplossen (“alles binnen 50m is hetzelfde knooppunt” gaat heel vaak niet op, en “alles buiten 50 m is een ander knooppunt” ook niet.

Dus echt de routes tussen de paaltjes aangeven is echt nodig. Maar het is ook weer niet nodig om in elke route precies aan te geven hoe hij aansluit op elke andere route en op zichzelf.

Waar je altijd op moet letten is een/twee richtingen op de tussenstukjes. Bijvoorbeeld die 75-75, als je de gesplitste route daar rondbreit en je laat de andere twee op hun eerste 75 landen, dan is het tussenstukje 75-75 eenrichting want het staat alleen als terugweg met een rol. Dus daar moet 75-75 ofwel een zelfstandig routetje zijn, ofwel aan een van de twee ongespitste routes zitten.

Ik ga nu eens nadenken over een rotonde met fietspaden en 3 gesplitste routes. Die heb ik best vaak gezien, en dan met stukjes enkelzijdig fietspad en stukjes dubbelzijdig fietspad.
Hoe eenvoudig/eenduidig kan ik het oplossen?

54

Ok, dat was best ingewikkeld, maar het is gelukt om het probleem in JOSM te fixen. Nu moet nog blijken of dat geen onverwachte bij-effecten heeft op andersoortige routes en of de developers deze aanpak zien zitten…

Zie https://josm.openstreetmap.de/ticket/19633

55

Top! Dat is nog eens aanpakken!

Kun je in woorden of pseudocode vertellen wat het probleem was en wat jij nou anders doet in die fix?
En, ook best belangrijk, sorteert hij hem dan nog goed?

56

Voor het tekenen van die lijn gaat JOSM van boven naar beneden door de relation heen en kijkt ie steeds of de opvolgende ways wel aansluiten op de vorige (eventueel na het omdraaien van de richting). Wanneer JOSM een one-way member (dus met role=forward of role=backward) tegenkomt, begint ie een splitsing. De eerste way wordt de “linker” tak, bij de volgende ways probeert ie steeds aan te sluiten op de linkertak, of het splitspunt. Zodra ie een way tegenkomt die niet aansluit op de linkertak maar wel op het splitspunt, wordt dat de eerste way van de rechtertak. Zo gaat ie verder, ways steeds aansluitend op links of rechts afhankelijk van wat past. Zodra er een way is die op beide past, dan wordt dat het samenvoegpunt en gaat ie weer als 1 weg verder (mits dat geen one-way member is, en ik mis meer details, maar dit is het idee).

Het verschil zit erin wat ie doet als ie een oneway member tegenkomt dat niet op links niet niet op rechts aansluit. Oorspronkelijk brak ie dan altijd de splitsing af met een “not connected” markertje en begon ie een nieuwe splitsing. Met mijn wijziging doet ie het volgende. Als er een oneway member is die niet aansluit op links en er zijn nog geen ways in de rechter tak en de way sluit ook niet aan op het splitspunt, dan maakt ie er toch het begin van de rechtertak van. Vervolgens zoekt ie terug naar het splitspunt en haalt ie daar de marking “splitspunt” (isOnewayHead) weg, waardoor het in de interface niet als splitsing getekent wordt, maar als twee open takken. Verder is de afhandeling hetzelfde, dus alle ways daarna gaat ie normaal aan beide takken proberen te passen.

Het zou kunnen dat er situaties zijn waarin deze aanpak misschien gekke resultaten oplevert, maar in de oude situatie zouden die toch al “not connected” zijn, dus in principe zou het er voor geldige situaties niet op achteruit moeten gaan (maar als iemand nog een bepaalde relation weet waar deze aanpak iets geks zou kunnen opleveren, hoor ik het graag).

Ik hoop dat dit een beetje duidelijk is?

Nee, dat lijkt nu niet goed te werken. Daar ga ik nog even naar kijken, maar dat zou wel eens lastiger kunnen worden.

57

Duidelijk, en ten opzichte van de oude situatie lijkt me dat het verder geen verschil maaakt. Hij heeft begint altijd een tweede tak, zodra er een wegdeel niet past op de eerste way of het eerste punt. Dat houdt MI in dat ook de situatie waarin uiteindelijk helemaal geen common way meer volgt, ook klopt, je heb dan gewoon een sliertje links en een sliertje rechts. 68-72 in mijn proefknooppunt 68 is er zo eentje. Dus dat is meteen een mooi testmodel: ik haal 1 way weg en ik zie of het werkt.

58

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).

59

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!

60

@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!