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

[Jo]

Will this be communicated to map renderers? As far as I know, they only
count rcn, rwn, rhn as (numbered) node networks. I tend to agree that lcn
is the best solution for this, but usually lcn are loops. If the renderers
can't cope with this, maybe we need something like ccn? (city wide cycling
network). I expect that those renderers will not be rendering the node
numbers for lcn.

Jo

On Wed, Jul 7, 2021 at 8:45 PM joost schouppe <joost.schouppe at gmail.com>
wrote:

> 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
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20210708/4a1c7288/attachment.htm>