<div dir="ltr">Richard's arguments seem spot on. I hadn't thought it through that way, and his viewpoint is coming from two regimes.<div><br></div><div>Richard wrote:</div><div><span style="font-family:arial,sans-serif;font-size:16px">Please, please, please don't fall into the trap of trying to optimise for</span><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">data consumers when you're not a data consumer. OSM has far too much of this</span><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">and it's resulted in a lot of nonsense tags over the years. Since you'd</span><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">never reach 100% coverage for paved=, the data consumer would need to</span><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">continue to parse the surface= tag. So the main effect would be to make life</span><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">_harder_ for data consumers, who would now have to check not just three</span><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">surface-type tags (surface=, tracktype=, smoothness=) but four. Or in other</span><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">words:</span><br style="font-family:arial,sans-serif;font-size:16px"></div><div><span style="font-family:arial,sans-serif;font-size:16px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:16px">+1</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 22, 2014 at 3:54 PM,  <span dir="ltr"><<a href="mailto:phil@trigpoint.me.uk" target="_blank">phil@trigpoint.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Toll? I assume that means the same in US English as in UK English?<br>
<br>
You really have to pay to use cycleways? How is the toll collected and enforced?<br>
<br>
Phil (trigpoint )<br>
<div><div class="h5"><br>
On Sun Sep 21 2014 23:36:04 GMT+0100 (BST), Paul Johnson wrote:<br>
> Along with this, I really hope renderers start computing surface=* and<br>
> toll=* values for ALL ways.  I say this since "surface=asphalt,<br>
> highway=cyclway" is an exceptionally rare combination in the midwestern US,<br>
> but "highway=cycleway, surface=gravel, toll=yes" is not.<br>
><br>
> On Sun, Sep 21, 2014 at 2:29 AM, Pee Wee <<a href="mailto:piewie32@gmail.com">piewie32@gmail.com</a>> wrote:<br>
><br>
> > -1<br>
> ><br>
> > A renderer/router is perfectly capable of deciding what he thinks is<br>
> > paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or<br>
> > unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map<br>
> > what you see. As you may have guessed I prefer surface=asphalt over<br>
> > surface=paved since the last one could mean that it is gravel.<br>
> ><br>
> > Cheers<br>
> > PeeWee32<br>
> ><br>
> > 2014-09-21 2:49 GMT+02:00 David Bannon <<a href="mailto:dbannon@internode.on.net">dbannon@internode.on.net</a>>:<br>
> ><br>
> >><br>
> >> yes, agree strongly. Surface= is a good tag, provides important info but<br>
> >> it is far too fine grained. Someone setting up a route cannot be<br>
> >> expected to sift through all the possible values.<br>
> >><br>
> >> Similarly, we may well have a chance to get the renderers to respect a<br>
> >> clear, on/off tag like the proposed and show it on the maps too.<br>
> >><br>
> >> I see no problem with both tags being used.<br>
> >><br>
> >> I think sometimes we put too much detail in the database and risk making<br>
> >> the data unusable because of that. Mention making the data usable, we<br>
> >> see charges of "tagging for the renderer". But this is important, I have<br>
> >> detailed life threatening issues resulting from unclear maps. This<br>
> >> proposal will provide valuable, dare I say "usable" info for consumers !<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">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>
> >> Tagging mailing list<br>
> >> <a href="mailto:Tagging@openstreetmap.org">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>
> > --<br>
> > Verbeter de wereld. Word mapper voor Openstreetmap<br>
</div></div>> > <<a href="http://www.openstreetmap.org" target="_blank">http://www.openstreetmap.org</a>>.<br>
<span class="">> ><br>
> > _______________________________________________<br>
> > Tagging mailing list<br>
> > <a href="mailto:Tagging@openstreetmap.org">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>
--<br>
</span>Sent from my Jolla<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Dave Swarthout<br>Homer, Alaska<br>Chiang Mai, Thailand<br>Travel Blog at <a href="http://dswarthout.blogspot.com" target="_blank">http://dswarthout.blogspot.com</a></div>
</div>