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

Sebastian Gürtler sebastian.guertler at gmx.de
Thu Nov 18 23:07:35 UTC 2021


Am 18.11.21 um 19:12 schrieb Volker Schmidt:
>
> When I plan a night trip home across my home city on bicycle I would
> give priority to low-traffic, good-surface, illuminated roads and
> would not be interested in any cycle tourism aspects, i. e. to be on a
> cycle route.

I wasn't talking about trips through a city but between cities - for
example between Paderborn and Bielefeld which I do quite often. It is
really to find my way in the dark in non illuminated routes where I
depend on the visible markers even at small ways through forests and
fields. It makes a big difference if you use routes that differ from that.

> If we start to introduce cycle routes as the equivalent of the road
> hierarchy for motorized traffic we need to be careful. A Fahrrad-Bahn
> to get people quickly to work or University should not be a bicycle
> route in OSM, at least under the actual scheme of cycle routes.

I really don't understand why you think that these routes shouldn't be
tagged in a similar way like the others. All these routes are marked and
signposted identically, no matter if they are touristic or fast ways.
You won't ignore features from "on the ground" in osm just by the
criteria that you decide the route has no touristical value and is a
quick connection. The only difference "on the ground" is that the
touristic routes have little icons at the guideposts at the branches
that show the existence of a touristic route on the way. (btw the routes
around the university in Bielefeld are all included in touristical
routes so here it won't make any difference...) But on the routes
themselves no matter how many turns you have take on the way, you won't
see any route specific post even on the touristic routes but only the
same sign with a bicycle and an arrow which gives only the network
information.

It may depend on the region, how far the communities are to implement
it, but it is planned to do it this way in whole Germany and I read that
any state had implemented it now. I don't know, where you usually ride,
and whether you talk about the situation in Germany at all.

Am 18.11.21 um 22:11 schrieb Peter Elderson:
> Volker Schmidt:
>
>     (I still don't understand what this basic network is supposed to be)
>
>
> I think I understand. The governmental bodies call it a network,
> because that's what they any road system.  And, if you look at the
> maps showing them, it looks like a net.
>
(thanks...)
> [...] This net is a system of designated cyclable ways, implemented on
> the road with Destination based guideposting, and, where it suffices,
> just pointers to the way or lane all cyclists should take if they want
> a certain level of cyclability.
>
> This is all visible and verifiable, so if mappers want to map it, fine.
> Of course they also want to use this after putting in all the work,
> they want to see it on the map and they want their
> planner/router/navigation to use it.
>
> You could tag all the ways with a tag that says "designated cycleway
> with quality N". That's fine for cycleways; with paths you have to
> consider access as well, and with roads you have to consider
> use_sidepath, separate cycle lanes (left, middle, right) AND access
> tags, maybe conditional; etc etc. ... I can see this can be
> complicated, for mappers and renderers and routers.
>
> So the idea became to create a relation, throw in all the ways, paths,
> etc having this preferential designation. Then the only thing data
> users have to do is check the relation; if the way is in there put in
> the weight. As it happens some cycling renderers and routers use route
> relations for neat rendering and preferential routing, so add
> type=route to the relation and BIYU!
>
> The down side is that it is not a route but a collection. Changing the
> relation type loses the rendering and the routing. And maintainability
> is reportedly low, and a constant PITA, I can imagine that.
> The solution is to have the collection relation contain routes, and
> the routes contain the ways. Then you keep the nice rendering and the
> route relation preference of the router. Maintainability is served,
> because changes only affect the lowest level: short routes. And you
> can make a hierarchical network: a network of networks at the top, the
> routes in the lower network level, as deep as you want, which neatly
> fits the cycleway network hierarchies in Germany. As long as the
> networks can be found on the guidepost and shields, there is
> verifiable ground truth.
>
> There is one thing to do. The route relations have to be separate
> routes! They should not overlap (too much), each route needs a
> starting way and an ending way, the routes should (for the most) chain
> neatly together. How do you choose the routes to achieve this, in a
> way that less expert mappers can understand? That's where the
> guideposts come in. Let the routes go from guidepost to guidepost.
> Intermediate signs (bicycle logo with arrow) are not mapped as
> features, but they indicate the route between the guideposts.
>
> The down side here is the burden to create and maintain a very
> fine-grained system of guideposts and small routes. Another issue is
> that a large amount of small routes is created, which do not have a
> name or other presentable label, at least not one that's found on the
> road.
>
> I think that's what the proposal targets by proposing
> network:type=basic_network. It allows an application to filter these
> small unnamed routes from lists, and also enables them to give them
> special rendering. Routers could base specific handling on this
> attribute.
>
> This is my current understanding. I am still not sure if the result
> justifies the means, in particular the huge maintenance task if you
> want to cover the whole of Germany.

The point is that I assume that in many regions nearly all ways of the
network are already collected in huge relations without any order - and
meanwhile outdated and full of wrong data. The main task is not to
create new mappings but to sort out the existing relations. Yes the task
is big, but only breaking down the huge relations makes this task
possible. The main problem is that there are no available sources of
sufficient quality for the network besides the survey on the ground,
this is the real big task... Only the direct cooperation of the local
communities that have the data could change this, but I think some are
interested in doing that - I assume that about 10-20 % of the bicycle
routes in OSM were put in by the geodata department of Bielefeld (nearly
all the other ways I checked personally in 2020).

The regions are very different concerning bicycle traffic and bicycle
mapping in OSM. North Rhine-Westphalia has the highest density of
population in Germany, young people using bicycles, here it's quite
easy. If you look at Lower Saxony it's completely different. I don't
expect that we get easily complete with it for the whole of Germany. But
I think it would be good to have a unified scheme for tagging the
network as the state has developed his unified system and is
implementing it more and more.

> I think it can't be done on this large a scale without special tooling
> and error detection.
That's the point why I prefer relations from branch to branch, that is
"node" to "node" - so I set hope in changing the software of
knooppuntnet.nl for this purpose. At the moment I get along with my
tracks, photos of guidepost and JOSM with my own templates, but it's
still a lot of work, that's true. And I can imagine that you also could
create plugins that simplify the creation of the elements of the network
in JOSM, or even mobile apps that could do the job. (Cycling the routes
with tracking and taking photos of the guideposts at the branches should
be enough for the basic network, maybe with manual correction of the
text data. Recognizing route logos would be a bit more difficult...).
> The structure is bound to deteriorate over time unless it is very
> tightly maintained by dedicated mappers, and if it's going downhill,
> it becomes useless very fast.

This has happened already to the relations made up 10-15 years ago. The
actual story is how to revive and unify the implementation of the network.

Sebastian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20211119/3c27c477/attachment.htm>


More information about the Tagging mailing list