[Tagging] Feature Proposal - RFC - value 'basic_network' - cycle_network?

[Minh Nguyen]

Vào lúc 16:48 2021-11-21, JochenB đã viết:
> Am 21.11.2021 um 18:30 schrieb stevea:
>> 3) Use cycle_network=* tagging with sane, planned, sensible values that have achieved consensus across a country (or countries, or a region, however "region" is defined and used "there").
>>
>> Again: this 'basic_network' seems like a whacky branch of mathematics being invented when "we already know math."
> 
> The basic network is not a design I designed for OSM. It is a 
> construction outside, in reality. There is a network there that is 
> officially recommended for hiking or everyday cycling. In addition, 
> there are special route recommendations in this network (themed routes) 
> and / or the node-based signposting (cycling by numbers).
> 
> I cannot explain why this is understood here as a complex model. If it 
> is complex, it is because in reality it is complex. But it's not for me. 
> It's just three things that we should put separately. There is already a 
> tag for one of the three things that the spade calls a spade. I suggest 
> extending this tag to include the others by their names.
> 
> I think I have to revise my description of basic network in the proposal 
> because it is misleading. Perhaps it is also because it is not common in 
> other countries for the state to set up such a well thought-out bicycle 
> network with three types of signage in one system. In many countries the 
> bicycle is just a piece of sports equipment. It is hardly a transport 
> device or everyday means of transport. The signposting systems are 
> correspondingly simple.
> 
> Anyone who is familiar with the local system will quickly understand 
> which of them belong to the basic network, which to the route 
> recommendation and which to the node network. Here is a picture where 
> all 3 signage systems meet at a signpost:
> 
>     File:Guidepost_basic_network_and_node_network_and_route_recommendation.jpg <https://wiki.openstreetmap.org/wiki/File:Guidepost_basic_network_and_node_network_and_route_recommendation.jpg>
> 
> But there are also many sections where there is only the basic network. 
> The proposal is intended to enable them to be presented differently.

Thank you for this photo, and to Volker for the more extreme one. I'm 
still not 100% sure I've wrapped my American occasional cyclist brain 
around this system, but I don't think cycle_network=* on route relations 
has completely solved U.S. bike-oriented wayfinding either.

I remember the chaos of bike route signing in Ohio during the '90s and 
2000s, when the state posted one route numbering scheme but an array of 
local park managers and private groups posted unofficial bike trail 
names, numbers, and blazes that all overlapped in fun ways. This tended 
to happen on dedicated bike paths like rail trails, where park managers 
were more tolerant of unofficial signage. There were unofficial 
on-street routes too, but those mostly relied on published guides.

Eventually, park managers reined in the signage using a system of 
integrated destination/distance signs that must have been inspired by 
node network signs in Europe. [1][2][3][4] (However, the number at the 
top is a route number; we still don't number nodes.) Recently, a 
national numbering system has been overlaid upon the existing system, so 
we'll probably see some extra shields bolted onto the side soon.

I'm also reminded of the wayfinding systems that various cities have 
introduced for bike boulevards. [5] If I'm not mistaken, bike boulevards 
are conceptually similar to Dutch cyclestreets, with a focus on physical 
infrastructure rather than any legal provisions. They have a one-to-many 
relationship to streets and often serve as connectors between dedicated 
bike paths. There are distance/destination signs at junctions between 
bike boulevards; at other intersections where the bike boulevard turns, 
there's a simpler arrow sign. [6]

So far, the U.S. community has a well-established scheme for tagging 
named and numbered routes, as Steve has explained. There's less 
certainty about undifferentiated local bike "routes" and bike 
boulevards. Some mappers have experimented with joining the whole 
network of local bike routes into a type=network network=lcn relation 
[7], but routers probably wouldn't find a graph-shaped relation to be 
very useful.

cyclestreet=yes seems to be the most popular way to tag bike boulevards, 
despite some apparent misgivings about semantic differences, but that 
alone doesn't allow us to represent a bike boulevard at a higher 
conceptual level than the individual roadways. There'd be no way for a 
data consumer to tell whether it's looking at a bunch of connected bike 
boulevards or just one very wiggly one.

The German basic network seems to have a distinct emphasis on 
destinations. No one has bothered to map destination:bicycle=*, 
destination:symbol:bicycle=*, etc. in the U.S. yet, but then again, the 
destinations aren't as important here. In addition to whatever you do 
with route relations, perhaps you could also map some destination_sign 
relations. In principle, a router could apply the same heuristics for 
"follow the signs to" instructions in a car routing profile.

[1] 
https://commons.wikimedia.org/wiki/File:Kokosing_Gap_Trail_at_Mount_Vernon_Avenue,_Mount_Vernon,_Ohio.jpg
[2] 
https://commons.wikimedia.org/wiki/File:Closeup_of_wayfinding_sign_on_the_Great_Miami_River_Recreational_Trail_at_Rip_Rap_Road,_Huber_Heights,_Ohio.jpg
[3] https://www.traillink.com/trail-photo/iron-horse-trail-%28oh%29_159176/
[4] https://www.traillink.com/trail-photo/dayton-kettering-connector_163629/
[5] 
https://nacto.org/publication/urban-bikeway-design-guide/bikeway-signing-marking/bike-route-wayfinding-signage-and-markings-system/
[6] 
https://www.cityofberkeley.info/Public_Works/Transportation/Bicycle_Boulevard_Signage_System.aspx
[7] https://www.openstreetmap.org/relation/2815833

-- 
minh at nguyen.cincinnati.oh.us