[Tagging] Feature Proposal - RFC - value 'basic_network' - cycle_network?

Peter Elderson pelderson at gmail.com
Sat Nov 27 20:04:49 UTC 2021


Just about lcn / rwn.

In Belgium there is a use case where the regional authorities maintain a
regional cycling Node network, as part a of the national cycling plan. Then
the main city in the region (I think it's Ghent) implemented its own
cycling Node network within the city and its surroundings, re-using
(adopting) most of the regional Nodes, but adding intermediate Nodes.

This was implemented in OSM by using lcn for the city's network, leaving
the regional network as rcn.
The shared Nodes now have an lcn_ref=NN tag in addition to the rcn_ref=NN
tag. The Local nodes only have an lcn_ref tag. This way both networks can
be used independent of each other, or connected, that's up to the data
user.

Peter Elderson


Op za 27 nov. 2021 om 20:25 schreef JochenB <JochenB at wolke7.net>:

> Am 24.11.2021 um 07:20 schrieb stevea:
>
> ... Right now begins a sort of crazy time where the calendar slows way down, little work gets done and people travel and gather with family and friends.  ...
>
> It's similar with me. Grandfather is visiting this weekend, he is alone
> and we are preparing for Advent with him and the child.
>
> I am positively surprised by the response to the proposal (even if a lot
> is viewed critically), but can hardly keep up.
>
>
> If say, icn=4, ncn=3, rcn=2, lcn=1 then basic_network would be 0 (zero) in this way of thinking about things (not actually using these numbers, just to illustrate how they relate to one another as layers / levels).  I think we might agree there.
>
> There was also the idea in the German forum to map level "0" via
> *'networc=bcn'*, that would fit this point of view. Roughly this fits,
> but it is also not ideal.
>
> *Short version: *in certain cases it may be that the specification of
> *'network=l*n/r*n'* makes sense, then it does not fit.
>
> *Long version*: *'network=icn/ncn/rcn/lcn'* was defined for classic
> routes that have a clear beginning and end. It often contains two
> statements in one tag:
>
>    1. Statement about spatial extent (length of the route in relation to
>    the size of the regions / countries)
>    2. Adminstrive classification or jurisdiction
>
> This tag is not entirely clean either, because it expresses two things at
> the same time.
>
> In the sense of a), *'bcn'* would actually be another level, here that
> fits very well. The other values *'**icn/ncn/rcn/lcn'* do not seem
> sensible to me in a network with many connections and thus many beginnings
> and ends. What is used for categorization? The length of the longest or
> shortest connection on the network? Or the expansion of the whole network?
> How do you determine the extent of a network if the networks at the edge
> are linked to a similar neighboring network. What is the added value that
> we derive an *'**icn/ncn/rcn/lcn'* , it cannot be read outside? Can't the
> data evaluators deduce this themselves? So it also happens that the similar
> basic networks in Germany are sometimes tagged as 'lcn', sometimes as
> 'rcn'. Examples:
>
>    - 'lcn': cycle-network Steinfurt, relation 2003649
>    <https://www.openstreetmap.org/relation/2003649>;
>    - 'rcn': cycle network Dithmarschen, relation 1771415
>    <https://www.openstreetmap.org/relation/1771415#layers=C>
>
> With *'network=bcn'* these questions would no longer arise, it would be
> another layer.
>
> With regard to b), it can sometimes be useful to specify
> *'network=icn/ncn/rcn/lcn'*. This is the case when there are different
> basic networks with different responsibilities, especially when the
> networks outside differ, e.g. B. by different standards. So there can be a
> basic network of nationwide connections (*'2-rcn'*) with *'surface =
> asphalt'* as standard, in the municipalities an additional basic network
> with different signposts (*'1-lcn'*), where also *'surface = compacted'*
> is permissible. Then I would use the *'network=rcn/lcn'*. But that would
> result in the following:
>
> 'network=bcn;rcn'
>
> On the one hand, it can be seen that 'bcn' does not completely fit into
> the scheme *'icn/ncn/rcn/lcn'*, on the other hand I find tagging two
> values on a key unfavorable. Therefore I would prefer to use a different
> key or describe the individual properties in individual keys, which
> distinguish networks or routes.
>
>
> However, I honestly believe that you can denote the "purpose" of a network by adding a modifier to the value of a cycle_network=* value.  Likewise for "THE" basic_network in a given jurisdiction.... cycle_network=DE:Bavaria:basic (or something like that)  ...  cycle_network=DE:Bavaria:tourist ... cycle_network:DE:Bavaria:commuter.
>
> Yeah, kind of like that. I would give the network a title. How we call
> this and in which hierarchy we would have to discuss for ourselves in
> Germany. The purpose of the network can be the namesake (basic, tourist,
> rehabilitation ...), but it doesn't have to be. In my german state Saxony,
> the basic network has an official name "Rad.SN", so maybe that's what it
> will be and not the purpose of the network.
>
> 'cycle_network=DE:Saxony:Rad.SN'
>
> Certainly you can also specify properties of the routes or networks in
> *'cycle_network'*, such as the purpose of a route. The question is, is it
> the best place for it? I mean it's not the best place.
>
> *Example: *In Bavaria the basic bicycle network has a green bicycle as
> its symbol. We could agree in Germany to designate the network as follows:
>
> 'cycle_network=DE:Bavaria:network green cycle'
>
> or similar. Let's imagine a data consumer wants to display color and
> symbol. He should know to look for the network name in *'cycle_network'*.
> We would have to document in the wiki at 'cycle_network' that in Germany
> these properties are mapped in the network name, the color comes after
> "network" and the symbol after the color. The data evaluator would have to
> program Germany-specific rules. In the wiki we would have to document all
> such country-specific rules for *'cycle_network'*.
>
> I think it becomes clear that you should use the key *'symbol=*'*, even
> if you find the symbol and color in the name of the network.
>
> It is the same with the purpose of a route / network. In Germany we can
> use the purpose as the name of the network in *'cycle_network'*. That
> would be a country-specific solution. That is OK here, because names are
> naturally country-specific.
>
> The aim of the proposal was to enable the renderer to display tourist
> routes differently than basic connections. However, it should not have to
> derive the purpose from a country-specific name. It is better to specify
> this property using a key that represents only this property as far as
> possible and that can be used worldwide where similar situations arise.
> Ideally, it can already be deduced from the name of the key which property
> is being mapped.
>
> *Another example: *The need for a separate key becomes particularly clear
> when the basic network has its own name, such as "Rad.SN" in Saxony. From
> *'cycle_network=DE:Rad.SN'* it is not possible to derive the purpose of
> the routes in the network "Rad.SN".
>
> So I'd like to suggest a tag that makes this distinction explicit. That is
> the intention of the proposal that has now been formulated. I have learned
> that it is better not to use *'network: type'*, but to use a
> self-speaking key.
>
> I would like to argue about this key name and its values, especially on
> this mailing list, because key names and values should be internationally
> understandable.
>
> With that I would revise the proposal and open a new thread for discussion.
>
> Best regards,
> Jochen
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211127/872c7d61/attachment.htm>


More information about the Tagging mailing list