# Lokale Knooppunt routenetwerken

###### tags: `archive`

## overgang van gepland naar gerealiseerd
* state=* wordt courant op relaties gebruikt. Laat ons dit behouden voor het netwerk en de route
* state=proposed op netwerk
* wat is de beste oplossing voor nodes van netwerken? > we stellen voor om lifecycle tags te gebruiken

## overlappende nummers van 4 naar 93 in netwerk 1 en van 4 over 11 naar 65 en 81 naar 93

* Er moeten dus soms twee relaties gedefinieerd worden op dezelfde weg > vb 4 naar 52 is onterecht verwijderd
* Mappers duidelijk op de hoogte brengen van overlappende netwerken met verschillende beheerders. Deze hebben wellicht ook een andere status: LCN vs RCN.
* De bestaande knopen van de provincie worden hergebruikt, maar tussen elk provinciaal knooppunt worden er bijkomende knooppunten toegevoegd. Op de provinciale knooppunten worden er dus ook Gentse pijltjes toegevoegd. De knoop krijgt dus zowel rcn_ref als lcn_ref die identiek zijn.
* TBD: mag cycle_network behouden worden?
* lifecycle tags is enkel nodig voor ???_ref=*

## Praktische aanpak

* Aankondigen, nog geen grote aanpassingen doen
* Relatief grote aanpassingen stadsnetwerk in bulk zal gebeuren door Stad Gent
* Anyways: gebruik de bestaande Stadsregionale network maar voorzie dat rcn kan veranderen naar lcn
* Verder aan te vullen op de wiki's

Hi all,

There was some discussion recently about the proposed cycle node network in the city of Ghent, see for example [1]. It's a rather confusing situation.

There is a well known cycle node network that spans Flanders (and connects to other regions) and is managed per province by province authorities.
The city of Ghent is planning a "stadsregionaal" cycle node network that spans the city and stretches slightly into neighbouring municipalities. The Ghent network respects the provincial network in the sense that all nodes from the province are re-used just as they curently exist. But they add a lot more options within the city area.

See the image linked here: [2]

For example, the provincial network has one section from 4 to 93, but in the Ghent network, you will go from 4 through 45, 11, 65 and 81 before reaching 93.

As if this isn't confusing enough, add this:
- the Ghent network is already mapped as a proposed network and used in route planners
- the Ghent network will NOT be fully integrated in the provincial network. So a user at Node 4 in reality will see a "provincial" sign to node 93 and a Ghent sign pointing to 45.

This complicated situation, together with a lack of documentation in the data model has lead to some mistakes when editing, and unneccesary issues for data consumers.

So we set up a meeting with mappers who are also data-users: pelderson, seppe, Pietervdvn, vmarc and Pieter Deckers from Stad Gent. I facilitated in my role as OSM Belgium member.

During the meeting we came to these conclusions:
- while not all of us are happy with the standard of using state=propose/construction/... for future route relations, this is documented and supported by most data users. Interesting discussion on the topic available here [3]. So let's keep using that for the relations (the route from node to node and the network itself)
- after considering all the options for how to indicate the status of nodes that are "proposed", we came to consensus that the best solution is to use lifecycle tagging. This is normally only needed for tags like proposed:rcn_ref. This will remove the planned Nodes from any tool that is not aware of lifecycle tags.
- The r in rcn stands for regional. Currently, the Ghent network is also defined as regional. We came to the consensus that the Ghent network is local in scope, so all relevant tags will be changed from rcn to lcn.
- There will be route relations between the lcn nodes, but also between all the rcn nodes. To return to the example above, there will be a rcn route relation between 4 and 93 (as currently exists), and also a lcn route relation between 4 and the 45.
- That means Nodes like 4 and 93 will of course keep their rcn_ref. Nodes like 45 will be changed from the current rcn_ref to lcn_ref. Nodes that are used by BOTH networks need a ref from both networks. So for example 4 will have both rcn_ref=4 as well as an lcn_ref=4. This makes sense, because it's the only way to make both networks "complete" when looked at individually. It is also a good fit for all the other networks that are popping up that re-use existing Nodes. Data users that are only interested in a particular type of network, will always find the relevant tag from their perspective.
- Occasionally, no extra Node is added by Ghent between two provincial nodes that are re-used in the Ghentian network. For the sake of consistency, these should also be connected by a Ghentian route relation.

These are some pretty large changes, but the people from the City of Ghent are willing to do them theirselves (with a little help from us). We would like to encourage you to not make large scale changes to the tagging quickly. The city are working to coordinate with their routing software developers (Anyways.eu) to be ready for the change. vmarc is also still preparing knooppuntnet.nl to be able to consume this data. Giving it a little time will also allow us to incorporate feedback recieved here. We will of course keep you posted here.

pelderson has already started documenting some of this on the wiki [4] and we will post an update at the previously mentioned talk page; as well as add a clarifier to the wiki page for the "state" tag that it should probably NOT be used on Nodes.

1: https://www.openstreetmap.org/note/2727432
2: https://i.imgur.com/Vya2DEQ.png
3: https://wiki.openstreetmap.org/wiki/Talk:Key:state
4: https://wiki.openstreetmap.org/wiki/Node_Networks#Recent_developments