[talk-au] New key proposal - paved=yes/no
David Clark
dbclark at fastmail.com.au
Mon Sep 22 09:28:56 UTC 2014
I have 2 thought on this and have posted before about the
surface=blahblah tag not being used for highway=path when by my
interpretation it really should be. ie if you use highway=path,
then you should be including the tag surface=blahblah if you
have any idea what the surface is (because there is no default
surface for highway=path).
When using highway=path, there is no default for surface so
renderer's are stuffed if the surface=blahblah is not also
included. (I do my own gps rendering so I have a little bit of
experience doing it, but I'm a hack not an expert :-).
Surface=paved and surface=unpaved are acceptable tags. The
other surface tags provide more specific details but still fall
into either paved or unpaved. (For example surface=dirt is a
type tag indicating unpaved but with more specific detail).
When rendering you can pick up all the tags indicating a
highway is paved and group them together and do the same for
highway's that are unpaved. It's the ones that aren't tagged
either way and have no default that are the problem. This is
basically a problem with highway=path because the other have
defaults for the surface.
So my 2 thoughts:
(1) Not including the surface tag when using highway=path
causes problems for renderers that want to differential between
paved and unpaved paths. If an additional tag such as paved=yes
or paved=no is created that's fine with me, when rendering I'll
just include that in the groupings for paved and unpaved paths
along with the other tags I use for grouping, the important
thing is there is something to differential between paved and
unpaved when there is no default or when the highway doesn't
conform to the default.
(2) Renderers can already group highways into paved or unpaved
when the tags have defaults or when the surface tag is included
for highway=path and highways that don't conform to the default
surface. So the fix is to get the renderers to use the
information that is available already.
David C
My experience is that surface can have descriptive values
that don't immediately indicate if the road is paved or not.
Things like "asphalt" (presuming paved=yes) and "gravel"
(presuming paved=no) are common.
- Ben Kelley
On 22 Sep 2014 09:24, "Warin" <[1]61sundowner at gmail.com> wrote:
Tagging for the render?
You can have surface=paved or surface =unpaved! More detailes
options are also avalible.
The argument on the routing not using the right method for
determining its route should be adressed to the router! Not
patched to 'fix' the routers problem. The router should
descriminate on the surfaces its finds actptable rather than
ones it thinks are unaceptable. e.g. for paved it should acept
surface = paved, concrete, asphalt ... is that just too hard?!
I'm assuming cobblestones are unaceptable.. but if in France
then they would be aceptable .. some of their 'main' roads are
cobblestones ...
My vote would be 'No'. As surface provides the information ..
in some cases in more detail but the grouping into paved and
unpaved is resasonable.
On 21/09/2014 12:25 PM, Ben Kelley wrote:
Hi.
This sounds like a very good suggestion. Often you just want
to know if the road is paved.
It seems like that was the original intent of surface=, but
that is not how it gets used now.
How surface= implies paved= sounds good too.
- Ben.
On 21 Sep 2014 11:03, "David Bannon"
<[2]dbannon at internode.on.net> wrote:
Interesting proposal on the OSM Tagging list. Oz would have
a
unpaved/paved ratio as higher that most countries, we should
have an
opinion on this.
So far, reaction has been mixed, some (including myself)
welcoming it
and some seeing it as a duplicate of surface=
Comments folks ?
David
On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote:
> Hello all,
>
> I've posted the below message on the forum, and have been
directed
> from there to this mailing list, thus re-posting it.
>
> Idea
>
> I would like to suggest making the paved key for highways
(and
> probably other types of elements) official. Taginfo for
paved:
> [3]http://taginfo.openstreetmap.org/keys/paved#values
>
> The above shows that the key is already being used, but
the Wiki
> doesn't describe this key, instead redirecting Key:paved
to the
> article about Key:surface.
>
> Rationale
>
> Currently, the surface key is being used as a way of
saying that a
> given highway is paved or unpaved, but often the value for
the surface
> key is not a generic paved or unpaved, but a specific
surface type is
> given.This is of course very useful for describing the
particular
> surface type a given highway has. However, in some cases,
a simple
> information on just whether a highway is paved or not,
would be very
> useful. One such case would be navigation software – if a
user chooses
> to avoid unpaved roads, 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. This leads to incorrect (in terms of what the
user expects)
> navigation when, for example, the surface is set to some
value that
> describes an unpaved road, not recognized by the
navigation software –
> if the software assumes that all highways are paved,
unless explicitly
> stated otherwise (by recognized values of known keys),
then, in
> consequence, it assumes that the road in question is
paved.
>
> If the paved key was widely used, then the navigation
software would
> have a simple and clear way of checking whether a given
road is paved
> or not. 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.
>
> I don't mean that we should stop using the paved and
unpaved values
> for the surface key – I'm sure those generic values are
useful in some
> cases. However, using the paved key would be also very
useful. 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.
>
> I believe that adding an article for the paved key to the
Wiki would
> encourage people to use this tag, and navigation software
makers to
> implement support for it in their applications.
>
> What do you think about that?
>
>
>
> Regards,
>
> Tomek
>
> _______________________________________________
> Tagging mailing list
> [4]Tagging at openstreetmap.org
> [5]https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Talk-au mailing list
[6]Talk-au at openstreetmap.org
[7]https://lists.openstreetmap.org/listinfo/talk-au
_______________________________________________
Talk-au mailing list
[8]Talk-au at openstreetmap.org
[9]https://lists.openstreetmap.org/listinfo/talk-au
_______________________________________________
Talk-au mailing list
[10]Talk-au at openstreetmap.org
[11]https://lists.openstreetmap.org/listinfo/talk-au
References
1. mailto:61sundowner at gmail.com
2. mailto:dbannon at internode.on.net
3. http://taginfo.openstreetmap.org/keys/paved#values
4. mailto:Tagging at openstreetmap.org
5. https://lists.openstreetmap.org/listinfo/tagging
6. mailto:Talk-au at openstreetmap.org
7. https://lists.openstreetmap.org/listinfo/talk-au
8. mailto:Talk-au at openstreetmap.org
9. https://lists.openstreetmap.org/listinfo/talk-au
10. mailto:Talk-au at openstreetmap.org
11. https://lists.openstreetmap.org/listinfo/talk-au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20140922/7322a3da/attachment-0001.html>
More information about the Talk-au
mailing list