[Tagging] Feature Proposal - RFC - value 'basic_network' for keys 'network:type', 'lcn' and 'lwn'

[Peter Elderson]

Ok, thanks so far, JochenB.
Is this correct: A cycle network of this size (all of Germany) cannot fit
into a single relation, so it is a hierarchy of network relations. The
lowest level contains the route relations. The junctions where routes
happen to cross each other, are the start/end points of the routes.

The main purpose of the system is to show cyclists the designated cycling
ways (win-win for traffic control and for the cyclist) and give them clear
destination-based directions. Which does not have to concern mappers,
because mappers can just map what they see (given knowledge of the German
ways) and it will fit in. Except... how it fits into the network hierarchy,
that is not every mapper's cup of tea.

I think this German integrated guidepost system is great for cyclists, once
you get the hang of it!

The purpose of mapping it all in this way is another thing.

The purpose of rendering. OpenCycleMap shows routes (route relations
containing ways), I think? To my understanding, the membership of the route
relation is converted to an attribute of the way, and that is used to
determine how it is rendered. If that is how it's done, the network
relations are not used for rendering. I know OsmAnd doesn't use the
network- and route relations in themselves for rendering (nor for routing).
My understanding is that for rendering, a tag on the way is easier and
quicker than membership of a relation. Correct?

The purpose of routing then. Again, I am far from an expert, so I will
probably (hopefully) be set straight! My understanding is that routing is
in the end also based on attributes of the ways. The router chooses ways
and assigns weights to ways, according to the routing profile, and
calculates which way is the best way to continue the trip. I know that it's
a lot more complicated, but the point is, it's way-based, and tags on the
ways are easier to process than membership of a relation. Correct?

The purpose of trip planning then. Yes, this may involve routing, but it is
not the same! Node Network planning is: chaining predetermined routes
together to form the itinerary of the trip. No way-based routing involved
there. The user selects the labeled Nodes corresponding to the Network
Nodes found on junctions; the software chains the sections together and the
result is a list or strip of Node labels telling the traveler exactly where
to go at each Network Node.
This Node Network system is aimed at guiding the traveler along ways and
routes that a router would not choose. It's not a how-to-get-there system,
it's a what-would-you-like-to-see system, and that's why it's worth it to
do all the mapping work involved.

Maybe I am missing important purposes here?

In this basic_network case, I would like to know why it is worth doing all
this mapping and building such an elaborate system of relations on top of
the ways.

A different question: am I correct that this system specifically targets
cycling?
I know in places, the integrated guidepost system is also applied to
hiking/walking but I think waymarking with e.g. a green or red "walk here"
sign between guideposts is not that common.

Fr gr Peter Elderson

Op wo 17 nov. 2021 om 02:38 schreef stevea <steveaOSM at softworkers.com>:

> On Nov 16, 2021, at 4:09 PM, JochenB <JochenB at wolke7.net> wrote:
> > Am 16.11.2021 um 09:07 schrieb Peter Elderson:
> >> JochenB:
> >> In the case of node networks, 'network: type=*' is already used
> >> successfully. There, 'network:type=node_network' describes the type of
> >> signposting.
> >>
> >> No, it doesn't! It describes the type of network using labeled Nodes
> and Node2Node connection routes to guide the walker, cyclist, horse rider
> etc through the area along a prescribed list of labeled Nodes. Each labeled
> Node points with labeled arrows to the adjacent Nodes, so the user just
> needs to follow the arrow to the next Node on the list (or node strip).
> > That is exactly what I meant by signposting. Maybe that's because of the
> translation tool. Basic network (destination signage) and themed routes
> (route symbols) also have their own way of guiding hikers or cyclists. All
> of these can and will be combined.
>
> This is wonderful, I believe all of us would agree.  The question is HOW
> they are combined, how these are discussed and understood amongst ourselves
> (including those of us who want to ponder and think well about these sorts
> of tagging schemes, but do not have such "cultural guiding principles,"
> routes, signs, (which is what these principles become) in our culture /
> region / signage / roadways / bicycle and hiking routes and networks.
>
> When it comes to the Germans (or Belgians, or Dutch...) want to map cycle
> / hiking routes which are far more rich than what might (or do) exist in my
> culture / nation, I want to GET OUT OF THE WAY and let these develop, grow
> and flourish.  At the same time, I want to understand them and possibly
> offer insights from my / our perspective on how this might, can and
> actually does fit into the greater world.  If there were some sort of
> proposal that might "step on" (interfere with) either my / our way of doing
> this, or it looked like it was short-sighted and could potentially break
> things (or confuse them) for the rest of the world, I would hope I might be
> able to say something about that and have it fall not upon deaf ears, but
> upon a listening community that says "hm, yes, maybe we can tweak this in
> Western Europe so with some minor changes, this works in the whole world."
> We are not quite there yet, but I am glad we dialog and listen to each
> other so that possibility remains open — this is the usual OSM way and it
> seems we're doing fine.  The road ahead to do so looks clear and good, and
> again, I thank the mail-list and community for listening and good dialog.
>
> >> I think destination based planning and guidance is regular routing and
> navigation, and in itself does not need             any special tagging.
> > It is not a question of whether routes with guideposts are mapped as a
> special day on the routes or on routes. The question does not really arise,
> because a large part of the network has already been mapped and is the
> basis for many cycle maps.
>
> I am glad to hear this.  As a brief aside, I'll mention that "tag" and
> "day" are often substituted — potentially confusingly — in
> machine-translated texts between German and English (and back to German
> again).
>
> > It is only a matter of making a distinction between the different layers
> of the cycle traffic network with the different target groups, network
> types and types of signposting. Today renderer have no chance to
> distinguish this. 'network=*' and 'cycling_network=*' are already aimed at
> other classification options that can be combined with the basic network.
>
> There are at least a couple of assumptions here, this isn't wrong, but it
> can be perilous to do so:  in one sense, tagging with a network=* tag and a
> cycle_network=* tag (not cycling_network=*) is VERY well-established, and I
> don't think we want to abandon doing so.  In a second sense, "basic
> network" remains a rather colloquial (to Germany and perhaps other parts of
> Western Europe) notion which, while I'm happy to concede certainly exists
> and should / must be accommodated in OSM, is still a new-ish concept to
> other (bicycling) cultures, such as those of us in the USA who have an idea
> of well established bicycling networks which fit quite well into the (OSM-)
> established hierarchies of "national, regional, local."  I want to
> accommodate "basic network," but I also want to see, participate in the
> development of, fully understand, and potentially untangle from
> MIS-understanding within other cultures and other well-established bicycle
> network mapping schemes (like OpenCycleMap/OCM's three-level
> hierarchy...realizing it is not perfect and needs extensions such as
> cycle_network=* to be fully sensical).
>
> Given that those are regional / cultural assumptions, that this IS a
> global project called OSM, that OCM, cyclosm and other cycling renderers
> have well-defined national / regional / local "levels" for routing and
> networks that are well-established:  we want the proposal to remain
> harmonious, understandable and able to "fit into" a global scheme that can
> be well understood, even in cultures / regions where the asserted German
> styles of routes certainly do not exist, but can be understood to exist
> elsewhere.
>
> >> I am fine with tagging <transport>_network for national, regional and
> local network plans. Most of those I see as road preference systems, aimed
> at channeling traffic. I would translate that into some kind of quality
> indicator, to be used as a weight indicator for routing. If it is a
> collection of predesigned routes, typically with route labels and
> indication of an operator, that's where the <transport_network=* can be
> applied, I think, even though I personally don't really care whose route it
> is if I'm on the road.
> > We need both, 'cycle_network=<country>:<federal
> state>:<region>:<commune>' for classification in the network structure of
> the federal states. In addition, we need a distinguishing feature to
> represent the differences described.
>
> Yes, I am glad to see the specifics of these "nuts and bolts" being
> discussed here.  These words above are a "tip of the iceberg," there is
> much more complexity under the surface.  Let's not keep this submerged, let
> us discuss the specifics so that no misunderstanding remains.  The proposal
> (perhaps initially its Discussion / Talk page) seems a good place for
> this.  German happens to be the language used there, I have already posted
> there in German (thanks to machine translation), even though I speak /
> write absolutely no German (besides "Ja," "Nein" und "Guten Tag").
>
> > There are several dimensions in which networks differ and according to
> which they can be classified. Mapping all dimensions in one tag makes it
> complex. How would we eq. tag a network conceived by a regional
> administration with a small spatial extension and a node network
> signposting?
> > 'cycle_network=<country>:<federal state>:<region>;node_network;lcn' ?
> > I think that's better::
> >
> > 'network=lcn'
> > 'network:type=node_network'
> > 'cycle_network=<country>:<federal state>:<region>'
>
> I agree: a SINGLE tag seems as though it might be too much here and it
> could get overloaded.  Let's agree that it seems OK to expand to TWO tags
> (slowly growing-up from one) and keep it to network=* (established),
> cycle_network=* (established) and PERHAPS (maybe it becomes this, maybe
> something else or something richer) network:type.  We remain in the early
> stages of this, so MORE or RICHER kinds of syntax (proposal) are quite
> welcome (at this point — the door to doing this might close soon and must
> close at some point in the future, lest we get bogged down in the mud).
>
> > Different types of clustering - different tags. In my opinion, this is
> clearer, easier to understand, easier to evaluate and less prone to
> failures.
>
> EXACTLY this sort of discussion is extremely welcome.  Please be more
> specific with how the clustering will be EXPRESSED AS specific tags.
> Good...VERY good!
>
> >> But is it worth it to break down the road system into pieces between
> every guidepost,create route relations for all the pieces, and labeling all
> these chunks with a *_network=* value? It's a lot of work, it's a lot of
> never-ending maintenance, and what does it actually achieve?
> > What's the alternative? So far, all the routes in a district have been
> put into a relation in an unstructured manner. The largest relations have
> over 4,000 members! This is really difficult to maintain. Many of these
> relations have therefore remained at their old status and are no longer
> maintained.
>
> We're going to need to solve this eventually.  4,000 members is too
> large.  (Ways with >2000 nodes, relations with >2500 members...) data
> structures in OSM with these approximate numbers or greater are simply
> unwieldy by mutual consensus.  Let's strive to find ways to simplify things
> at a "more macro" level where it becomes easier to "chunk" things perhaps
> at "more layers" (or levels), but with fewer individual members of
> great-big structures.  I'd much rather deal with "five levels where at the
> bottom or next-to-bottom level, there are dozens or hundreds of things"
> much better than "three levels where at the bottom there are many, many
> thousands of nodes or objects."  Four levels is better than five, three
> levels is better than four, but hundreds or even dozens is much MUCH better
> than thousands.
>
> > Only breaking it down into manageable pieces makes this work
> maintainable. In the end, it is not much different than with node networks,
> only the node names are missing. I find this very maintainable.
>
> It does seem we're on the right rack here, if node names are all that are
> missing, and adding those makes things either maintainable or MUCH MORE
> maintainable, then please:  let's add the node names!
>
> > Refraining from mapping the official cycle network with signposting is
> by no really an alternative. This is essential for good bike maps.
>
> I'm not quite sure what is meant here, but that's like a "five out of six"
> (or thereabouts), so I'll take JochenB's post as "a pretty big win" and
> suggest that we keep discussing.  Great so far!
>
> SteveA
> _______________________________________________
> 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/20211117/fb0295ee/attachment-0001.htm>