Knooppuntnetwerken scheiden van routes?

Gewoon network:type gebruiken.
Het is altijd hetzelfde gez**k, altijd vindt iemand wel weer iets negatiefs. :rage:

En duidelijk of onduidelijk is totaal niet relevant in dit verband. Het is een technische tag, niet bedoeld om zichtbaar te zijn voor het publiek. Alleen voor insiders en tooling zoals knooppuntnet.nl
En tools vinden niets onduidelijk of duidelijk en insiders zijn zo gewend aan een bepaalde tag.

En tags gebruiken met een underscore erin moet je zowiezo niet doen, dan krijg je geheid ergens te horen, dat dat verouderd is.

Bytheway, ik heb al een preset gebakken waarmee je network:type aan een node en aan een rcn route kunt toekennen.

En bij het nieuwe rcn netwerk Kreis Kleve, zijn een groot deel van de routes en nodes inmiddels van deze tag voorzien.

Ik had namelijk iets nodig om rcn routes op Waymarked Trails te kunnen vinden in de hele massa van bruine lijnen. Daarvoor gebruik ik nu de ref tag. Doet Radregion Ruhr ook.
Echter door het gebruik van ref werkte de style, waarmee rcn routes in JOSM zichtbaar worden niet meer. Die gebruikt de ref tag om onderscheid te maken. Door nu de routes te voorzien van network:type kon ik de style weer werkend krijgend

Ik probeer om vooraf ruime overeenstemming te bereiken en te dokumenteren zodat waymarkedtrails, knooppuntnet, de mappers in Nederland, België en Duitsland en de tagging list allemaal weten wat er precies te gebeuren staat. De tagging list had ik geen beslissende rol toegedacht, maar wel de gelegenheid om eea te vragen en te zeggen. De dingen die hier besproken waren werden daar ook genoemd en ik heb geduldig uitgelegd wat de bedoeling was. Er zijn erg weinig mensen die iets begrijpen van het XXn routegebeuren en nog minder die iets snappen van knooppuntennetwerken.

Maar deze opmerking over dat de beoogde key eigenlijk niks zegt over waar hij voor is, vind ik terecht dus ik leg hem hier even terug.

Op het Duitse forum is wat diskussie geweest maar niet zo diepgaand. Onderscheid kunnen maken tussen de doorgaande routes en de knooppuntnetwerken vinden ze zeker belangrijk; het hoe boeit ze denk ik niet zoveel.

Waymarkedtrails wil heel graag een duidelijk onderscheid kunnen maken dmv een kenmerk in de routes. De superrelatie met het hele netwerk erin is voor hun onwerkbaar. Zij willen dat er onder mappers overeenstemming is met duidelijke dokumentatie, dan kan daar de verwerking op gebaseerd worden.

Het Belgische forum heeft niet gereageerd. Nou gebruiken ze daar een Riot berichtensysteem wat ik onwerkbaar vind, maar iemand monitort het forum en zet het zonodig door naar het Riot systeem. Ik denk in dit geval: geen nieuws goed nieuws, ze vinden het best.

vmarc en andere data users zullen zich ook moeten baseren op vastgelegde afspraken lijkt mij.

Het hangt niet op een paar weken, denk ik, dus Dick, zullen we het gewoon eerst bespreken met alle gremia, dan vastleggen als wiki en daarmee naar de verwerkers gaan?

Een vraagje, Dick: waarom tag je ook de knooppunten met de network:type tag? Wie heeft dat gegeven precies nodig, waarom is het niet voldoende dat het een knoop met een xxn_ref tag is?

Het antwoord staat een stukje terug in dit draadje.
Het is op verzoek van vmarc, die anders knooppuntwezen niet terug kan vinden.

En het is ook consistent, je hebt dan in 1 keer alles wat knooppuntnetwerk is.
Je hoeft dan niet weer uitzonderingen in de software te maken, voor een route moet ik daar kijken en voor een node daar.

Je moet er nl vanuit gaan dat er ook netwerken zijn, die geen knooppuntennetwerk zijn, maar een soort semi netwerken. Eentje is net ter ziele, de Herrensitz routes

En wat Waymarked betreft, network:type=node_network kun je gewoon in een style bevragen, ik heb dat zelf ook gedaan. Ik denk dat in ee style een databasebevraging lastig wordt of zelfs onmogelijk is.

Ik las dat als: inderdaad niet nodig om de nodes extra te taggen met node_network. De rXn _ref zegt genoeg, en die paar uitzonderingen kunnen misschien aangepast worden, en anders zijn het gewoon de bekende uitzonderingen!

Overigens, als de r in rXn niet meer beteken “dit is onderdeel van een knooppuntnetwerk” dan betekent het gewoon weer regionaal. Dan moet je er ook rekening mee houden dat er knooppuntnetwerken op lXn, nXn en iXn-schaal kunnen zijn.
lwn: Ik kwam laatst door een bos (weet niet meer waar) waar ze een soort knooppunten/keuzepunten hadden in de vorm van dieren.
iwn: Internationaal heb ik zitten kijken en puzzelen op de jakobsroutes, dat zijn heel veel varianten en verbindingen tussen plaatsen, waarbij sommige plaatsen door veel varianten gebruikt worden. Dat leek verdacht veel op een internationaal knooppuntnetwerk!
nwn: Het knooppuntnetwerk in NL was eerst gemeentelijk, is nu bijna helemaal regionaal in onderhoud, maar het wordt in rap tempo één groot netwerk in Nederland.
Ik heb vaarknooppunten gezien, hoe het daarmee staat weet ik niet maar ze gaan ook van lokaal naar nationaal, denk ik. Paardrijden: komt ook denk ik!

Dus ik denk dat je rekening moet houden met knooppuntnetwerken voor alle kombinaties van vervoer en schaal.

Samenvattend.

  • We zijn het eens over: rXn gaat weer gewoon betekenen regionale route. Met een extra tag in de routerelatie geven we aan dat routes knooppuntroutes zijn (node2node). De value wordt node_network.

  • Uit België is geen respons gekomen, behalve dan vmarc, en die heeft er verstand van dus daar gaan we voor!

  • Uit Duitsland is positieve respons over het scheiden van de netwerk-configuraties, maar geen specifieke ideeën over de voorgestelde tagging.

  • De tagging list vroeg vooral naar de zaken die wij hier al afgekaart hadden (ik heb uitleg gegeven), en bijkomende zaken waar we nu niets aan doen. Plus het idee om een key te gebruiken waaruit blijkt wat voor type we dan bedoelen. Dit laatste kwam van iemand die behoorlijk weet waar hij het over heeft.

  • vmarc is voor de extra tag voor routes en heeft daar in principe genoeg aan, afgezien van enkele uitzonderlijke nodes die rcn_ref zijn maar niet in een knooppuntnetwerk zitten. Hij heeft geen voorkeur voor een keynaam en value uitgesproken, als iedereen het maar hetzelfde doet kan hij ermee werken. (klopt dit, @vmarc?)

  • Waymarkedtrails (Sarah Hoffman) wil één duidelijk afgesproken kenmerk in de routes zelf. Het moet bij voorkeur goed afgesproken zijn en goed en eenduidig gedokumenteerd in de wiki. NB: als we dit goed doen kan het verzoek voor landspecifieke weergave van rwn-routes vervallen.

  • Bij Zwollle is één wandelknooppuntnetwerkje als pilot door mij getagd met network:type=node_network. Dit was bedoeld als proefterrein voor vmarc, maar ik geloof niet dat er iets mee gedaan is.

  • dvdhoven heeft in Duitsland een rcn-netwerk getagd met network:type=node_network. Uit de beschrijving is mij niet helemaal duidelijk geworden of het ook ergens in produktie gebruikt wordt of nog een test is (sorry Dick, ik mis vaak iets in jouw posts en dan blijkt later dat je het allang gezegd had… excuus als dat nu weer zo is)

Volgens mij hebben we het over de volgende vragen nog geen uitgesproken consensus:

1.** De key-naam.** Voorgesteld in de diverse forums is network_type. Dat is namelijk een bestaande key. In proeftagging is network:type gebruikt. Dat is een nieuwe key. De opmerking vanuit de tagginglist is terecht, dat dit niet zegt wat het verschil is met de network-tag en wat voor type we het over hebben. Voorstel is network:setup (network_setup) of network:config (network_config). Dat zou een nieuwe key opleveren.

  1. Nodes ook taggen of niet. In principe zou dit niet nodig zijn, het feit dat een node een network=rXn_ref tag heeft bevat dezelfde informatie. Misschien is een aparte tag handiger voor data-users, als die dat aangeven dan moet je de moeite bij taggen en onderhoud afwegen tegen het voordeel bij data-users.

  2. Wat er ook nog ligt is de vraag of je de **superrelatie per netwerk **moet blijven gebruiken. Het is slecht onderhoudbaar, een hoop werk bij het invoeren, en moeilijk bruikbaar voor datausers. Het gegeven dat de elementen bij een node_network horen staat al in de elementen zelf. De naam/operator van het knooppuntnetwerk niet, maar a. dat is helaas een snel verouderend gegeven, b. Op de knooppunten en routes staat meestal geen netwerknaam en bijna nooit een operator; c. voor knooppuntnet hadden we een groeperingsalternatief bedacht waar geen tagging voor nodig is: indelen naar gemeente, op basis van de (al gemapte) gemeentegrenzen.

Nu ik toch bezig ben:
4. De nodes in de node2node-routes. Tijdens het invoeren is het best prettig, maar daarna heb je er weinig aan en voor het gebruik worden ze genegeerd. Nu is het een lappendeken van routes die het wel hebben en routes die het niet hebben, dus dan kan een datauser er zowizo niet op rekenen. Mijn voorstel zou zijn om het in de wiki’s af te raden.

  1. De verplichte volgorde laag-hoog. Voorstel was om wel te sorteren, maar het boeit niet welke richting. Vraag: blijven we de note wel laag->hoog doen? In de JOSM relatielijst vind ik dat wel prettig om op te kunnen reken.

  2. Verwachte aantal routes in een knooppunt zetten. Wordt ook heel wisselend gebruikt. Bij checken kan je fouten detekteren, dat kan je goed gebruiken maar dan moet je wel je werkwijze bij het taggen er helemaal op instellen. Wat ik zie gebeuren is dat mensen een knooppunt invoeren, expected erop zetten en dan denken: die relaties vult een ander wel aan! Niet voorschrijven maar wel aanbevelen?

Graag zoveel mogelijk eens / oneens, en bij oneens aangeven met wat en de reden, en liefst ook een suggestie hoe dan!

**Vervolg: **

  • Als er consensus is over de basisopzet en het eerste vraagpunt zal ik het in wiki’s verwerken en daarover een melding rondsturen.
  • Bijkomende punten waarover we consensus hebben neem ik gelijk mee. Punten waar geen consensus over is neem ik niet mee.
  • Afspraken maken met vmarc en waymarkedtrails
  • Plannen van de bij-tagging voor de huidige installed base

Hier is mijn mening:

  1. superrelatie per netwerk: Dit maakt m.n. het beheer gemakkelijker:
  1. De nodes in de node2node-routes: Hier ben ik ooit mee begonnen. Daarna een tijdje gestopt (omdat er weerstand tegen was), maar bij het invoeren en foutzoeken bleek het handig te zijn. Ze zijn niet nodig als er geen fouten gemaakt worden en routes niet stuk gaan, maar mij helpt het wel. Voor het gebruik van de data lijkt dit mij niet nodig.

  2. De verplichte volgorde. Dit kostte mij alleen werk (om foutmeldingen te voorkomen) en de voordelen heb ik nog niet gezien. Als er wel een voordeel ergens is kan de afspraak blijven.

  3. Verwachte aantal routes in een knooppunt. Deze gebruik ik zelf niet omdat ik niet bij elk paaltje ga kijken welke routes er zijn. Ik wandel een route en zet deze daarna in osm met track en waypoints voor de knooppuntnummers. Het kan handig zijn voor iemand die meer gestructureerd een netwerk in kaart brengt.

Bij de andere punten heb ik geen sterke voorkeur.

Klopt.

Wanneer we spreken over “enkele uitzonderlijke nodes”, dan gaat het toch wel om meerdere honderdtallen. Wanneer ik in de database op zoek ga naar nodes met tags lcn_ref (1899), lwn_ref (334), lpn_ref (98), ncn_ref (10), nwn_ref (5), icn_ref (12) of iwn_ref (1), dan vind ik daar ook nog een pak meer nodes die vermoedelijk geen knooppuntnetwerkknooppunten zijn (naast de rcn_ref voorbeelden in een eerder forum bericht).

Als de XXn_ref tags in de wiki gedocumenteerd worden als enkel te gebruiken voor knooppuntnetwerken (zoals nu het geval al is voor rcn_ref en lcn_ref), en oneigenlijk gebruik wordt aangepast, dan is er geen probleem. Anders blijft er uitsluitingslogica en/of blacklisting nodig in knooppuntnet.

Mee eens.

Ik ben momenteel aan het bekijken wat de mogelijkheden zijn om rapportage te doen per provincie/gemeente (Nederland, België), of gelijkaardige “boundary=administrative” levels in Duitsland en Frankrijk. Een eerste stap zou eventueel kunnen zijn om voorlopig rapportage per netwerk te behouden maar een aantal netwerk gerelateerde validatie regels te laten vallen.

Dit betreft het netwerk Kreis Kleve en ja dat is actief

Punt 1
Ik ben en blijf voor network:type en niet iets met een underscore erin
Dat het niet duidelijk zou zijn, snap ik niet. Wat is er onduidelijk aan node_network ?

Punt 2
Ja, nodes ook mee taggen. Dan ben je gewoon consistent en eventuele software hoeft geen uitzondering te maken.
En het is heel simpel. Als je een preset gebruikt is het heel makkelijk deze tag te zetten.

Punt 3
Ik heb geen grote voorkeur.
Aan de ene kant zijn netwerken handig om gebieden af te bakenen, aan de andere kant is het af en toe lastig als je knopen en routes lid moet maken en je het weer eens vergeet.
Dus als mensen vinden dat netwerken moet blijven, mij best
Het is wel zo, dat dan het hele connection gebeuren ook overeind blijft en dat is extra werk en ook weer lastig uit te leggen.
In ieder geval moet er dan in NL flink de bezem door, met name in het zuiden

Punt 4
Kan zo blijven. Ik ben er niet voor om nodes in de routes op te nemen, maar ik kan meevoelen dat het voor sommigen toch handig kan zijn. En een praktisch punt. Als je besluit dat ze niet meer de routes moeten, dan heb je een hoop werk om alle routes te schonen.

Punt 5
Ook hier geen sterke voorkeur.
Het is lastig als je aan het aanpassen bent en je soms een route wel meerdere keren omkeert.
En het omkeren kan vooral bij forward/backward nog wat problemen geven.
Maar zelf heb ik zoveel routine dat het voor mij niet veel meer uitmaakt.
Bedenk wel dat voor starters, het lastiger wordt naar mate het aantal regels toeneemt.
Uiteraard blijven we hoe dan ook de routes in volgorde invoeren, anders krijg je problemen in de route editor.
Het argument voor laag->hoog als opzoekmogelijkheid, vind ik niet sterk. Ook bij laag->hoog krijg je niet alle routes van één knooppunt in beeld

Punt 6
Ik gebruik vrijwel altijd expected
Het blijft een handige tag om fouten op te sporen.

De value is duidelijk, het ging om de key network[:|_]type.

Dit was de opmerking: De key network geeft al een type. Het is dus niet duidelijk wat het verschil is met de key network:type.
Die tweede lijkt dan overbodig, in ieder geval niet vanzelf duidelijk wat die toevoegt en welk soort typering er bijmoet.

Nou zijn er zat keys waar niet direkt bij duidelijk is waar ze voor zijn (amenity betekent niet meer dan “iets”), sterker nog die iets heel anders lijken te betekenen dan ze in feite doen (ik zal het woord landuse maar niet noemen…). Ik kan het wel uitleggen, maar ik zou inderdaad een key zoals network:config wel duidelijker vinden wat die inhoudt. Met name dus voor nog-niet-ingewijden (inklusief een hoop taggers die ergens anders juist heel goed in zijn).
Nieuwe mappers en ook mappers die goed zijn in kaartobjecten vinden routes mappen echt heel moeilijk te leren, heb ik gemerkt. Bij mij ging het bepaald ook niet van een leien dakje, anderhalf jaar leertijd ongeveer (ik weet het, ik ben niet heel snel).

Hoe bedoel je dit precies? Ik bedoel, ik doe dat uiteraard in JOSM, om te zien of de route aansluitend is, maar als hij om welke reden dan ook een verkeerde volgorde heeft gekregen, bij wie of wat gaat het dan fout? Of doel je op een andere route-editor?

Nou het is precies de aanvulling, die nodig is bij het type. Als je rcn en dergelijke als type wilt zien. Er had een value kcn, kwn, etc moeten komen. En network:type=node_network is niets anders dan zeggen, hallo, de r moet eigenlijk een k zijn.
Bij config denk ik aan heel wat anders. Die vind ik niet duidelijk.

Wij zijn het wel eens hoor… er waren nog meer opmerkingen, die heb ik niet in overweging genomen cq weggelaten want ik wil eigenlijk niks veranderen aan de basistagging alleen wat toevoegen om de NL/BE/DE uitzondering zo eenvoudig mogelijk ongedaan te maken.
Bijvoorbeeld: network=Xcn: de n is overbodig want de key zegt al dat het een network is. Niks tegen in te brengen! En: c (transportwijze) is overbodig want route= geeft die informatie al. Bij die laatste zou je dan wel ook in de nodes de route= tag moeten toevoegen, en dan heb je het probleem dat een node voor meerdere transportwijzen kan gelden… afijn, daar ga ik niet verder over nadenken. Wie dat anders wil die komt zelf maar met een voorstel!

Voor nu de nodes meetaggen dan maar? Als ik tijd heb zal ik s kijken of die oneigenlijk xxn_ref’s snap en kan herstellen.

De knooppuntwezen en routewezen toch? sDenken… je kan wel weergeven welke knooppunten in geen enkele knooppuntroute zitten denk ik? En welke routes geen 2 knooppunten verbinden en op minstens 1 andere route aansluiten? Dat lijkt mij ongeveer hetzelfde, maar misschien denk ik daar weer eens te makkelijk over! En het connectie-gebeuren. Volgens mij maakt daar verder niets of niemand gebruik van. Het is MI puur: als je met de netwerkrelaties werkt, dán moet je ook iets voor de connections verzinnen.
Wat ik helemaal niet weet is of er planners of routers zijn voor knooppuntnetwerken, mn voor fietsen want daar heb ik me helemaal niet in verdiept, die de netwerkrelaties en de connections gebruiken. Nog maar even behouden dus maar.

Ondertussen zou ik dan wel de tag network:type=node_network willen toevoegen ook aan de netwerkrelatie. Kan jij die gebruiken ipv de tag type=network? Consistent en consequent!
Dan kunnen we namelijk type=route (of superroute) gebruiken in de netwerkrelaties, waaroor het hele netwerk ook door waymarkedtrails wordt weergegeven. Je kan daar dan ook het gehele netwerk selekteren ipv alleen de aparte node2node-routes zoals nu. Ik heb die weergave vaak gemist!

Ik kan me voorstellen dat type=route of superroute voor een netwerk even wennen is, maar in network=… worden nu al alle routes of routeverzamelingen als “network” benoemd. Het komt aardig overeen met type=[super]route voor de hierarchische routeverzamelingen met etappes, varianten zoals de meeste LAWen en zeker de grote Europese wandelroutes.

Ik zou de node tagging misschien voorlopig even laten zoals het is, en even afwachten tot we eventueel een volledige lijst hebben van mogelijke probleemgevallen.

Bij het uitwerken van de tagging voor kano- en motorbootroutes vorig jaar is gekozen om de tag lpn_ref te gebruiken voor genummerde referentiepaaltjes langs een lpn-route. Dit zijn dus geen knooppunten.

Ik zou ervan uit gaan dat alleen de rxn_ref’s zeker knooppunten zijn.

Een route is één route, met eventueel een aantal varianten. Een superroute is een superrelatie (dus een relatie van relaties) die een route beschrijft, al wordt hier vaak ook gewoon type=route voor gebruikt. Een knooppuntennetwerk is geen route! Daarom hoor je hier geen type=route/superroute, maar het correcte type=network te gebruiken.

Dat je dat niet kan selecteren bij Waymarkedtrails is jammer, maar dat is een functie die zij in moeten bouwen. We moeten niet foutief gaan taggen om het selecteren op een bepaalde website gemakkelijker te maken.

Hoe tag je die bootroutes en nummerpaaltjes precies?

Aanpassing: Lamaar, ik heb op de wiki over paddling gekeken, duidelijk. De routerelatie bevat alle vaarwegen. De referentiepunten staan onderweg. Ik ga nog even verder grasduinen!

Ik volg je redenering, maar:

  • Losse routes worden nu ook al als netwerk aangeduid (network=lwN/nwN - lokale routes en streekroutes vormen echt geen netwerk!)
  • Superroutes zijn relaties van relaties, sommige zijn samen 1 lineaire route maar zijn dan meestal weer onderdeel van een groter geheel, in feite dus een netwerk, maar hebben toch type=route.
  • Het enige verschil met een knooppuntnetwerk is dat die laatste ook nog knooppunten onderweg heeft. Alles wat erin zit komt uiteindelijk op routes neer, net als bij de top-relaties van lineaire routes.

Ik ga hier verder geen punt van maken, maar ik zou voor consistentie, zolang ze er zijn, de netwerkrelaties ook de network:type=node_network tag geven. Dus alle elementen van een knooppuntnetwerk krijgen de tag. Mochten ander netwerksetups opgang doen (bv kleurkeuzenetwerk, boomstruktuurnetwerk) dan kunnen die met een andere value van network:type worden aangemaakt.

Losse routes worden als route aangeduid. De tag ‘type’ duidt aan wat voor soort relatie het is. Bij een losse route is dat type=route, bij een netwerk is dat type=network. De tag network is een aanvullende tag, die aangeeft van wat soort netwerk de route deel uitmaakt. Het betekent dus niet dat de losse route een netwerk is.

De superroutes (bijvoorbeeld bij een lange-afstandroute) geven wel een duidelijke route aan, eventueel met een aantal alternatieven. Een knooppuntennetwerk bestaat uit een netwerk van honderden korte routes. Er is dus absoluut geen sprake van één route. Het is een fundamenteel ander object dan een (super)route.

Heb je de E2 wandelroute al eens bekeken? Niet erg duidelijk, kan ik je vertellen! Die grenzen zijn echt niet zo duidelijk, uiteindelijk zijn een heleboel langeafstandwandelingen gewoon een grote stapel deelroutes. Je kan bv het Grote Rivierenpad wel één route noemen, maar het Erasmuspad is bijgevoegd en de noordelijke variant is in feite een route op zich. De losse etapperelaties hebben ook nog alternatieven. En het VeluweZwerfpad is in feite een netwerk, niet één route. Idem voor het wandelpad rond Winterswijk, hoe heet het ook weer? Het Scholtenpad. En SP04 Waddenwanden, dat is een verzameling meerdaagse rondwandelingen op de Waddeneilanden… In feite gewoon containers met routes dus. Toch: allemaal type=route, terwijl het eerder verzamelingen zijn, min of meer met elkaar verbonden, soms alleen maar door de groepering die Wandelnet eraan gegeven heeft.
Het verschil tussen een superroute en een netwerk wordt soms wel héél erg klein. Fundamenteel zijn het allemaal verzamelingen wandelroutes en het verschil zit m in hoe wij mensen ze noemen en benaderen.

Maar nogmaals: ik wil er geen punt van maken.

De voorgestelde wijzigingen zijn dus:

  1. network:type=node_network toevoegen aan alle nodes, node2node-routes en de netwerkrelatie van elk knooppuntnetwerk
  2. de ways in de node2node-relatie mogen voortaan ook hoog-laag gesorteerd zijn.

Als het vmarc lukt om de netwerken op gemeentegrens te verdelen en analyseren, dan kunnen de netwerkrelaties vervallen.
exp_… taggen, en het toevoegen van de nodes aan de node2node relatie blijven optioneel.

Ik wil de wandelwiki’s wel bijwerken.
Wie wil de fiets-wiki’s aanpassen?
Wie wil de vaar-wiki’s aanpassen?
Voor de andere transportwijzen heb ik niet gekeken naar wiki’s.

Wie is er goed in een wikipagina maken voor de nieuwe key?

Ik zal de issue van waymarkedtrails in github aanvullen, en de Belgische en Duitse forums en de tagginglijst inlichten.

Dat lijkt me een goed idee.

Ik wil de vaar- en skateknooppuntenpagina’s op de wiki wel aanpassen. Die heb ik destijds ook aanmaakt.