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

Peter Elderson pelderson at gmail.com
Wed Sep 4 18:40:49 UTC 2019


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 <s8evq at runbox.com>:

> 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 <pelderson at gmail.com>
> wrote:
>
> >
> >
> > Mvg Peter Elderson
> >
> > > Op 4 sep. 2019 om 16:30 heeft Simon Poole <simon at poole.ch> 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
> > > Tagging at openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/tagging
> >
> > _______________________________________________
> > Tagging mailing list
> > Tagging at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> _______________________________________________
> 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/20190904/791a8e60/attachment.html>


More information about the Tagging mailing list