[OSM-talk-be] Proposed cycle node network in Ghent

[joost schouppe]

Hi all,

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

There is of course a well known cycle node network that spans Flanders (and
connects to other regions) and is managed per province by provincial
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 currently 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, if you want to go from 4 to 93, you will go 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 is actually
used in route planners and maps
- the Ghent network will NOT be fully integrated in the provincial network.
So a user at Node 4 in actual reality will see a "provincial" sign to node
93 and also a Ghent sign pointing to 45.

This complicated situation, together with a lack of documentation about the
data model for this kind of situation has led to a few mistakes when
editing, and unnecessary 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,
as an 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 large data users. Interesting discussion
on the topic is 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. This will be the conclusion to the second
discussion at [3].
- 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 (or as long as
the network awaits construction: proposed: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 (for example cycle-horse hybrids). Data users that
are only interested in a particular type of network, will always find the
relevant tag from their perspective.
- Occasionally, Ghent did not add an extra Node between two provincial
nodes that are both 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 themselves (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 adapted data. Giving
it a little time will also allow us to incorporate feedback received 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

-- 
Joost Schouppe
OpenStreetMap Belgium
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20210707/3cf97bc3/attachment.htm>