Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Peter Elderson
LS
With the arrival of cycling node networks, the Dutch, German and Belgian mappers decided to claim (hijack)  the network value rcn for those node networks. This exception was copied with the claim of network=rwn for the walking node networks. 

We are currently discussing in the three communities how to coreect this exception and return rcn and rwn to their intended use. To do that, we need another way to identify (members of) a route network as (members of) a node network.
 
The network values identify transport mode and scope of routes, and these "dimensions" also apply to node networks. We do not want to add another dimension (configuration type) to the network=*  values of routes.

Instead, we are thnking about just adding a tag to identify segment routes as parts of a node network. The nodes themselves do not need this, since they ARE nodes and have a xxn_ref tag. 

In short, we are thinking to simply add the tag network_type=node_network (or network:type=node_network) to the node2node network routes. Nothing else has to change, which also means that renderers and data users who don't change anything, will not notice anything! But if they want they can make use of the separation and handle node networks different than non-node networks. 

Notice that no new key or value is proposed here. If new network config types arise, a new value for network_type can accommodate that.The method is applicable for all transport modes and geographical scopes. 

Thoughts, anyone? What did we forget? Shoot!

Fr gr Peter Elderson

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

s8evq

On Thu, 29 Aug 2019 16:52:47 +0200, Peter Elderson <[hidden email]> wrote:

> We are currently discussing in the three communities how to coreect this
> exception and return rcn and rwn to their intended use.

Where does this discussion you're talking about take place?
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Peter Elderson
Osm forums
https://forum.openstreetmap.org/viewtopic.php?id=67218  (german forum)

The main discussion of alternatives was on the Dutch forum. Here I present the bottom line. 
Vr gr Peter Elderson


Op do 29 aug. 2019 om 18:56 schreef s8evq <[hidden email]>:

On Thu, 29 Aug 2019 16:52:47 +0200, Peter Elderson <[hidden email]> wrote:

> We are currently discussing in the three communities how to coreect this
> exception and return rcn and rwn to their intended use.

Where does this discussion you're talking about take place?
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Andy Townsend
In reply to this post by Peter Elderson
On 29/08/2019 15:52, Peter Elderson wrote:
> LS
> With the arrival of cycling node networks, the Dutch, German and
> Belgian mappers decided to claim (hijack)  the network value rcn for
> those node networks. This exception was copied with the claim of
> network=rwn for the walking node networks.

Would it be possible to try and describe in a bit more detail what has
happened, without using judgmental terms such as "hijack"?  I'd start
with a link helping people understand what a "cycling node network" is.

Can you give an example of a "normal" rcn and a "node network" that
someone has tagged as an rcn and explain what the problem is with this
tagging?

Best Regards,

Andy




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Peter Elderson

Op zo 1 sep. 2019 om 12:35 schreef Andy Townsend <[hidden email]>:
On 29/08/2019 15:52, Peter Elderson wrote:
> LS
> With the arrival of cycling node networks, the Dutch, German and
> Belgian mappers decided to claim (hijack)  the network value rcn for
> those node networks. This exception was copied with the claim of
> network=rwn for the walking node networks.

Would it be possible to try and describe in a bit more detail what has
happened, without using judgmental terms such as "hijack"?  I'd start
with a link helping people understand what a "cycling node network" is.

Sure. A node network consists of numbered nodes (signs) with short routes between pairs of adjacent nodes. Eg nodes 10, 35 and 22 with routes 20-35, 10-22 and 22-35, and then each of these nodes has other connections to other nodes. The idea is that a cyclist/hiker plans a route along these nodes, so a  trip consists of a series of node numbers. This differs from regular cycling/walking routes which contain chains of ways to follow, or subrelations containing the ways. Node networks were first designed and implemented for cycling  in Belgium, then spread to Nederland and Germany, and they are now also used extensively for walking.


Tagging of regular cycle route relations is route=lcn for local routes, rcn for regional routes, ncn for national routes, icn for international routes.
Node network connections are short local routes, but if you just tag these as lcn you cannot tell the difference between regular local routes and node2node routes belonging to a node network. For rendering, checking integrity, planning and routing, the types need to be different. Same for other scopes.
Rather than creating a new network value, cycle network taggers decided that rcn wasn't much used anyway, so they reserved that value for cycling node networks. 
The walking node networks later copied that: lwn, nwn and iwn for regular and long distance walks, rwn for walking node networks.

To get an idea how that works out: this is a part of the waymarked trails hiking view in Nederland, around Eindhoven. Walking network routes are orange.

 
Can you give an example of a "normal" rcn and a "node network" that
someone has tagged as an rcn and explain what the problem is with this
tagging?

The problem is that node networks are different from regular walking/cycling routes in most aspects, except the mode of transport. 
They need different rendering, different planning tools, different routing and different integrity checking.

At the same time, node networks and regular routes for more modalities are emerging. Node networks can also have different geographical scopes. If you call them all regional, you lose the actual scope.
The idea now is to stop reserving rXn (a scope value) for a specific network configuration type. rcn should just mean regional cycling, and by default regular route configuration (chain of ways)  is assumed. 
We now want to add a separate tag for network configuration type. Could have more than one value, but for now we need only one, indicating that the route relation belongs to a node network. 

This will return the network=rXn in Germany, Belgium and Nederland for its intended use as documented on the OSM hiking/cycling wiki's, while at the same time opening up a more generic way to document network configuration type for data users including rendering.

There are significant advantages in maintenance load as well, but that's a bonus.

I hope this clears things up?  In terms of proposal, we propose one extra value "node_network" for the key "network_type". 
Nothing is changed, nothing is removed. So we think zero impact on the current base. It's up to renderers and other data users to make use of the extra tag.


Best Regards,

Andy




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

s8evq

On Tue, 3 Sep 2019 16:56:49 +0200, Peter Elderson <[hidden email]> wrote:

> Op zo 1 sep. 2019 om 12:35 schreef Andy Townsend <[hidden email]>:
>
> > On 29/08/2019 15:52, Peter Elderson wrote:
> > > LS
> > > With the arrival of cycling node networks, the Dutch, German and
> > > Belgian mappers decided to claim (hijack)  the network value rcn for
> > > those node networks. This exception was copied with the claim of
> > > network=rwn for the walking node networks.
> >
> > Would it be possible to try and describe in a bit more detail what has
> > happened, without using judgmental terms such as "hijack"?  I'd start
> > with a link helping people understand what a "cycling node network" is.
> >
>
> Sure. A node network consists of numbered nodes (signs) with short routes
> between pairs of adjacent nodes. Eg nodes 10, 35 and 22 with routes 20-35,
> 10-22 and 22-35, and then each of these nodes has other connections to
> other nodes.


Some pictures might make it more clear for somebody who has never heard of this system:

This is an example of a node: (in this case node 55) https://pretwerk.nl/wp-content/uploads/knopen-lopen.jpg

From that point, individual waymarks indicate the route to one of the connecting nodes (54, 91 and 56 in this case).
So, along the road between two nodes, you will then find this kind of signs:
https://www.anwb.nl/binaries/content/gallery/anwb/portal/wandelen/wandelroutes/soorten-routes/knooppuntroutes/wandelknooppunt_kvp.jpg


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

s8evq
In reply to this post by Peter Elderson
On Tue, 3 Sep 2019 16:56:49 +0200, Peter Elderson <[hidden email]> wrote:
> Tagging of regular cycle route relations is route=lcn for local routes, rcn
> for regional routes, ncn for national routes, icn for international routes.


You probably mean network=lcn instead of route=lcn


> I hope this clears things up?  In terms of proposal, we propose one extra
> value "node_network" for the key "network_type".
> Nothing is changed, nothing is removed. So we think zero impact on the
> current base. It's up to renderers and other data users to make use of the
> extra tag.

So hiking node network would still be tagged with network=rwn, but you would just add network_type=node_network.

If yes, then I find this a bad proposal. What is the difference between network=* and network_type=*

Do not choose network_type because it's the most easy solution!!!
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Peter Elderson
Thanks for the illustrations!

network=* gives geographical scope (local, regional, national, international) and transport mode (bicycle, foot, canoe, horse, mtb, ski, skate, ....)

network_type gives network configuration type (chain of ways; node_network=network of nodes&connections)

The network configuration type is applicable to all geographical scopes and all transport modes. By adding this as a separate tag the network=rXn tag is free again for regional routes. This applies in Nederland, Belgium and Germany. In other countries the tag network_type creates the option to register node networks in OSM if they are implemented, without reserving a mode/scope network=XXn tag which may be already in use for regular routes (conform the wiki's about routes).

Please feel free to offer other solutions!

Fr gr Peter Elderson


Op wo 4 sep. 2019 om 14:53 schreef s8evq <[hidden email]>:
On Tue, 3 Sep 2019 16:56:49 +0200, Peter Elderson <[hidden email]> wrote:
> Tagging of regular cycle route relations is route=lcn for local routes, rcn
> for regional routes, ncn for national routes, icn for international routes.


You probably mean network=lcn instead of route=lcn


> I hope this clears things up?  In terms of proposal, we propose one extra
> value "node_network" for the key "network_type".
> Nothing is changed, nothing is removed. So we think zero impact on the
> current base. It's up to renderers and other data users to make use of the
> extra tag.

So hiking node network would still be tagged with network=rwn, but you would just add network_type=node_network.

If yes, then I find this a bad proposal. What is the difference between network=* and network_type=*

Do not choose network_type because it's the most easy solution!!!
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

SimonPoole

Am 04.09.2019 um 15:59 schrieb Peter Elderson:
> Thanks for the illustrations!
>
> network=* gives geographical scope (local, regional, national,
> international) and transport mode (bicycle, foot, canoe, horse, mtb,
> ski, skate, ....)
You know what I'm going to point out.

The redundant coding of transportation kind in the the geographical
scope was a mistake, but is a done deed for cycling and hiking. BUT
there is no need to propagate repeating the mistake for every other
transportation mode, lets just stick with local, regional, national and
international these (historically I suspect that the values came from
direct tagging on ways,  lcn=yes and similar).



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Peter Elderson


Mvg Peter Elderson

> Op 4 sep. 2019 om 16:30 heeft Simon Poole <[hidden email]> het volgende geschreven:
>
>
>> Am 04.09.2019 um 15:59 schrieb Peter Elderson:
>> Thanks for the illustrations!
>>
>> network=* gives geographical scope (local, regional, national,
>> international) and transport mode (bicycle, foot, canoe, horse, mtb,
>> ski, skate, ....)
> You know what I'm going to point out.
>
> The redundant coding of transportation kind in the the geographical
> scope was a mistake, but is a done deed for cycling and hiking. BUT
> there is no need to propagate repeating the mistake for every other
> transportation mode, lets just stick with local, regional, national and
> international these (historically I suspect that the values came from
> direct tagging on ways,  lcn=yes and similar).

I agree with your point. Had I been around, I probably would have voted not to mix scope and mode in one tag. At the same time, the proposed tag for network configuration type does not change this, nor does it propagate it. So I would like to keep this a separate issue, and just talk about how to separate regular routes from node networks.

> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

s8evq
Why don't you continue to use network=* ? Invent a new value for network= instead of introducing a new, but confusing tag called "network_type".

I understand that using network_type would be easier. You just add the tag to the already tagged node networks that are currently using network=rwn.

But is introducing a new tag "network_type=" really the best solution? Or is it the easiest solution?

On Wed, 4 Sep 2019 16:44:58 +0200, Peter Elderson <[hidden email]> wrote:

>
>
> Mvg Peter Elderson
>
> > Op 4 sep. 2019 om 16:30 heeft Simon Poole <[hidden email]> het volgende geschreven:
> >
> >
> >> Am 04.09.2019 um 15:59 schrieb Peter Elderson:
> >> Thanks for the illustrations!
> >>
> >> network=* gives geographical scope (local, regional, national,
> >> international) and transport mode (bicycle, foot, canoe, horse, mtb,
> >> ski, skate, ....)
> > You know what I'm going to point out.
> >
> > The redundant coding of transportation kind in the the geographical
> > scope was a mistake, but is a done deed for cycling and hiking. BUT
> > there is no need to propagate repeating the mistake for every other
> > transportation mode, lets just stick with local, regional, national and
> > international these (historically I suspect that the values came from
> > direct tagging on ways,  lcn=yes and similar).
>
> I agree with your point. Had I been around, I probably would have voted not to mix scope and mode in one tag. At the same time, the proposed tag for network configuration type does not change this, nor does it propagate it. So I would like to keep this a separate issue, and just talk about how to separate regular routes from node networks.
>
> > _______________________________________________
> > Tagging mailing list
> > [hidden email]
> > https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Richard Fairhurst
In reply to this post by Peter Elderson
Peter Elderson wrote:

> The network values identify transport mode and scope of routes, and
> these "dimensions" also apply to node networks. We do not want to
> add another dimension (configuration type) to the network=*  
> values of routes.
>
> Instead, we are thnking about just adding a tag to identify segment
> routes as parts of a node network. The nodes themselves do not need
> this, since they ARE nodes and have a xxn_ref tag.
>
> In short, we are thinking to simply add the tag network_type=
> node_network (or network:type=node_network) to the node2node
> network routes.

I have a strong interest in this proposal. :) [1]

If I understand you rightly, a route like
https://www.openstreetmap.org/relation/1844941 would get an extra
network_type=node_network tag. Nothing else would change. (Correct me if I'm
wrong.)

You say "we don't want to add another dimension" but you are effectively
doing that; you're just doing it by adding a new tag rather than adding a
value. That's not _necessarily_ a problem but it would be better done in an
extensible way that might be useful for other tagging scenarios, rather than
special-casing this one scenario.

We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the
_importance_ of the route.

What we do not have is a tag to identify the _character_ and _purpose_ of
the route. All bicycle routes (except MTB) get lumped together as a generic
route=bicycle. This is increasingly a problem as routes are devised and
signposted for performance cycling, bikepacking, and so on. For example,
there are two new performance cycling routes in Wales which I'd like to map
(https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be
misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain.

You're proposing a tag called "network_type", but it's a tag for the route,
and what you're using it to describe is the character and purpose of the
route. (The network is already mapped in the network super-relation.)

So I'd suggest that instead of network_type=, you add route_type= .

This would achieve the same purpose; be semantically more appropriate; and
be extensible to other routes where "route=bicycle" alone does not
adequately capture the character and purpose of the route.

Richard
cycle.travel


[1] I believe cycle.travel is the only OSM-based router that includes nodes
in its turn-by-turn instructions, e.g.
https://cycle.travel/map?from=51.0623,2.8582&to=51.0913,2.8531 .
cycle.travel also has a few localised rules for rendering in the Netherlands
and Belgium to cope with the sheer density of the node network.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Peter Elderson
In reply to this post by s8evq
I think it's the best AND the easiest solution. 
Network configuration type is currently not tagged. Nederland, Belgium and Germany decided to use rcn exclusively for the cycle node networks. Later they copied that to rwn for the emerging walking node networks.
We now want to correct that, but we also want a clear difference between the network condfigurations. Then renderers and other data users can make the distinction. 

We have considered using another network=* value. But the transport mode is still in there, as is the geographical scope. So you would need extra values for all combinations of mode, scope and config. If yet another network config type emerges, you will need more network values. Every data user has to decode the values to know what's going on. While what we want is just to indicate that this particular rcn route is part of a node network. 

This is true for all transport modes (now and future) and for all geographical scopes, now and future. 

So we came to the solution that it is by far the most effective and at the same time the easiest solution to just add the information that a route is part of a node network in a separate tag. The bonus is that other network systems can be accommodated as well. E.g. some regions and some nature parks in Nederland have a "colour choice network", where you can follow a (self-planned) sequence of signposted coloured routes. 

The extra bonus of this solution is that currently tagged node network routes need no retagging, just addition of the information that they are part of a node network. This allows renderers and other data users to refine the display or handling of the existing rXn routes. 

We thought of network_type as a key. This is not a new key, it has some non-conflicting usage. We could introduce a new key as a namespaced variant: network:type=*.

If this is still confusing: feel free to suggest better names and values to indicate that a route belongs to a network system of the node variety.

Fr gr Peter Elderson


Op wo 4 sep. 2019 om 18:33 schreef s8evq <[hidden email]>:
Why don't you continue to use network=* ? Invent a new value for network= instead of introducing a new, but confusing tag called "network_type".

I understand that using network_type would be easier. You just add the tag to the already tagged node networks that are currently using network=rwn.

But is introducing a new tag "network_type=" really the best solution? Or is it the easiest solution?

On Wed, 4 Sep 2019 16:44:58 +0200, Peter Elderson <[hidden email]> wrote:

>
>
> Mvg Peter Elderson
>
> > Op 4 sep. 2019 om 16:30 heeft Simon Poole <[hidden email]> het volgende geschreven:
> >
> >
> >> Am 04.09.2019 um 15:59 schrieb Peter Elderson:
> >> Thanks for the illustrations!
> >>
> >> network=* gives geographical scope (local, regional, national,
> >> international) and transport mode (bicycle, foot, canoe, horse, mtb,
> >> ski, skate, ....)
> > You know what I'm going to point out.
> >
> > The redundant coding of transportation kind in the the geographical
> > scope was a mistake, but is a done deed for cycling and hiking. BUT
> > there is no need to propagate repeating the mistake for every other
> > transportation mode, lets just stick with local, regional, national and
> > international these (historically I suspect that the values came from
> > direct tagging on ways,  lcn=yes and similar).
>
> I agree with your point. Had I been around, I probably would have voted not to mix scope and mode in one tag. At the same time, the proposed tag for network configuration type does not change this, nor does it propagate it. So I would like to keep this a separate issue, and just talk about how to separate regular routes from node networks.
>
> > _______________________________________________
> > Tagging mailing list
> > [hidden email]
> > https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Peter Elderson
In reply to this post by Richard Fairhurst
Richard Fairhurst <[hidden email]>:
Peter Elderson wrote:
> The network values identify transport mode and scope of routes, and
> these "dimensions" also apply to node networks. We do not want to
> add another dimension (configuration type) to the network=* 
> values of routes.
>
> Instead, we are thnking about just adding a tag to identify segment
> routes as parts of a node network. The nodes themselves do not need
> this, since they ARE nodes and have a xxn_ref tag.
>
> In short, we are thinking to simply add the tag network_type=
> node_network (or network:type=node_network) to the node2node
> network routes.

I have a strong interest in this proposal. :) [1]

If I understand you rightly, a route like
https://www.openstreetmap.org/relation/1844941 would get an extra
network_type=node_network tag. Nothing else would change. (Correct me if I'm
wrong.)
 
You are correct. 
 
You say "we don't want to add another dimension" but you are effectively
doing that; you're just doing it by adding a new tag rather than adding a
value. That's not _necessarily_ a problem but it would be better done in an
extensible way that might be useful for other tagging scenarios, rather than
special-casing this one scenario.

We do want to add a new aspect: network configuration. We just do not want to add this new aspect into the network tag, because it already has two aspects in it: transport mode and geographical scope. Therefore we decided to just add the new information independent of the other two. 

This simply allows us (Nederland, Belgium and Germany) to return to the use of rXn as it was intended. We then no longer need the exception that rXn is a node network in these countries only, and a regular regional route (chain of ways) in the rest of the world.
 
We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the
_importance_ of the route.

More specific, it gives the transport mode and the geographical scope, including icn for international cycling routes. Same for hiking, and usage for other transport modes (horseriding, canoe, skating) is emerging, and so are regular (chain of ways) routes and node networks including special node network planners.
 
What we do not have is a tag to identify the _character_ and _purpose_ of
the route. All bicycle routes (except MTB) get lumped together as a generic
route=bicycle. This is increasingly a problem as routes are devised and
signposted for performance cycling, bikepacking, and so on. For example,
there are two new performance cycling routes in Wales which I'd like to map
(https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be
misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain.

You're proposing a tag called "network_type", but it's a tag for the route,
and what you're using it to describe is the character and purpose of the
route. (The network is already mapped in the network super-relation.)

That is not the idea. Maybe I wasn't clear. The idea is to add the network setup or configuration in a clear and unmistakeable way. 

You bring up an interesting point: the superrelation. The superrelations are containers of a mix of route relations and nodes but they don't give how these elements are connected. This is the case for both regular routes (think long distance, international, variants) and node network superrelations. So data users using routes would have to determine membership of a superrelation, then analyse the superrelation to find out whether a route is part of a node network, or part of another type of superrelation. 
At this time, local walking node networks are merging with provincial walking node networks and regional walking node networks into one big national walking node network with connections and branches to Belgian and German walking node networks. The orginal relatively small local node networks already were very difficult to maintain and to use, but on the cureent larger scale the are unmanageabe and unusable. 

Adding the information as a tag to the individual network routes solves this problem as well. 
 
So I'd suggest that instead of network_type=, you add route_type= .

This would achieve the same purpose; be semantically more appropriate; and
be extensible to other routes where "route=bicycle" alone does not
adequately capture the character and purpose of the route.


I disagree. The information is that the route is part of a particular network setup. This does not alter the route itself. It's not about the character of the route, it's about the configuration of the network it's a part of.
 
Richard
cycle.travel


[1] I believe cycle.travel is the only OSM-based router that includes nodes
in its turn-by-turn instructions, e.g.
https://cycle.travel/map?from=51.0623,2.8582&to=51.0913,2.8531 .
cycle.travel also has a few localised rules for rendering in the Netherlands
and Belgium to cope with the sheer density of the node network.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Warin
In reply to this post by Richard Fairhurst


On 5/9/19 2:42 am, Richard Fairhurst wrote:
Peter Elderson wrote:
The network values identify transport mode and scope of routes, and 
these "dimensions" also apply to node networks. We do not want to 
add another dimension (configuration type) to the network=*  
values of routes.

Instead, we are thnking about just adding a tag to identify segment 
routes as parts of a node network. The nodes themselves do not need 
this, since they ARE nodes and have a xxn_ref tag.

In short, we are thinking to simply add the tag network_type=
node_network (or network:type=node_network) to the node2node 
network routes.
I have a strong interest in this proposal. :) [1]

If I understand you rightly, a route like
https://www.openstreetmap.org/relation/1844941 would get an extra
network_type=node_network tag. Nothing else would change. (Correct me if I'm
wrong.)

You say "we don't want to add another dimension" but you are effectively
doing that; you're just doing it by adding a new tag rather than adding a
value. That's not _necessarily_ a problem but it would be better done in an
extensible way that might be useful for other tagging scenarios, rather than
special-casing this one scenario.

We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the
_importance_ of the route.

What we do not have is a tag to identify the _character_ and _purpose_ of
the route. All bicycle routes (except MTB) get lumped together as a generic
route=bicycle. This is increasingly a problem as routes are devised and
signposted for performance cycling, bikepacking, and so on. For example,
there are two new performance cycling routes in Wales which I'd like to map
(https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be
misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain.

You're proposing a tag called "network_type", but it's a tag for the route,
and what you're using it to describe is the character and purpose of the
route. (The network is already mapped in the network super-relation.)

So I'd suggest that instead of network_type=, you add route_type= .


    
'Type' does not add information. If the key is only to have one value .. why not use the proposed value as the key? 
node_network=yes/no ?  



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Peter Elderson
We have considered node_network=yes. But other network configurations are already present. We now map two network setups, but the default one (chained ways) is by no means uniform, and we have already seen colour choice networks. 
So all emerging network configurations would need a separate key. 

So it's more generic and future proof to use one key with values for different network setups. For now we only want to distinguish node_network from the rest, to free up rXn in Nederland, Belgium and Germany for the intended use. So we propose one value, but we want to facilitate the option for more network setups.

We've used network_type because it's an existing key. Very very low usage, though.
(network:type is used in one smaller network in Nederland, for a pilot, so that is not regular usage. To be removed if another solution is chosen. Still, network:type usage is higher than network_type)

Maybe the key should be network_setup=* or network_configuration=* ? Or the namespaced variants, network:setup=* or network:config=* ? 

For renderers and other data users the string does not matter very much as long as it's uniquely defined. They need to know for a particular route what setup it's part of, preferably by an attribute of the route itself. A renderer then can decide how to render different network configurations.

A node network planner needs to find the node network routes connected to a particular node. The safest way to know which routes to use and which not to use, is by looking at an attribute of the routes. 

A node network router also needs to distinguish exactly which ways to use, so has the same need.

Fr gr Peter Elderson


Op do 5 sep. 2019 om 07:00 schreef Warin <[hidden email]>:


On 5/9/19 2:42 am, Richard Fairhurst wrote:
Peter Elderson wrote:
The network values identify transport mode and scope of routes, and 
these "dimensions" also apply to node networks. We do not want to 
add another dimension (configuration type) to the network=*  
values of routes.

Instead, we are thnking about just adding a tag to identify segment 
routes as parts of a node network. The nodes themselves do not need 
this, since they ARE nodes and have a xxn_ref tag.

In short, we are thinking to simply add the tag network_type=
node_network (or network:type=node_network) to the node2node 
network routes.
I have a strong interest in this proposal. :) [1]

If I understand you rightly, a route like
https://www.openstreetmap.org/relation/1844941 would get an extra
network_type=node_network tag. Nothing else would change. (Correct me if I'm
wrong.)

You say "we don't want to add another dimension" but you are effectively
doing that; you're just doing it by adding a new tag rather than adding a
value. That's not _necessarily_ a problem but it would be better done in an
extensible way that might be useful for other tagging scenarios, rather than
special-casing this one scenario.

We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the
_importance_ of the route.

What we do not have is a tag to identify the _character_ and _purpose_ of
the route. All bicycle routes (except MTB) get lumped together as a generic
route=bicycle. This is increasingly a problem as routes are devised and
signposted for performance cycling, bikepacking, and so on. For example,
there are two new performance cycling routes in Wales which I'd like to map
(https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be
misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain.

You're proposing a tag called "network_type", but it's a tag for the route,
and what you're using it to describe is the character and purpose of the
route. (The network is already mapped in the network super-relation.)

So I'd suggest that instead of network_type=, you add route_type= .


    
'Type' does not add information. If the key is only to have one value .. why not use the proposed value as the key? 
node_network=yes/no ?  


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

s8evq
In reply to this post by Peter Elderson
I see that network:type=node_network has been added to the wiki:
https://wiki.openstreetmap.org/w/index.php?title=Tag:network%3Drwn&diff=next&oldid=1897551
https://wiki.openstreetmap.org/w/index.php?title=Tag:route%3Dbicycle&diff=next&oldid=1866174

Was there consensus on this in the end? I didn't follow the whole discussion.


On Thu, 29 Aug 2019 16:52:47 +0200, Peter Elderson <[hidden email]> wrote:

> LS
> With the arrival of cycling node networks, the Dutch, German and Belgian
> mappers decided to claim (hijack)  the network value rcn for those node
> networks. This exception was copied with the claim of network=rwn for the
> walking node networks.
>
> We are currently discussing in the three communities how to coreect this
> exception and return rcn and rwn to their intended use. To do that, we need
> another way to identify (members of) a route network as (members of) a node
> network.
>
> The network values identify transport mode and scope of routes, and these
> "dimensions" also apply to node networks. We do not want to add another
> dimension (configuration type) to the network=*  values of routes.
>
> Instead, we are thnking about just adding a tag to identify segment routes
> as parts of a node network. The nodes themselves do not need this, since
> they ARE nodes and have a xxn_ref tag.
>
> In short, we are thinking to simply add the tag network_type=node_network
> (or network:type=node_network) to the node2node network routes. Nothing
> else has to change, which also means that renderers and data users who
> don't change anything, will not notice anything! But if they want they can
> make use of the separation and handle node networks different than non-node
> networks.
>
> Notice that no new key or value is proposed here. If new network config
> types arise, a new value for network_type can accommodate that.The method
> is applicable for all transport modes and geographical scopes.
>
> Thoughts, anyone? What did we forget? Shoot!
>
> Fr gr Peter Elderson
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Peter Elderson
Sorry for the delay, I meant to post this earlier. My bad! 
We have discussed the arguments again in the Dutch OSM forum. The Belgium OSM forum did not respond, except for vmarc who took active part in the Dutch forum discussion. The German OSM forum had some positive response but no specific details. They have discussed the same problems earlier.

The only new argument from this tagging list was that the key network_type or network:type is not very clear; it does not show what the difference is with the key network. I thought that was a valid point, I thought of two alternatives but mappers thought those were wrongfooting new mappers and that's even worse than confusing them.

I am sorry to say that some mappers already had started to add the new tag to cycle node networks even before we reached consensus. 

The Dutch consensus (with a touch of expert Belgian input and no objection from Germany) is:

We add the tag network:type=node_network to all the junction nodes, to all the node2node route relations, and the node network relation of the node network.

This applies to all recreational node networks: all transport modes, and all geographical scopes.
Note that the key is not new. There already was some usage, mainly in Spain, thought it wasn't documented. We had a quick look, it doesn't conflict with our use. 

When done, rXn in itself is no longer reserved for node networks. Node networks can be separated easily and completely from linear routes. This means tagging regular regional routes (linear routes) will once again be possible in Nederland, Belgium and Germany. We actually have quite a few of those, the are now tagged as national routes even when they are entirely within a particular region.
The exception has been undone.

I will be happy to answer any questions arising from this.

Fr gr Peter Elderson


Op di 10 sep. 2019 om 19:49 schreef s8evq <[hidden email]>:
I see that network:type=node_network has been added to the wiki:
https://wiki.openstreetmap.org/w/index.php?title=Tag:network%3Drwn&diff=next&oldid=1897551
https://wiki.openstreetmap.org/w/index.php?title=Tag:route%3Dbicycle&diff=next&oldid=1866174

Was there consensus on this in the end? I didn't follow the whole discussion.


On Thu, 29 Aug 2019 16:52:47 +0200, Peter Elderson <[hidden email]> wrote:

> LS
> With the arrival of cycling node networks, the Dutch, German and Belgian
> mappers decided to claim (hijack)  the network value rcn for those node
> networks. This exception was copied with the claim of network=rwn for the
> walking node networks.
>
> We are currently discussing in the three communities how to coreect this
> exception and return rcn and rwn to their intended use. To do that, we need
> another way to identify (members of) a route network as (members of) a node
> network.
>
> The network values identify transport mode and scope of routes, and these
> "dimensions" also apply to node networks. We do not want to add another
> dimension (configuration type) to the network=*  values of routes.
>
> Instead, we are thnking about just adding a tag to identify segment routes
> as parts of a node network. The nodes themselves do not need this, since
> they ARE nodes and have a xxn_ref tag.
>
> In short, we are thinking to simply add the tag network_type=node_network
> (or network:type=node_network) to the node2node network routes. Nothing
> else has to change, which also means that renderers and data users who
> don't change anything, will not notice anything! But if they want they can
> make use of the separation and handle node networks different than non-node
> networks.
>
> Notice that no new key or value is proposed here. If new network config
> types arise, a new value for network_type can accommodate that.The method
> is applicable for all transport modes and geographical scopes.
>
> Thoughts, anyone? What did we forget? Shoot!
>
> Fr gr Peter Elderson
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

mesh bicycle network

Hubert87
Hi,

i have stumbled over the post about rcn and cycling node networks and
was wondering if you guys might have a proposal for primary bicycle
route mesh network relation(s) like this one
https://www.openstreetmap.org/relation/3585265, which is in Bremen, Germany.

It is neither a cycling node network nor a classical bicycle route but a
set of
guideposts(https://www.mapillary.com/map/im/AlXYW3arx59dkSlruUsWjg)
showing poi destinations and distances completed with addition smaller
signs (https://www.mapillary.com/map/im/9pqoiH4eH4o7Ieh6IXRnfg) in
between guideposts pointing in the right direction.

All classical bicycle routes seem to be part of this network, but it
contains more routes. Additionally these routes do not have a beginning
or end or a closed loops, but are more a kind of mesh like the node
network; except for the nodes.

Also, as far a I can tell, the main guidepost are sorted into 5 regions
(Nord, Süd, Ost, West, Mitte), which is coded in the small print
(mi=mitte) on the guideposts, as can be seen in the first example picture.

There is a discussion in the german forum
(https://forum.openstreetmap.org/viewtopic.php?pid=762131) about
deleting these relations and just tagging its highways with lcn=yes.
But I'd really looking for a different solution.
Can someone point me to a possible solution?

Yours
Hubert87



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: mesh bicycle network

Peter Elderson
I would say it is a system of preferential cycleroutes to different destinations. It resembles the system of preferential truck routes in Amsterdam. 

It is a system, and it's visible on the ground. The arrow signs create a route to the next signpost in the chosen direction. If there is agreement that this actually is something worth mapping, I don't see a problem there. 

The network:type=* tag creates the option to add network-systems for all transport modes. If a clear value for this network:type can be agreed upon, I see no problem there either.

That's my own opinion. Since the Dutch route mappers came up with the network:type tag to explicitly map network systems (i.c. node_network), and since we have discussed how to tag a preference route system for trucks in Amsterdam last year, I will ask on the Dutch OSM forum how they feel about this idea. 

Fr gr Peter Elderson


Op do 12 sep. 2019 om 00:04 schreef Hubert87 <[hidden email]>:
Hi,

i have stumbled over the post about rcn and cycling node networks and
was wondering if you guys might have a proposal for primary bicycle
route mesh network relation(s) like this one
https://www.openstreetmap.org/relation/3585265, which is in Bremen, Germany.

It is neither a cycling node network nor a classical bicycle route but a
set of
guideposts(https://www.mapillary.com/map/im/AlXYW3arx59dkSlruUsWjg)
showing poi destinations and distances completed with addition smaller
signs (https://www.mapillary.com/map/im/9pqoiH4eH4o7Ieh6IXRnfg) in
between guideposts pointing in the right direction.

All classical bicycle routes seem to be part of this network, but it
contains more routes. Additionally these routes do not have a beginning
or end or a closed loops, but are more a kind of mesh like the node
network; except for the nodes.

Also, as far a I can tell, the main guidepost are sorted into 5 regions
(Nord, Süd, Ost, West, Mitte), which is coded in the small print
(mi=mitte) on the guideposts, as can be seen in the first example picture.

There is a discussion in the german forum
(https://forum.openstreetmap.org/viewtopic.php?pid=762131) about
deleting these relations and just tagging its highways with lcn=yes.
But I'd really looking for a different solution.
Can someone point me to a possible solution?

Yours
Hubert87



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12