[mkgmap-dev] render landuse=orchard

Fri Aug 5 02:51:48 BST 2016

Gerd Petermann <GPetermann_muenchen at hotmail.com> writes:

> If I got that right we should change the style rules in at least two places.
>
> If a way with railway=abandoned is member of a route relation with
> e.g. route=hiking we want the way to be routable for pedestrians, see
> e.g https://www.openstreetmap.org/way/56214377 which is part of
> relation https://www.openstreetmap.org/relation/1735816
>
> If we simply change the lines style to
>
> railway=abandoned {add access=no} [0x0a road_class=0 road_speed=1 resolution 22]

> this way would not be usable for pedestrians.

True.  I think this is a general problem, when a way (or its relations -
I don't see relation vs direct tags as being super important for this
dicussion) has multiple tags, then mkgmap has to decide which of them
controls the garmin line code.  That said, I tealize that relations are
not necessarily handled the same, so that may complicated the
implementation.  But I don't think it affects the intended semantics.

> So we need an additional rule in relations to store the info that a
> way is member of a route relation, and we should evaluate that
> information somewhere in lines or inc\access.

It's not really about being a route relation.  The thing that matters is
that the railway=abandoned is also either highway=path or
highway=cycleway, or something else that if it did not have
railway=abandoned would be routable.  Usually that sort of physical tag
belongs on the way, not on a relation which would assign ref tags or
route tags to a collection of ways.

So I think if someone has a route relation over a bunch of ways that are
railway=abandoned and the route is about cycling and not an old
railroad, and there are no highway=path/cycleway/footway/track tags,
then it is correct to have a nonroutable line type and the tagging
should be updated to reflect the access.

What mkgmap has to do is just to evaluate the rules that assign
path/footway/cycleway/track tags before the railway=abandoned tags.

Or a fancier style could have two types, routable and a non-routable,
that both render as old railroad, and use the routable one for path/rail
and the nonroutable one for just rail.

> I assume that this should also be done for highway=*, but I am not
> sure how to handle conflicts, for example a way may have
> "highway=footway and no explicit bicycle tag" and be a part of a
> route=bicycle relation. Does that mean that the relation is wrong or
> that the way should be accessible for bicycles?

Two thoughts here:

1) The tag

  highway=footway

is equivalent to

  highway=path foot=designated

and neither says yes or no for bicycle.  The default for path (and thus
for highway=footway) is bicycle=yes.   So that should be the same.

2) "route=bicycle" denotes a bicycle route, which is a logical
association of some bicycle route ref with all the underlying ways.  It
really does not say anything about access.  There could be a bicycle
route for which many or all of the ways are access=private.

Overall I would recommend to let the route=bicycle relation simply
associate the refs (and shields), and to let access tags be about
access, and not try to do anything fancier.

Does this make sense?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20160804/2686fa4d/attachment.sig>