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

Peter Elderson pelderson at gmail.com
Mon Nov 22 10:12:31 UTC 2021


It's really not that complicated. Putting all signs on one pole does not
make any difference.
Forget the special routes, themed routes, networks, all that sh!t. That's
all settled and handled. It's just about the ways selected for regular
destination-signage. Berlin 5000 Km to the left, Beiruth 10.000 to the
right.

The wish is to allow data users to emphasize them on a map, or giving them
higher weight for routing. This reflects the real world situation that
these ways are Chosen.

To achieve this, the Chosen ways need an attribute that reflects that these
ways have The Official Signage. Possible solution direction are: tag the
Chosen ways, or relation(s) containing the Chosen ways, and tag the
relations as Chosen. So far, it doesn't really matter with what key or
value.

Tagging all the ways as Chosen for a specific purpose has its drawbacks.
Route tagging in general started out like that, has learned a lot, and is
now mostly relation based.

Putting all the Chosen ways in one Relation Of The Chosen is unmanageable.
A scalable solution is then needed (*If*  you still want to achieve the
goal of marking the officially signposted ways to enable
emphasis/weigth for data users). The other end of the spectrum is putting
all the ways between all the official signposts in short route relations.
(There are examples of tooling to check and manage such a mass of small
relations.)

And that's the proposal. I think.

Peter Elderson


Op ma 22 nov. 2021 om 08:56 schreef stevea <steveaOSM at softworkers.com>:

> I do not have the knowledge nor time to invest in designing a
> "full-Europe" set of values for cycle_network=* because I'm not familiar
> with the rich set of the routes, networks and jurisdictions where the do or
> might overlap.
>
> But I know I did this by throwing all the kinds of routes that existed
> into one big bucket, then sorting them out into different buckets, without
> really being concerned about whether they were "national" (and might get
> tagged network=ncn) or "regional" (and might get tagged network=rcn)...and
> so on.  I / we (when we did this around 2013 in the USA) noticed that there
> were three or four or five or maybe six "kinds" of "groupings," some of
> them "acting national" (and maybe as many of three of them actually were
> and are national, but that doesn't mean we have to call ALL of them that,
> especially as we can differentiate them with cycle_network values that
> differ from one another.  So maybe something that really ACTS national is
> better expressed (in OSM in the USA, because we also denote it with a
> specific and unique cycle_network value to differentiate it) as regional
> (network=rcn) instead of ncn (national).  In fact, we did just that, but
> not before we discussed it and did the "goods and bads" about that...and
> tried on a couple of different solutions and we discussed it some more...we
> DESIGNED it.  We made mistakes along the way.  We came up with something
> that even today maybe isn't perfect, but it is good enough to work (and
> grow) and it does both.  I'm thrilled.  I'm also confident you can do this,
> too.
>
> And so on.  The "tourist" or "more commuter oriented" and even "the
> basic_network" (I still don't see why lcn=yes or rcn=yes or similar tags
> can't "collect" these) "routes" (as members of a network or networks) —
> which ARE, after all, OSM relations tagged type=route, route=bicycle...it's
> the other tags we're wrangling about...these can get whatever values for
> cycle_network that make sense to you.  If you don't like cycle_network=DE
> (for Germany, and then followed by German states and maybe German cities
> within those states...you know, a hierarchy) because "you have to look for
> a specific keyword in value," OK I hear you, maybe you prefer to spell out
> "Deutschland" rather than abbreviate DE:.  Maybe you want to "spell out"
> "basic_network" (as a cycle_network value) instead of using "bas_net" (or
> some obscure abbreviation, as that can be OSM-unfriendly), although there
> are arguments to be made for good abbreviations people already know and
> there are arguments for "spell out the whole word so we don't have to guess
> at what an abbreviation stands for."  Your choice!
>
> But start out putting "everything under the sun" (routes, categories of
> routes, networks, categories of networks, the whole cross product of this
> with the geography of countries and how "only up to the jurisdiction
> boundary" is truly going to affect routes, basic_network and whether
> something is a member of this relation or not a member...) and so on.  LOOK
> at this big bucket / table of "things."  See if there is structure,
> especially "country at a time."  (I can almost guarantee you that what
> Bavaria calls its basic_network is NOT going to be the same as what a Swiss
> canton might call this, after it has been identified as "yes, this is
> pretty much the same kind of thing, but the way we do it is Zug-like,
> rather than München-like."  You'll find overlaps, you'll find exceptions.
> You'll find broad categorizations that allow you to say "these are pretty
> similar but not exactly the same, let's put them in a loose aggregation
> category that denotes their similarities."  You'll find things that are
> expressed with a hierarchy in a network tag that STILL needs to include the
> complexity of being blended into super-relations.  Or not.  Or..."roll your
> own as you see fit."  That's why cycle_network changes around the world:
> because things are different around the world.  Not SO different they can't
> be expressed with a sensible (maybe even fully-spelled-out words) structure
> in a smart key like cycle_network, but close enough that with good design,
> this CAN be designed.
>
> Whew, I'm exhausted.  This CAN be done.  It requires work and more
> discussion using these ideas and the wheels we've invented (the data
> structure elements, tagging schemes and renderers / routers we already
> have), not new wheels that obfuscate away messy tagging and what appears to
> be laziness of "we shouldn't be forced into imposing what feels like
> artificial structure upon us and our bicycle routes / networks here."
> Well, in OSM, about bike routes, yeah, you should.  The world already does
> this.  Apparently, you don't (yet).  But you should, I'll be the first to
> welcome you into the world of doing it a lot like the rest of us. You can
> get there.  Take the time to design what the heck these routes and networks
> are trying to "utter" and express to everybody (you really haven't even
> done THAT yet, it's a good place to start), denote that / those using the
> building blocks / data structures we already use and everybody will cheer.
> But please do not avoid doing the necessary work it will take to "properly"
> structure this with room to grow for the future.  Because once you do, it
> will pay dividends of clarity and growth into the future.  I say this from
> personal experience, and you can check out me and the truth of this
> yourself.
>
> Encouragement!  (Not rock-throwing).  I wish to offer encouragement!
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211122/37263462/attachment-0001.htm>


More information about the Tagging mailing list