Knooppuntnetwerken scheiden van routes?

Dit lijkt me een punt voor de verwerkers, of het handig is om een trajekt tussen twee punten te taggen als knooppunttrajekt of dat ze dat uit de overkoepelende relatie moeten halen. Technisch is het niet zo dat een tag op de relatie ook in de delen zit, de verwerker moet die relatie opzoeken en de tags zelf toepassen. Aangezien de networktag in elk deel zit, leek het mij logisch om het nadere kenmerk network:type daar ook toe te voegen.

Waarschijnlijk ligt dit voor rendering anders dan voor analysetools en nog anders voor plannen en routeren.

Dit is gewoon standaard database techniek.
Je zet een kenmerk zo hoog mogelijk. In dit geval geldt de netwerk:type voor alle routes van het netwerk. Het is nl een eigenschap van het netwerk, niet de routes.
Als je het in de routes plaatst, dan heb je redundency. En dat kan nog in de papieren lopen en ook qua onderhoud is het gevoelig. Bovendien moet het aan alle routes worden toegevoegd, dus een extra kans dat het weer mis gaat.
Normaal ontwerp je eerst de database, plaatst kenmerken bij de objecten waar ze bij horen en pas later ga je eventueel redundency toevoegen als bijv. uit performance overwegingen blijkt dat dat noodzakelijk is.
Dat lijkt hier niet het geval. De OSM database is zo plat als een dubbeltje en met een eenvoudige query zijn gegevens van de parent op te halen.

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 :slight_smile:

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