<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Am 18.11.21 um 19:12 schrieb Volker
Schmidt:<br>
</div>
<blockquote type="cite"
cite="mid:CALQ-OR41KrqYM7WJVCRnn0jUb=mq8AZMQfyt8bo28iCztkuwHg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<div>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.</div>
</div>
</blockquote>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:CALQ-OR41KrqYM7WJVCRnn0jUb=mq8AZMQfyt8bo28iCztkuwHg@mail.gmail.com">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>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.</p>
<div class="moz-cite-prefix">Am 18.11.21 um 22:11 schrieb Peter
Elderson:<br>
</div>
<blockquote type="cite"
cite="mid:CAKf=P+sc8SFaWpqEvpf3ohd9jy3zoiZ6mb7fvoq_LRV5OtLo0Q@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">Volker Schmidt:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>(I still don't understand what this basic network is
supposed to be)<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
</div>
</div>
</blockquote>
(thanks...)<br>
<blockquote type="cite"
cite="mid:CAKf=P+sc8SFaWpqEvpf3ohd9jy3zoiZ6mb7fvoq_LRV5OtLo0Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>[...] 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. </div>
<div><br>
</div>
<div>This is all visible and verifiable, so if mappers want to
map it, fine. </div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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!</div>
<div><br>
</div>
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.
</div>
</div>
</div>
</blockquote>
<p>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).</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:CAKf=P+sc8SFaWpqEvpf3ohd9jy3zoiZ6mb7fvoq_LRV5OtLo0Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>I think it can't be done on this large a scale without
special tooling and error detection. </div>
</div>
</div>
</blockquote>
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...).<br>
<blockquote type="cite"
cite="mid:CAKf=P+sc8SFaWpqEvpf3ohd9jy3zoiZ6mb7fvoq_LRV5OtLo0Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>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. <br>
</div>
</div>
</div>
</blockquote>
<p>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.</p>
<p>Sebastian<br>
</p>
<br>
</body>
</html>