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

[stevea]

As I consider this potential solution (bcn), I lean towards it as "better."  I believe it is better because it neither creates a new key (like network=*) nor does it repurpose a subkey (network:type) in a manner I have pointed out as inconsistent and confusing.  Instead, extends the VALUES of network=* to contain a NEW value that appears to satisfy those who believe that "this" (a 'basic_network' — I'm still grappling with the difficulty of what, exactly, that is) is a form of "network" (even as I don't quite see that, but I can be convinced that it is with some very crisp definitions that do not yet appear to be extant or widely accepted).

However, just as icn, ncn, rcn, lcn routes could or do have appropriate cycle_network=* tags on them to identify WHICH network these routes belong to (that is its exact purpose), relations potentially tagged bcn should ALSO have cycle_network tags on them.  Recall that this will denote WHICH network the specified basic_network is a member of (is it "the one in Zug, the one in Bavaria, the recreational one in this region of Italy...")?  I might suggest that all of these follow some sort of convention that if they are in a network=bcn, they all have the word "basic" in them, to emphasize the distinction (or a similarly agreeable value / sub-string).

I am / it seems we remain (on this list) in earlier-to-middle phases about how we will solve this, as there is JochenB's "re-write" of the original proposal, Flips' suggestion (here), Florian, Sarah and Richard (all cycling renderer or routing authors) have chimed in (Andy, are you out there?), Minh's participation, Sebastian's continuing contributions...Martin, many others, I don't want to leave anybody out, but this has been a seemingly record-breaking thread in its length, complexity and wide participation.  I wish the finish line were better in sight, but it still seems a clear solution remains murky about what is best to do:  there are lot of suggestions, some of them very good imo, but consensus remains elusive.

I think what this means is that we do not (yet) agree on how to solve this.  I'm certain it CAN be solved to wide satisfaction and acceptance, we're simply not there yet.  I don't wish to state the obvious, however, I can certainly sense there is a feeling of exhaustion on this topic in this thread; I certainly feel it myself.  I don't want this to turn into "frustration becomes destructive," as that is all-too-easy to happen.  Let's keep our cool, everybody, and forge ahead.  I thank everybody here for continuing good discussion.


> On Nov 28, 2021, at 11:22 AM, Flips <flips at gmx.ch> wrote:
> 
> I am pretty much in favor of the key network=bcn as Martin wrote. And equaly network=bwn for hiking.
> 
> Cheers, Urs
> 
> 
> 
> Am 28. November 2021 16:34:56 MEZ schrieb "Brian M. Sperlongano" <zelonewolf at gmail.com>:
> I agree that lcn=yes is what I should have written -- but I see no reason why a way tagged lcn=yes *must* be part of a route.  That seems like an entirely artificial constraint and not some kind of fundamental tagging canon.
> 
> On Sun, Nov 28, 2021 at 10:03 AM Martin Koppenhoefer <dieterdreist at gmail.com> wrote:
> Am So., 28. Nov. 2021 um 01:52 Uhr schrieb Brian M. Sperlongano <zelonewolf at gmail.com>:
> It seems that the challenge here is that you have all of these cycling ways which are certainly part of an interconnected network, though they are not part of any named and numbered route.
> 
> I see this as very simple - we have a tag for this, network=lcn[1].  These ways are all part of a local cycling network, so tag them that way.
> 
> 
> According to the wiki, the tag lcn=yes is intended for "Designates that a road or path is part of a local Cycling Network route", i.e. it must be part of a _route_.
> 
> Still we could have a tag bcn with a slightly different definition ("is part of the basic cycling network" without the "route")