W dniu 21 września 2014 02:10 użytkownik Tom Pfeifer napisał: > Navigation software is pretty able to consider a short list of specific > pavings > as 'paved' and another short list as 'unpaved', they are already structured > in the > wiki.
> OsmAnd, as a popular navigation software, does so, and in the pre-1.9 > nightlies you > can switch on colour coding for different surfaces. >> the software can check the value of the surface key, but in practice most >> (all?) >> of the navigation software only checks for a subset of all the possible >> values >> the surface key can have. > Could you please support your argument with examples of such software, and > why such incompleteness cannot be fixed within the router/renderer? Didn’t want to name particular software, but if you ask, then OsmAnd 1.8.3 thinks that highway=tertiary + surface=dirt is a paved way, and setting “avoid unpaved roads” in its configuration doesn’t prevent it from routing through such a road (car navigation mode). Please look at this issue: https://code.google.com/p/osmand/issues/detail?id=1956 As you can see, they have “fixed” the issue more than a year ago, in version 1.4.1. Then I forgot about this and didn’t check whether it really worked. Yes, I should have probably reopened the issue and tell them that they didn’t really understand what it was all about. But on the other hand, I believe I was clear enough in my description. I stated clearly that the problem is that they do not support _various different_ values of the "surface" key, yet they only went for adding support for _one most general_ value. I had pointed them to that very long list of possible values for “unpaved” surfaces, yet they have decided to add support for only one of them. So, again: > Navigation software is pretty able to consider a short list of specific > pavings > as 'paved' and another short list as 'unpaved', they are already structured > in the > wiki. True. > OsmAnd, as a popular navigation software, does so Untrue, unfortunately. And answering this particular question of yours: > [...] and why such incompleteness cannot be fixed within the router/renderer? Don’t as me. They apparently have chosen not to. Moving on: >> The default value >> of the paved key for highways could be yes, so that it would be consistent >> with the >> assumption that highways in general are paved. > This does not work as a general assumption. > I would assume a motorway as paved, but a track or path as unpaved, unless > shown otherwise. Yes, I forgot that the highway tag is used also for these. So this would be a bad idea indeed to assume that highways are paved by default. >> Also, the surface=paved could also implicate paved=yes >> and similarly surface=unpaved could implicate paved=no, so that duplication >> of the >> information could be avoided when the generic paved and unpaved values are >> set for the surface key. > You are just arguing against your proposal. I wouldn’t agree that I’m arguing against my proposal here. I’m supplementing it. > As we have surface=paved we don't need paved=yes. Yes, that’s what I meant – if a highway has surface=paved, then it doesn’t need paved=yes. > And surface=asphalt implies paved. And what about surface=dirt? Doesn’t seem to mean surface=unpaved for everybody. Besides all the above, and besides all the answers all of you have written, another thing has just came to my mind – don't you think that using the “surface” key for saying _either_ that a highway is paved/unpaved _or_ what particular surface the highway has, is a bit inconsistent? What I mean: don’t you think that a property called “surface” should describe what highway is made of/consists of (asphalt, paving stones, grass, mud, dirt, ice, etc.) and not how it has been made (it has been _paved_ or has been left _unpaved_)? In my opinion these are fundamentally two different properties (although one of them is a derivative of the other). Regards, Tomek _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
