[Tagging] Feature Proposal - RFC - value 'basic_network' - Tagging with a simultaneous basic network, node network and/or route recommendation

[JochenB]

Am 20.11.2021 um 15:38 schrieb Sebastian Gürtler:
>
> I didn't get it. Would you suggest to use the tag
> "network:type=basic_network" for all the 24 (?) internodal segments or
> only for those that are not part of any of the other  routes or
> relations? (about the half of them) The other segments can be part of
> the numbered node network and/or part of a named route. But the named
> routes also can be routes that are not according to the signposting
> guidelines in their whole. So I don't know at the moment how to
> describe in OSM that you can rely in these sections on the
> standardized signposting.
>
You hit a sore point where I'm not sure if my idea is the best solution.

The motivation of the proposal is to create a possibility to display the
basic network connections without route recommendations differently than
basic network connections where route recommendations run. In other
words: where recommended routes run along, the basic network should not
be displayed. It is the same for connections from node networks. Here,
too, the basic network does not need to be displayed.

The representation is one thing, the correct mapping in the data is
another. There the question arises of how the basic network is mapped,
where a route recommendation or a connection of the node network leads
congruently over it.

The proposal is limited to the tag for basic network relations. How
these relations are intersected leaves it open. It's complicated enough
as it is.

Even if this is left open, the proposal restricts the freedom of how to
deal with it *). It is therefore right to discuss this now.

*Possible variants of tagging with a simultaneous basic network, node
network and/or route recommendation:*

I see 4 options: In the sections in which a signposted route
recommendation or a node network connection leads via the basic network ...

 1. ... there is no mapping of the basic network
 2. ... the basic network and route recommendations / node network
    connections are mapped in separate relations
 3. ... it is marked in the affected sections of the route
    recommendations / node network connections that they are also part
    of the basic network
 4. ... route recommendations / node network connections are only mapped
    as a master relation. The master relations contain the relations of
    the basic network connections in the correct order

*Network planning perspective:*

 From the point of view of network planning, there are three different
layers:

 1. Basic network connections as a base layer (in the German bicycle
    network: destination guideposting)
 2. Node network connections (in the German bicycle network: signs with
    numbers on the destination guideposts)
 3. Route recommendations (in the German bicycle network: signs with
    symbols on the destination guideposts)

In addition, there are still

 4. (Older) routes that have not been created taking this layer
    definition into account.

In most cases, routes in 2) and 3) will also be part of 1) at the same time.

With 4) the question is whether we see it as part of the basic network
1) by definition. In my opinion, this depends on whether the users'
expectations for level 1 are met with these routes. That would be a
separate thread of the discussion, presumably with different results
depending on the concrete case.

Globally viewed, in most cases there will only be one of the three
levels. Then, of course, the distinction between the levels is no longer
necessary.

*Discussion of the tagging variants:*

*Variant A) *does not show that / which sections of levels 3 and 2
routes (route recommendations and network connections) belong to level 1
(basic network). This could be solved by simply defining in the wiki
that levels 2 and 3 are always level 1 at the same time. This means that
the network planning perspective is also shown in variant A).

Special cases where a route recommendation leaves the basic network are
not taken into account. Such a special case is described under 4). In
the German bicycle network, this would mean, for example, that a route
recommendation is only shown by means of a route symbol and without
destination signage, or that the destination signage deviates
significantly from the standard of the basic network. You could treat
these special cases with a /'basic_network=no'/, write something in
/'note=*'/ or accept the blurring.

With *variant B) *we have 2 relations on a way, one for the basic
network and one for the route recommendation. The variant becomes
particularly interesting if further information is to be written in the
relations that can be found on the signposts, for example.

If, in addition to the route recommendation, there is also a node
network, this would be the third relation on the way in variant B). The
relation of the node network would mostly be identical to the relation
of the basic network connection. Sounds like effort and complexity.

I would not recommend a complete mapping of the basic network according
to B), most of it would be redundant to node network connections or
route recommendations - without much added value. But if someone wants
to do that, I wouldn't stop them.

For *variant C)*, the route recommendations would have to be split when
they leave the basic network. I don't think we will succeed in conveying
this necessity to all mappers. It increases the complexity of the model
with little added value.

*Variant D) *is only practicable for route recommendations. In the case
of node network connections, variant D) would mean that a node network
relation usually only contains one basic network connection relation. A
master relation with only one member would be strange. If we opt for
variant D) for route recommendations, variant C) should apply to node
network connections.

I feel *variant D) *brings additional complexity into the scheme,
everything is already complicated enough.

*My proposition:*

*I would *pragmatically *suggest **variant A) *with the definition
described in the wiki that route recommendations and node network
connections always belong to the basic network at the same time. This
creates the least effort and the least complexity. Not every special
case is covered, but we are used to blurring in OSM. In special cases I
would give a tag /'basic_network=no'/ to the relation or ignore them.

In addition, *variant B) can be used *if the connections in the basic
network contain additional information that does not apply to the entire
node network connection or the entire route recommendation.

I would not recommend variants C) and D).


I hope I haven't lost you with the long text and haven't forgotten any
aspect or possible solution, otherwise please add :)

What do you think my suggestion is understandable and correct?

Many greetings,
Jochen

*) According to the proposal, a route relation cannot be a node network
connection and a basic network connection at the same time (either
/'network:type=node_network'/ or /'network:type=basis_network'/)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211121/5c417ab8/attachment-0001.htm>