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

[Sebastian Gürtler]

(Sorry sent only personally...)


Am 17.11.21 um 19:43 schrieb Sarah Hoffmann:
> It just seemed to be the right thing to do. After all it made the
> routes instantly visible on all hiking maps. Ten years into mapping the
> network, here is the most important lesson I have learned:
>
> Using relations to model the network was a Big Mistake.
>
> Relations are complicated to handle. They don't fit the concept. And they
> will cause confusion and disputes between mappers. (Feel free to read
> the most recent fallout within the Swiss community:
> http://lists.openstreetmap.ch/pipermail/talk-ch/2021-June/010972.html
> The gist of it is that mappers will try to define routes in the network
> leading to different ideas of how the network should be built.)

I don't agree that they are really complicated to handle. I think, it is
unavoidable that there are variants in how taggings are used, no
difference whether you use relations or simple ways.

I saw the rules from Switzerland, when one should see a route as a route
"in sense of osm", where I can extrapolate the discussions behind that.
I read similar criticism from Austria but got the impression that it was
quite little from Germany in relation to the number of possible mappers.
It may depend on the different infrastructure of the bicycle networks in
the countries. So I think there might be relevant regional differences.
(That is surely an issue - tagging the network in Bielefeld has
completely different problems than in the neighboured district Herford
and the practise of guideposting has another air in the district
Gütersloh in the west... so I won't be surprised).

> We model the road network with ways with a highway=* tag. That is simple
> and works extremely well.

The road network has a completely different structure compared to the
bicycle network. The bicycle network is using a broad set of ways of
different kinds that may be also designated footpaths, sometimes even
stairs where you have to dismount, paths to big primary roads (then
mainly as sidepath that even needn't to be mapped in every case). The
ways have very little in common. And you can have different local
bicycle routes and networks which historically coexist and would need
different additional taggings.

> For the guideposts we have
> destination relations. I strongly recommend to do exactly the same for
> cycling/hiking.
The current guidepost-relation is very difficult to transfer to the
bicycle system where at split nodes over several locations in an area of
sometimes about 100 m in diameter with sometimes quite ambiguous
relation to ways (visible from several directions sometimes conflicting
information on it...). This would be very complicated to "tag what is on
the ground".  And it is in contrast to the roads for cars not clear
which way the route will take, there are usually branches which have no
guideposts but route markers without information about any destination.
You will still need this information, most easily from a route relation.

> Invent a new tag bike_way=primary/secondary/whatever
> and pedestrian_way=primary/secondary/whatever and put that on the
> roads where the basic network goes over. Use the existing destination
> relations for the guideposts and you have everything in your
> infrastructure
> that you need.

There is no hierarchy of the ways but existing parallel systems in the
bicycle networks, the defining of the "whatever" would precipitate a lot
of discussions an inconsistency, I'm afraid.

Finally working with relations is from my mapping perspective still the
easiest and simplest way to get around with the situation that I find on
the streets.

Sebastian