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

Sebastian Gürtler sebastian.guertler at gmx.de
Mon Nov 15 21:49:54 UTC 2021


Am 15.11.21 um 21:37 schrieb stevea:
> OK, if there are "1)" (conflicting taggings), then fix / harmonise this tagging.  That might seem ambitious, but I'm certain it could be done.  You'd be undoing damage to the values of a tag, not re-inventing what appears to be a correct (or even THE correct) tag mechanism for what you are trying to do — it already seems to exist as cycle_network=*, but you say that it has been "misused" (or poorly coordinated in Germany).  I don't point any fingers of blame here, OSM is a big project with "many chefs baking the pie," but when such blurring occurs, it isn't correct to re-invent the wheel when there is a wheel that seems to do what you wish right now.
>
> The tag does allow for a route to be a member of multiple networks, simply semicolon (;) separate the values for as many values as the route is a member.
Fine, I didn't know that.
> This seems like the correct solution, but it has been "muddied" in Germany.
;-) That's my impression too. It is no surprise that there is no German
page for the cycle_network-key and that the key cycle_network isn't
mentioned at all neither in the German instructions for the tagging of
bicycle routes nor for bicycle networks. (Only suggestion is to use
network=lcn/rcn ... which is not really useful for the germanwide
network with very local aspects...)
> (I've sort of been watching the taginfo values in Germany over the years as I've mildly updated the cycle_network wiki page, but I agree with you that it seems messy — and from California, I seriously lack the insight of the specifics of what is needed to fix these.  However, the GENERAL concepts of implementing the apparently-multiple-hierarchies that would be required in the "value side" of what Germany's cycle_network tags might become someday (it seems like a medium-large project, but not so huge is can't be done) — well, the cycle_network tag seems very well-suited:  it is hierarchical, allows multiple values and fits in perfectly with the semantics you wish to capture.
>
> SteveA

Thanks for your encouraging...

Am 15.11.21 um 22:05 schrieb Peter Elderson:
> Maybe my misunderstanding - I thought cycle_network=<ref or code>
> denotes a collection of individual routes such as numbered or named
> routes between and along deliberately picked locations. So they
> resemble themed routes, together covering a certain area with a
> specific type of routes, where the main idea is that you pick one
> route and follow that. Not hard infrastructure, although the operator
> would probably call it a network infrastructure!

For the thing I am looking for cycle_network fits quite well. Quite in
whole Germany you have the routes sharing nearly the same route marker

Official route marker bicycle (NRW) (can also be green) and the same
guideposting system.

They are easily recognizable and include unnamed routes. At least for
these Jochen suggested the tag basic_network.

>
> As I understand it, the idea here is to tag all the connections
> between all the guideposts as route relations. All other higher order
> routes and networks could then e.g. re-use these chunks for their own
> purpose. Is that the idea? I am still searching for purpose.

Initially it was only a practical aspect during checking the local
routes. I found relations for each district with all unsorted ways
belonging to the official network. There were in fact completely
outdated. Lots of new routes and the same amount of routes that have
been abandoned. I started to correct the routes belonging to the
numbered node network of Bielefeld according to the system applied in
the Netherlands and being analyzed with knooppuntnet.nl. Afterwards I
tried to correct the other routes (unnamed and named but all under the
same system) and had big difficulties to identify the parts of the
network that I have checked already. So I made single routes between the
nodes in analogy to the numbered node network, that have just one start
and one endpoint which I could tag with survey:date=xyz.

The purpose of splitting the big network relations with unsorted ways is
therefore 1) better maintainability of the rapidly changing network 2)
make the data usable for routing applications like knooppuntnet.nl 3)
creating a base to tag the signposted features of the route that are
only given at start end end nodes (described in the guidelines: there
are logos for former railway routes, leisure routes, fast bicycle
routes, routes with strong incline/decline) which could be rendered and
help to chose a specific route depending on the intention of the
cyclist. 4) You also could imply that there won't be a branch if you
take the route from start to end - there are places where routes of a
different (e.g. european or non official local) network cross the
official network, where the route markers are placed in a way that the
aren't visible from the other network. (e.g.
https://cycling.waymarkedtrails.org/#route?id=12893830 crossing the
European EV2/D3/R1).

(The splitting of the big network relations is not really the core idea
of the proposal for the tag basic_network).

Sebastian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211115/af3aa5a1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Beispiel_Zwischenwegweiser_Radverkehrsnetz_NRW.jpg
Type: image/jpeg
Size: 19015 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211115/af3aa5a1/attachment-0001.jpg>


More information about the Tagging mailing list