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
