[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:


  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
  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 ?
  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
  > from there to this mailing list, thus re-posting it.
  > Idea
  > I would like to suggest making the paved key for highways
  > probably other types of elements) official. Taginfo for
  > [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
  > 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
  > 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
  > 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
  > 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

Talk-au mailing list
[8]Talk-au at openstreetmap.org


Talk-au mailing list

[10]Talk-au at openstreetmap.org



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