[Tagging] Feature Proposal - RFC - value 'basic_network' for keys 'network:type', 'lcn' and 'lwn'

Sebastian Gürtler sebastian.guertler at gmx.de
Fri Nov 19 06:45:04 UTC 2021


Am 19.11.21 um 01:03 schrieb JochenB:
> Am 16.11.2021 um 08:09 schrieb Sebastian Gürtler:
>>
>> I think instead of the basic_network tag it may be possible to use
>> cycle_network=DE:xyz (unique tag like "official" or just the code for
>> the state signalling that it is the governmental network) and
>> noname=yes. This also implies the possibility to create basic routes
>> just by tagging cycle_network=DE:xyz without using a name=* tag which
>> I would prefer because the network system is changed quite frequently
>> and new named routes are added (it is very simple, they just add
>> route logos to the direction signs). So one doesn't need to remove
>> possible noname=yes tags on the way if a new named route is made up.
>>
> The aim is to distinguish the (mostly) tourist routes from the other
> hiking and cycling networks provided with signposts. I see two main
> use cases:
>
> A) One user wants to know where cycling / hiking is officially
> recommended (basic network). In the German cycling network, these can
> be recognized by the destination signposts with place names and
> intermediate signposts with arrows. The user wants to recognize these
> paths in order to prefer them when navigating
>
> B) The other user wants to follow a certain signposted route
> recommendation (in Germany: symbols)
>
I think, the problem lies a bit in the approach. These two points are
possible intentions of the user. I talk about the representation of the
situation on the ground.

The situation on the ground is quite different for hiking and the
cycling network. The cycling network has official guidelines that are
introduced for all states in Germany and the districts and communities
are more or less bound to follow these rules. The hiking networks have
much more freedom.

The cycle network has no discrimination between the tourist routes and
"other routes". There is one network.


For example: Destination orientated signposting: I start at Bielefeld
Hauptbahnhof and follow the Guidepost to "Spenge" (you can do this
easily with waymarkedtrails.org, with a quite strong zoom you can click
all guideposts and get the inscriptions), the nodes with branches are:

Start: "Spenge 17 km to south". 6 route inserts: 08, Pudding, Fußball,
Teuto-Senne, Weser-Lippe, Hellweg-Weser [Other branches on the direction
signpostes from this point lead to Lage, Bad Salzuflen, Herford,
BI-Schildesche]

Node 08: "Spenge 17 km to west", 3 route inserts: 15, Pudding,
Weser-Lippe [Branches: Gütersloh, Werther, Campus Bielefeld, Altstadt
(+backwards directions)]

https://www.openstreetmap.org/node/7554134683 Guidepost: Spenge 17 km
NE, 3 route inserts: 15, Pudding, Weser-Lippe [Branches: BI-Babenhausen,
BI-Gellershagen]

https://www.openstreetmap.org/node/8754195177 Guidepost: Spenge 16 km N,
3 route inserts: 15, Pudding, Weser-Lippe [SchücoArena, Siegfriedsplatz]

Node 15: Spenge 16 km N, 5 route inserts: Weser-Lippe, Pudding,
Romanzen, Aufspüren!, 11 [Obersee, Ravensberger Park]

*https://www.openstreetmap.org/node/7554134680 Guidepost: Spenge 16 km
N, % route insert (basic_network:
https://www.openstreetmap.org/relation/12622099) [BI-Babenhausen, Nordpark]
*

*https://www.openstreetmap.org/node/8361368997 Guidepost: Spenge 15 km
NW, % route insert (basic_network:
https://www.openstreetmap.org/relation/12800588) [Obersee,
BI-Schildesche, Campus Bielefeld, Nordpark]
*

https://www.openstreetmap.org/node/7573351545 Guidepost: Spenge 14 km N,
1 route insert: 41 (part of relation with network:type=node_network)
[Campus Bielefeld, BI-Gellershagen]

*https://www.openstreetmap.org/node/8361368996 Guidepost: Spenge 14 km
N, % route insert (basic_network:
https://www.openstreetmap.org/relation/12622100) [Obersee, BI-Schildesche]
*

*https://www.openstreetmap.org/node/7573351551 Guidepost: Spenge 13 km
N, % route insert (basic_network:
https://www.openstreetmap.org/relation/12656818) [BI-Großdornberg,
BI-Babenhausen, Obersee, BI-Schildesche]
*

Node 98: Spenge 13 km N, 3 route inserts: 03, Silhouetten, Weser-Lippe
[BI-Großdornberg, BI-Babenhausen, Obersee, BI-Schildesche]

Node 3: Spenge 11 km N, 4 route inserts: 04, Malerisch, Engel,
Weser-Lippe [BI-Großdornberg, BI-Babenhausen]

Node 4: Spenge 11 km N, 3 route inserts: 42, Engel, Weser-Lippe
[BI-Schildesche, Moorbachtal marked as "leisure route" BI-Schildesche
also backwards]

Node 42: Spenge 8.7 km N, 1 route insert: 51 [BI-Jöllenbeck]

*https://www.openstreetmap.org/node/8663160568 Guidepost: Spenge 8.5 km
W, % route insert (basic_network:
https://www.openstreetmap.org/relation/12621890) [BI-Schildesche,
BI-Vilsendorf]*

*https://www.openstreetmap.org/node/8399999055 Guidepost: Spenge 7.9 km
N, % route insert (**basic_network:
https://www.openstreetmap.org/relation/12621890) *(branch at this place
without end of relation! nowadays I avoid that) [Enger, Pödinghausen]

https://www.openstreetmap.org/node/8399999054 Guidepost: Spenge 7.6 km
W, 4 route inserts 07,06, Engel, Weser-Lippe [BI-Schröttinghausen,
BI-Jöllenbeck Ortsmitte]

https://www.openstreetmap.org/node/8663160567 Guidepost: Spenge 7.3 km
W, 1 route insert 07 [Enger, Pödinghausen]

Node 07: Spenge 6.5 km, 3 Route inserts: History 1, Herford 6, Wittekind
[Werther, Häger]

*https://www.openstreetmap.org/node/7700786088 Guidepost: Spenge 6.3 km,
% route insert (basic_network:
https://www.openstreetmap.org/relation/12691435) [Enger, Westerenger]
*

*https://www.openstreetmap.org/node/8790620652 Guidepost: Spenge 4.7 km,
% route insert (basic_network:
https://www.openstreetmap.org/relation/12797077) [Enger, Pödinghausen]
*

*https://www.openstreetmap.org/node/8790620655 Guidepost: Spenge 3.4 km,
% route insert (basic_network:
https://www.openstreetmap.org/relation/12797078) [Werther, Häger]
*

*https://www.openstreetmap.org/node/8790620657 Guidepost: Spenge 3.1 km,
% route insert (basic_network:
https://www.openstreetmap.org/relation/12797079) [Enger, Westerenger]
*

*https://www.openstreetmap.org/node/8790620658 Guidepost: Spenge 2.7 km,
% route insert (basic_network:
https://www.openstreetmap.org/relation/12797080) [Werther, Häger,
Westerenger]
*

*https://www.openstreetmap.org/node/8790620659 Guidepost: Spenge 1.8 km,
% route insert (basic_network:
https://www.openstreetmap.org/relation/12797081) [Werther, Häger]
*

*https://www.openstreetmap.org/node/7009821694 Guidepost: Spenge 1.3 km
E, % route insert (basic_network:
https://www.openstreetmap.org/relation/12852976) [Werther, Häger]
*

Arrived. What helps in discrimination between the route orientated
guidance and destination orientated guidance? Mainly the following of
the destination signs, not the type of the relation. BUT: To follow
them, the existence of the relations is essential. Guideposts are not
sufficient if you look at the map where the routes go.

Jochen, just to understand your proposal better: What exactly would be
your suggestion for tagging the parts of this continuously signposted
way from Bielefeld main station to Spenge.


> The basic network and signposted route recommendations are usually
> mapped in OSM with route relations. Both often occur simultaneously.
> Therefore, both must be distinguishable from each other in order to be
> able to represent them differently.
>
> 'noname = yes' describes a characteristic that applies to all
> connections in the basic network. That sounds good at first.
> Unfortunately, it can also apply to route-based signposting. Sometimes
> these routes only have a symbol and no name. This is not uncommon,
> especially on hiking routes. Therefore, I find 'noname = yes'
> unsuitable to differentiate between the various network layers with
> their guidpost types. The lack of a symbol is also not enough. Often
> the basic network also has a uniform symbol for the entire network. In
> the German cycling network, for example, it is the green or red
> bicycle. It is the red line on the Swiss hiking network.
>
I don't think of the tags in a 100% literally sense at all. The most
bicycle routes only have a symbol at their route inserts without any
text and have still a name (which is written elsewhere), we had the
funny discussion in the forum where someone found a lot of citations
that proved that "3" can't be a name of something because it's a number
but "three" could be, because it would be written with letters. And I
admit, that it would be a free interpretation to use "noname=yes" in the
meaning of: this route is complete in its description even without a
name, regardless whether it is a part of a bigger route which has a
name. It would be just a way to avoid the introduction of a new tag
without giving up the amount of information.

The new tag "basic_network" would otherwise have the advantage not to be
confused with previous definitions of a tag that's already in use.

> In principle, 'noname=yes' only describes a symphtom and not the heart
> of the matter. It's a bit like tagging 'sign_color=blue' instead of
> 'highway=motorway'. I find that unsatisfactory. Why not call the child
> by name?
>
I repeat myself: In the case of the cycling network there are no
specific "basic" routes, there is no heart of the matter in it. The
routes are all equivalent and it is just by chance and decision of the
tourism departments which ways of the network they want to recommend as
a touristic route and which not - or if they want to extend the network
for whatever purpose.
>
> The question now is, how do you classify the route relations in order
> to best reach the goal?
>
> I see several possibilities for classifying the networks:
>
> *The spatial extent (established):* local / regional / national /
> international
>
>     For this, the 'network=l*n/r*n/n*n/i*n' has prevailed.
>
>     This becomes difficult with close-knit networks. The individual
>     links in the network are often short. Since the networks are
>     linked to neighboring networks, the spatial extent of the entire
>     network can often not be clearly determined, sometimes it is very
>     large, up to national.
>
>     In Germany, this is different in every district (lcn: Relation
>     Radverkehrsnetz NRW, Kreis Paderborn (222581)
>     <https://www.openstreetmap.org/relation/222581> ; rcn: Relation
>     Radverkehrsnetz NRW, Kreis Siegen-Wittgenstein (124706)
>     <https://www.openstreetmap.org/relation/124706>). Here, too, a
>     uniform approach would be desirable.
>
>     The goal is not reached.
>
> *The administrative assignment (partially established):*
> <country>:<state>:<destrict>:<municipality>.
>
>     In Germany, this is usually mapped using parent and child network
>     relationships, starting with the federal state. In addition, there
>     is an "invented" 'ref' value on the routes, e.g. 'ref=NRW'.
>
>     I would like to establish 'hiking_network / cycle_network =
>     <country>: <state>: <destrict>: <municipality>'
>
>     The goal is not achieved with this.
>
> *External characteristics (partly established):* e.g. 'symbol=no',
> 'name=no', 'no_ref=yes'.
>
>     The goal is not achieved with this, because the desired
>     distinction is not always clearly possible with these values, see
>     above.
>
> *Structural properties (partially established)* such as the layer /
> form of the network: e.g. 'basic_network', 'node_network',
> 'line_network'; 'circular_route', 'honeycombs'.
>
>     There is already an established key with 'network:type=*', but so
>     far only the one value 'node_network'. New values need to be
>     introduced.
>
>     For me, 'basic_network' is a simple network of connections with
>     associated marking / signposting and connected nodes.
>
>     The goal can be achieved very well.
>
> *The way users are guided (not established):* 'destination_guided',
> 'symbol_guided', 'number_guided', 'colour_guided'.
>
>     A new key would have to be found for this.
>
>     The goal can thereby be achieved for the German application cases.
>
>     In other countries, however, the basic network can only be marked
>     with symbols without any destination signs. Then it doesn't work
>     anymore.
>
> *The target group for signposting (not established):* 'touristic',
> 'workaday_traffic', 'rehabilitation'.
>
>     I don't know a key for that either.
>

>     The challenge here is that the signposting actually helps everyone
>     and it is often not clear who it is aimed at.
>
This information is not given by the signposting in the bicycle routes.
It would be completely based on fiction! (Only the symbol with the tree
which occurs quite seldom and indicates routes with such a difficult
terrain that you won't use it with racing bikes)
>
>     The goal cannot therefore be achieved.
>
The goal is achieved by evaluating the destination signs. If you want a
destination based travel then you use the destination signs, if you go
for a route orientated touristic approach then you use the routes.

If you want to travel to destinations by nice touristic routes, you need
a map and route suggestions. Differentiation between touristic
destination signposting and just fast destination signposting is not
supported with the exception of the differentiation by the route symbols
where you sometimes can decide between leisure route and normal route to
the same destination or you can decide whether to take a strong incline
or not.


Am 19.11.21 um 01:56 schrieb JochenB:
> In almost every cycling concept of the German federal states it is
> stated that they want to create a network of ways that are well suited
> for cycling and that are provided with standardized signposting. The aim
> is to promote cycling in general. That is the basic network.
>
> In addition, tourist routes are created and marketed with the aim of
> getting tourists to travel along them, relax and spend money.
>
> Both are already recorded in many countries and are visible on the maps.
>
> The only problem is that both were recorded with the same tagging scheme.

... this is no surprise, as they are signposted with the same scheme!
The tourist routes are not an addition but are integrated in the other
system.

The real difficulty is that there are for historical reasons still
routes that don't fit completely in the "new" system. In the guidelines
for the state NRW these type of signposting is explicitely declared as
deprecated. I don't know exactly the details for the other states, as I
haven't had the time to find, read and evaluate them all.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211119/9724031a/attachment-0001.htm>


More information about the Tagging mailing list