Knooppuntnetwerken scheiden van routes?

Hm… een lokaal kleurenrondje is geen knooppunttrajekt op zich, toch? Het is verdeeld in delen die elk al of niet een knooppunttrajektje kunnen zijn. En dan is dat hetzelfde als rondwandelingen opbouwen uit knooppunttrajektjes plus losse trajektjes die niet bij een knooppuntnetwerk horen.

Ik zie alleen een probleem als meerdere wandelknooppuntnetwerken tegelijk dezelfde keuzepunten/knooppuntpalen gebruiken, maar elk een verschillende nummering voor de paaltjes gebruiken. Maar dat gebeurt nergens, mag ik hopen… anders passen we daar ook wel weer een mouw aan.

Dat laatste gebeurt helaas wel. Al weet ik niet of het buiten nog zo ligt. Dat is het netwerk Dorpen van Venray dat over andere netwerken heen ligt en in VMarc veel fouten geeft.

Het netwerk Salland en het netwerk Achterhoek hebben net hun grensgeschillen beëindigd. Tot dusver lagen ze over elkaar heen soms met een keuzepunt van de één of de ander, maar nu werken ze geïntegreerd en gebruiken ze elkaars keuzepunten en paaltjes

Wat de lokale rondjes betreft, er is een mapper, die deze rondjes als DE rwn routes ziet. Die wil helemaal geen onderliggend rwn netwerk, die wil ipv daarvan de lokale rondjes als rwn. Dat dat allerlei problemen oplevert, neemt hij op de koop toe.
Kijk en dat heb ik al een aantal keren gezegd, die rondjes zijn maar een deel van het geheel. Het rwn netwerk is veel en veel groter dan de rondjes

Ik deel volledig jouw mening. Met een onderliggend rwn netwerk kun je veel beter uit de voeten. De rondjes kun je dan er overheen leggen als lokale routes.

Er is bij Venray al iets veranderd ten goede. Oorspronkelijk had elk dorp in de gemeente Venray zijn eigen ‘netwerk’. Hierbij stonden soms 2 paaltjes bij een kruispunt met andere nummers. Of dezelfde nummers bij 2 verschillende afslagen.
Deze lossen netwerkjes zijn gekoppeld. Maar er zit helaas nog te veel (letterlijk) overlap met andere netwerken.

Dat zal in e checker wel lastig zijn, hoe moet je bv #expected interpreteren. Maar misschien is dat soort dingen wel oplosbaar? Voor renderen maakt het MI niet veel uit. Voor eventueel routeren via knooppunten - lijkt me ook niet veel uitmaken. Zolang je maar weet dat het een knooppunttrajekt is, boeit het voor de router eigenlijk niet tot welk netwerk het behoort.

Inderdaad, maar…

Er zijn toch een aantal tegenvoorbeelden te vinden waarbij een rcn_ref tag gebruikt wordt op een node, terwijl het toch niet om een knooppunt in een knooppunt netwerk gaat.

Het gaat hier wel om een in verhouding heel beperkt aantal nodes, die het inderdaad niet verantwoord maken om de tagging van alle andere nodes aan te passen.

Voorbeelden van rcn_ref gebruik, waarbij het waarschijnlijk niet om knooppunten gaat:

Hmm… het wringt voor mij een beetje met mijn principe om dingen zo generiek mogelijk op te lossen, dus niet values aflopen om je verwerking te bepalen. De xxn_ref tags zijn gekoppeld aan values van een andere key, en die set is niet principieel beperkt. Als er een andere value voor network bijkomt moet iedereen case-statements in de code gaan zitten aanpassen.
Of klets ik nu onzin?

In de tagging-list kwam de opmerking dat network_type (of network:type) niet heel duidelijk is. We hebben toch al network=*?

MI gaat het hier om de netwerksetup of de netwerkkonfiguratie. In network=* staan de geografische schaal (l, r, n of i) en de transportmethode (w, c, h, …). (Dat laatste is eigenlijk overbodig, want route= geeft de transportwijze al. Maar daar wil ik niet aankomen, het lijkt me geen goed idee om bestaande veelgebruikte tagging te veranderen.)*
Dus we voegen wel degelijk iets nieuws toe met de extra tag.

Dus misschien beter network_config=* of network_setup=* gebruiken, of de namespace:varianten daarvan, network:config of network:setup ?

Het nadeel is dat het dan om een nieuwe key gaat en ik wil het proposal-circus hiervoor niet doormaken. Tenslotte gaat het erom dat we ophouden met ons bijzondere gebruik van rXn zodat je weer gewone regionale routes kan mappen conform de internationale wiki’s. Daarnaast willen we wel onze knooppuntnetwerken behouden op een zo eenvoudig mogelijke manier, zonder retagging, en consistent en eenduidig voor de taggers, de rendering, de checks van knooppuntnet.* en de knooppuntplanner-in-aanbouw.

Als dat lukt dan kunnen anderen er 100% zeker ook mee overweg!

Maar de vraag dus: de bestaande key network_type hiervoor gaan gebruiken of toch een andere (nieuwe) key met een duidelijker naam?

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.