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

Sat Jul 10 18:20:32 UTC 2021

Well, 
The example Seppe gives is an lcn-route, 87-88, which is part of an
rcn-network. I think the renderer here renders all routes in the rcn-
network ignoring that this route is tagged as lcn.For reasonable
rendering, the lcn-network (nodes and routes) should have a different
colour/shape than the rcn-counterparts, since some users will want to
ignore the lcn-nodes. e.g., someone using rcn-nodes wanting to travel
from node 3 to node 82 in Ghent can follow the rcn-arrows carrying 82,
but will find intermediate lcn-nodes and arrows on his ride.
vg,
JanFi
 Seppe Santens schreef op za 10-07-2021 om 13:54 [+0000]:
> Well, it seems these lcn node networks will be rendered at least in
> one layer/style:
> https://imgur.com/a/Ev0xBGx
>  
> see
> 
> https://www.openstreetmap.org/relation/11966301#map=15/50.9309/4.6234&layers=CN (although I suppose this should be corrected to
> rcn).
> 
>  
> I guess a node network is defined by network:type=node_network and
> that should be independent of rcn / lcn / … Any other things to take
> into account?
>  
> Cheers,
>  
> Seppe
>  
> 
> Van: Jo <winfixit at gmail.com>
> 
> 
> Verzonden: donderdag 8 juli 2021 12:47
> 
> Aan: OpenStreetMap Belgium <talk-be at openstreetmap.org>
> 
> Onderwerp: Re: [OSM-talk-be] Proposed cycle node network in Ghent
> 
>  
> 
> 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
> 
> 
> 
> ***DISCLAIMER*** www.westtoer.be/disclaimer
> 
> 
> _______________________________________________Talk-be mailing 
> listTalk-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/20210710/3708286e/attachment-0001.htm>