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

[JochenB]

*Short version: *I agree with you almost completely, from the first
post. But this still does not solve the problem that the proposal is
supposed to solve, namely to determine the purpose of a route / network.
Obviously the suggested value is misleading. That's why I have to reduce
the proposal to the core and leave out everything that leads astray.
Thank you for this insight!

*Long version:*

Your lines show me that you assume that I want to name a certain network
and classify it. Yes, that's exactly what I intend to do. And yes, the
/'cycle_network'/ and /'hiking_network'/ tags are wonderfully suitable
for this. I understand your answer and your concern completely and I
agree with you in almost all things, right from the start. I would even
like to suggest doing the same in Germany.

The problem with that is that none of this should be part of my
proposal. There is a tagging scheme for this, why should I suggest
something that already exists? So far I have not been able to convey
that there is another need that does not belong to the task of "name a
network and classify it".

That's why we talk at cross-purposes. It annoys you that I keep going
despite your good reasoning. It annoys me that you don't go one step
further to recognize my need, but get stuck where your picture ends.

But I have an idea why it could be.

Cause: I'm not clean in my definition either. With 'network: type =
basic_network' I involuntarily express several things at once:

 1. The route is part of a network, therefore /'…_network'/
 2. This network is the lowest layer in the hierarchy of networks,
    therefore /'basic_...'/ in the sense of "basic layer"

I'm pretty sure your criticism is related to both of these aspects,
because there has been a scheme for this for a long time. And you're
right, and I've agreed with you several times and said "let's do it this
way". At that point the discussion would be over for you. And I see in
your lines the increasing astonishment that the crazy German insists on
the new value anyway and more and more persistently. Why does he do this?

I'm doing this because for me the discussion hasn't even started here. I
want to express two completely different things with the proposal:

 3. I want to tag the purpose of the network, which is to officially
    mark cycle- or hiker-friendly routes using standardized signposts -
    nothing more. Therefore /'basic_...'/ in the sense of "basic function"
 4. I want to distinguish these routes from specific route
    recommendations that have a different purpose and different signage.

This is something completely different from 1st and 2nd (admittedly:
that wasn't so clear to me at the beginning, because it took your
persistence). I'd love to discuss that core, but you're always stopped
at thing # 2 along the way.

In addition, there is the initial misunderstanding that my description
of the situation in Germany (different network levels) was understood by
many as the content of the proposal.

*I now have an idea how to get out of this misery:*

I will clean up my proposal and reduce it to the core. I separate the
1st and 2nd. There’s your suggestion for that.

For 3rd and 4th I will address directly what I mean and only that.

    3rd thing: /'route:purpose=basic_network'/
    4th thing: /'route:purpose=route_recommendation'/

I could also be more radical and not relate the third thing to the
network, because it is not absolutely necessary. I could delete the
'network' from the proposal for this. What is left is this:

    3rd thing: //'route:purpose=basic_route'//
    4th thing: //'route:purpose=route_recommendation'//

This is not a "lazy syntactic sugar". That is the reduction to the
essentials. Everything you want is already regulated in other tags.

Can you follow me?

Can you live with this solution?

If so, then the only question left is whether /'purpose'/ is the perfect
key name. In addition, whether there are better values that describe the
basic function of the route: "officially mark cycle-friendly routes
using standardized signposting".

The same question arises for /'route_recommendation'/ for signposted
route recommendations.//
//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211124/fbf49b0b/attachment-0001.htm>