On 13 Jan 2014, at 11:15, Christian Quest <cqu...@openstreetmap.fr> wrote:
> tags on relations can be seen as default values for the relation members, so
> in such a case, the default tag is replaced by the member one.
> I'm not saying it's right to do it that way, just a way to deal with data in
> such cases.
Thank you Christian, you are right. The Overpass API finds 46 ways that are in
in type=route highway=* relations but don’t have a highway=* tag themselves:
http://overpass-turbo.eu/s/22N
It looks like most of these are bad data, and I will attempt to fix them all
manually.
Many are, for example, ferry routes:
http://www.openstreetmap.org/way/4471590
http://www.openstreetmap.org/way/81832097
Others make no sense whatsoever:
http://www.openstreetmap.org/way/238402296 (part of
http://www.openstreetmap.org/relation/3213904 highway=bus_stop, no less)
Finally, the rest can reasonably be tagged with the parent relation’s highway
tag (and the highway tag safely removed from the relation, if the relation is
even still necessary):
http://www.openstreetmap.org/way/99421886
> This can also be managed at rendering level in several ways:
> - do not render route=* (that's the option I choose)
> - render route=* first in case there is one (may not render right in your
> motorway/residential example, but fine with the railway tunnel)
I understand where you’re coming from. It doesn’t feel nice to have this
ambiguity in the way we render data, so fixing that feels natural. Not
rendering route=* would cause issues in these 46 cases; rendering route=* could
potentially cause issues in the >500 issues pnorman found. There’s no reason
why we can’t clarify our rendering conventions, but fixing this only in the
rendering would still not fix the semantic issue, and we should try to remove
ambiguities from our data model.
Cheers,
Guillaume
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
