<!--/*SC*/DOCTYPE HTML/*EC*/-->
<html><head><title></title><style type="text/css"><!-- body{padding:1ex;margin:0;font-family:sans-serif;font-size:small}a[href]{color:-moz-hyperlinktext!important;text-decoration:-moz-anchor-decoration}blockquote{margin:0;border-left:2px solid #144fae;padding-left:1em}blockquote blockquote{border-color:#006312}blockquote blockquote blockquote{border-color:#540000} --></style></head><body><div style="font-family: Arial; font-size: small;" dir="ltr"><div>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).</div>
<div> </div>
<div>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 :-).</div>
<div> </div>
<div>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).</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>So my 2 thoughts:</div>
<div> </div>
<div>(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.</div>
<div> </div>
<div>(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.</div>
<div class="defangedMessage">
<div id="me41936">
<div>David C<br />
</div>
<div><br />
</div>
<div><br />
</div>
<div><br />
</div>
<blockquote class="me41936QuoteMessage" type="cite">
<p dir="ltr">My experience is that surface can have descriptive values that don't immediately indicate if the road is paved or not.</p>
<p dir="ltr">Things like "asphalt" (presuming paved=yes) and "gravel" (presuming paved=no) are common.</p>
<p dir="ltr"> - Ben Kelley</p>
<div class="me41936gmail_quote">On 22 Sep 2014 09:24, "Warin" <<a href="mailto:61sundowner@gmail.com">61sundowner@gmail.com</a>> wrote:
<blockquote class="me41936gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" defang_text="#000000">
<div>Tagging for the render?<br />
<br />
You can have surface=paved or surface =unpaved! More detailes options are also avalible.<br />
<br />
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,<span> asphalt</span> ... 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 ...<br />
<br />
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.<br />
<br />
<br />
<br />
On 21/09/2014 12:25 PM, Ben Kelley wrote:</div>
<blockquote type="cite">
<p dir="ltr">Hi.</p>
<p dir="ltr">This sounds like a very good suggestion. Often you just want to know if the road is paved.</p>
<p dir="ltr">It seems like that was the original intent of surface=, but that is not how it gets used now.</p>
<p dir="ltr">How surface= implies paved= sounds good too.</p>
<p dir="ltr"> - Ben.</p>
<div class="me41936gmail_quote">On 21 Sep 2014 11:03, "David Bannon" <<a href="mailto:dbannon@internode.on.net" target="_blank">dbannon@internode.on.net</a>> wrote:
<blockquote class="me41936gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br />
Interesting proposal on the OSM Tagging list. Oz would have a<br />
unpaved/paved ratio as higher that most countries, we should have an<br />
opinion on this.<br />
<br />
So far, reaction has been mixed, some (including myself) welcoming it<br />
and some seeing it as a duplicate of surface=<br />
<br />
Comments folks ?<br />
<br />
David<br />
<br />
On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote:<br />
> Hello all,<br />
><br />
> I've posted the below message on the forum, and have been directed<br />
> from there to this mailing list, thus re-posting it.<br />
><br />
> Idea<br />
><br />
> I would like to suggest making the paved key for highways (and<br />
> probably other types of elements) official. Taginfo for paved:<br />
> <a href="http://taginfo.openstreetmap.org/keys/paved#values" target="_blank">http://taginfo.openstreetmap.org/keys/paved#values</a><br />
><br />
> The above shows that the key is already being used, but the Wiki<br />
> doesn't describe this key, instead redirecting Key:paved to the<br />
> article about Key:surface.<br />
><br />
> Rationale<br />
><br />
> Currently, the surface key is being used as a way of saying that a<br />
> given highway is paved or unpaved, but often the value for the surface<br />
> key is not a generic paved or unpaved, but a specific surface type is<br />
> given.This is of course very useful for describing the particular<br />
> surface type a given highway has. However, in some cases, a simple<br />
> information on just whether a highway is paved or not, would be very<br />
> useful. One such case would be navigation software – if a user chooses<br />
> to avoid unpaved roads, the software can check the value of the<br />
> surface key, but in practice most (all?) of the navigation software<br />
> only checks for a subset of all the possible values the surface key<br />
> can have. This leads to incorrect (in terms of what the user expects)<br />
> navigation when, for example, the surface is set to some value that<br />
> describes an unpaved road, not recognized by the navigation software –<br />
> if the software assumes that all highways are paved, unless explicitly<br />
> stated otherwise (by recognized values of known keys), then, in<br />
> consequence, it assumes that the road in question is paved.<br />
><br />
> If the paved key was widely used, then the navigation software would<br />
> have a simple and clear way of checking whether a given road is paved<br />
> or not. The default value of the paved key for highways could be yes,<br />
> so that it would be consistent with the assumption that highways in<br />
> general are paved.<br />
><br />
> I don't mean that we should stop using the paved and unpaved values<br />
> for the surface key – I'm sure those generic values are useful in some<br />
> cases. However, using the paved key would be also very useful. Also,<br />
> the surface=paved could also implicate paved=yes and similarly<br />
> surface=unpaved could implicate paved=no, so that duplication of the<br />
> information could be avoided when the generic paved and unpaved values<br />
> are set for the surface key.<br />
><br />
> I believe that adding an article for the paved key to the Wiki would<br />
> encourage people to use this tag, and navigation software makers to<br />
> implement support for it in their applications.<br />
><br />
> What do you think about that?<br />
><br />
><br />
><br />
> Regards,<br />
><br />
> Tomek<br />
><br />
> _______________________________________________<br />
> Tagging mailing list<br />
> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br />
> <a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br />
<br />
<br />
<br />
_______________________________________________<br />
Talk-au mailing list<br />
<a href="mailto:Talk-au@openstreetmap.org" target="_blank">Talk-au@openstreetmap.org</a><br />
<a href="https://lists.openstreetmap.org/listinfo/talk-au" target="_blank">https://lists.openstreetmap.org/listinfo/talk-au</a></blockquote>
</div>
<br />
<fieldset><br />
</fieldset>
<br />
<pre>
_______________________________________________
Talk-au mailing list
<a href="mailto:Talk-au@openstreetmap.org" target="_blank">Talk-au@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/talk-au" target="_blank">https://lists.openstreetmap.org/listinfo/talk-au</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
<div><u>_______________________________________________</u></div>
<div>Talk-au mailing list</div>
<div><a href="mailto:Talk-au@openstreetmap.org">Talk-au@openstreetmap.org</a></div>
<div><a href="https://lists.openstreetmap.org/listinfo/talk-au">https://lists.openstreetmap.org/listinfo/talk-au</a></div>
</blockquote>
</div>
</div>
</div></body></html>