Zeker, daar heb ik ook al aan zitten denken op de fiets.
Als het echt een wens is om de gekleurde lokale rondjes in het rwn te hebben, dan kun je ze onderbrengen in een rwn netwerk met network:type= iets van roundtrips of local_routes of regional_routes.
De software van VMarc kan deze netwerken dan negeren.
Dat kun je ook gebruiken voor een groep regionale fietsroutes zoals de Grafschafter Fietsentour routes
Wanneer de informatie dat het om een knooppuntnetwerk gaat enkel in de netwerk relaties gaat zitten, dan geloof ik de functionaliteit rond de knooppuntwezen en routewezen verloren gaat. Lijsten met routes die niet tot een netwerk behoren (of knooppunten die niet rechtsstreeks of onrechtstreeks onder een netwerk hangen), kunnen dan niet meer aangemaakt worden. Deze routes en knooppunten zouden ook verdwijnen uit de kaarten of routeplanners die zich op de nieuwe tagging baseren.
Misschien geen probleem? Of toch? Ik me voorstellen dat er routes verdwijnen als ze per ongeluk uit hun netwerk relatie wegvallen?
Dat is helder en duidelijk.
Dan moet zo’n tag in de routes en evt ook de knopen worden opgenomen.
Geeft alleen het probleem dat dat niet in de preset zit. Dus moet de preset worden aangepast of er moet een aparte preset komen.
In ieder geval nieuwe foutcategorie: route/knoop heeft geen tag voor network:type
Ik denk dat we ons er nu in kunnen vinden om een aparte tag toe te voegen aan knooppuntennetwerken?
Met als enige value voorlopig node_network (uitbreiding met andere types is mogelijk)
De key voor netwerktype kan network:type zijn (de namespacevariant).
Niet de rijgvariant network=rwn rwn=node_network, want dan moet je voor elke scope/mode-kombinatie een nieuwe key toevoegen.
Hoe nu verder? Uiteraard moet dit ook (vooral) in Duitsland en Vlaanderen door de community’s besproken worden, maar dan zou het handig zijn om de werkbaarheid te kunnen laten zien, niet alleen theoretisch. Vmarc kan dan de Duitse toko een werkend model bieden voor de uitbreiding naar Duitsland.
Ik stel een pilot voor. Een beperkt aantal wandelknooppuntnetwerken bijtaggen met network:type=node_network zodat verwerkers die als bron kunnen gebruiken om met de verwerking te stoeien. Ontwikkelen en testen, bedoel ik. Dat kan zonder probleem, want bestaande verwerkingen worden op geen enkele manier gehinderd of veranderd.
We kunnen gecontroleerd netwerken kiezen, bijvoorbeeld een heel goed en kompleet netwerk, een halve (in aanbouw), een met veel problemen, eentje uit de Achterhoek.
Wandelnetwork lijkt me handig om te beginnen, want fietsen is al veel verder ontwikkeld dus daar hangt meer aan, en het heeft de komplikates van aparte heen-en terug-routes met gesplitste knooppunten en zo.
Mocht blijken dat het geen voordelen biedt, onwerkbaar is, of nog anders moet, dan kan het in dit stadium nog gemakkelijk worden aangepast/verwijderd.
Ik kan je voor een proef het wandelnetwerk IJsseldelta aanbevelen. Daar is maar weinig van ingevoerd en het is een compact geheel meest rond Zwolle. De Achterhoek is een reus van 638 km
De grootte ben ik niet zo bang voor, het gaat er vooral om of je het goed kan selekteren om aan alles tegelijk de tag toe te voegen. ObjectId van de netwerkrelatie downloaden, dan krijg je alle onderdelen binnen, toch?
Gedaan voor rwn network Vechtdal 1341166. Sorry, Dick je zei IJsseldelta bij Zwolle, dus ik pikte er een uit bij Zwolle en zag later pas dat het netwerk Vechtdal heet.
Maar het was snel te doen, alle relaties krijg je meteen binnen en kan je zo selekteren, alleen de knooppunten moet je apart via Zoeken in het objectvenster zetten. Ongedaan maken kan op dezelfde manier of via de changesets.
Ik zag dat veel van die punten ook rcn-punten zijn, dus er is meteen een testmodel voor rcn.
Vechtdal is ook nog redelijk bescheiden en overzichtelijk 
Het is wel raar dat je voor een node een extra tag zou moeten toevoegen dat het om een node_network gaat. Andere netwerken hebben toch helemaal geen nodes? Als je node tegenkomt met een xwn_ref tag, heb je toch sowieso met een knooppuntnetwerk te maken? Die kun je toch net als nu als waymarkedtrails of knooppuntnet herkennen? Of is het plan om de oude tagging te verwijderen?
P.S. Ik negeer hier voor het gemak maar even dat een overenthousiaste PE via een (mechanical?) edit alvast aan het omtaggen is geslagen, en niet even een dagje op reacties wacht.
Je hebt gelijk, ik loop te hard. Maar ik ben niet aan het omtaggen, ik heb alleen in 1 network een tag toegevoegd die niets aan de huidige situatie verandert en die zo weer verwijderd kan worden.
Ik denk ook dat een tag node_network toevoegen aan een network node redundant is. Ik ga op Vmarc en de gebruikers van zijn site af als ze zeggen dat het voor het checken handig is, net als de note tag en de expected… tag. En dat kan de moeite waard zijn als daardoor de netwerken gecheckt en onderhouden kunnen worden.
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. 
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.