Gerd Petermann <GPetermann_muenchen@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?