Gerd Petermann <gpetermann_muenc...@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?
signature.asc
Description: PGP signature
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
