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

[JochenB]

If I understand you correctly, you are suggesting exactly what we have
been doing for over 10 years or are currently doing. I'm happy about
that, because I had the feeling that we were very far apart.

Am 22.11.2021 um 20:56 schrieb stevea:
> But for the last time, we have the ingredients to bake this cake without inventing new tagging schemes and new keys.  Feel free to invent your own values for cycle_network, that's the point of it:  to make it work in your "region" (which could be all of Europe, for all I know).  But please don't invent entire new tagging schemes when the rest of the world already does this (rich, complex different kinds of bicycle routes at various levels of hierarchy which sometimes need the complexity of super-relations...) with existing tagging schemes.

The only thing that really gets us is that the kit is complete. For me,
a tiny component is missing: a value that describes the purpose of a
route in a network.

I would like to advise against summarizing very different things at the
same time in one long value under one key /'cycle_network'/, I wrote a
long post on this yesterday.

After all the many contributions here, in which the difficulty of
understanding this network can be seen, I slowly have an idea why you
insist so hard on expanding the key 'cycle_network'. I suspect that the
term I propose creates false associations. Maybe I have to reduce the
proposal to my concern.

I will answer you separately tomorrow to the corresponding email and
will explain it there. Maybe we can find each other :)

> Underscoring that there is no need for the 'basic_network' proposal as stated.  Repeating:  what "is" (in the real world and represented on these signs) can be mapped using existing OSM data structures and bicycle-route/network-oriented tags.
>
> If an entire country's 'basic_network' is far too large to be put into one relation (and at what I understand would be or is >4000 relation elements, it sounds like it already is), then do what we do in USA:  we break apart huge, long routes that are or tend towards "national scope, therefore quite huge" into one-state-at-a-time relations and combine these relations together into a super-relation.
> ...
> Rolling up your sleeves and doing the admittedly hard work of "putting the whole mess into a big bucket and sorting them (routes, networks...) out into smaller buckets"

We did that in Germany over 10 years ago. 4,000 members - that's just
one district ore one big city. That is the smallest useful
administrative unit here für cycling networks.

That's why we're actually breaking it down into individual connections.
But that is not the content of the proposal. We just do that because
there is no other way.


> and future-proofed cycle_network=* values

I'll happily suggest using cycle_network to name the network and map it
to the correct administrative classification, as is done around the world.

Unfortunately, this does not meet the core need. I will reply to your
answer tomorrow.

> But please don't invent entire new tagging schemes when the rest of the world already does this (rich, complex different kinds of bicycle routes at various levels of hierarchy which sometimes need the complexity of super-relations...) with existing tagging schemes. ... Coining a new tagging scheme (as the proposal does)

Thanks for the honor, but I only suggest an additional value for
existing keys. Not more. :)

I think there is a big misunderstanding here. The proposal does not
invent a new tagging scheme. It is only intended to make it possible to
distinguish between existing routes with different purposes, only this
small brick was missing.

So that every one can understand the need for the missing component, I
have described the situation in Germany. The complexity of this
situation exists outside and is largely mapped in OSM, mostly in
relations. These relations have existed in OSM for 10 years and more.
This is not part of my proposal.

My only change is that I suggest using route relations. Some of these
networks currently use network relations with /'route=bicycle'/, in
which all ways have been collected.

How we divide the existing giant relations into manageable parts, we do
not have to discuss here because the existing toolbox is actually
sufficient, including /'cycling_network'/.

When we run into problems, we discuss them and resolve them.

With that in mind, have a nice evening / morning
Jochen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211123/50961d34/attachment-0001.htm>