Re: [Tagging] New key proposal - paved=yes/no

[Tom Pfeifer]

We are only reiterating the fact that being paved or not is subjective to
the renderer/router/data consumer, based on the intention of the particular
user, and thus a tag for paved=* is counter-productive.

John F. Eldredge wrote on 2014-10-01 14:44:

Compacted usually means compacted earth (the soil has been packed more densely, 
but no other hard surface has been added). A dirt road simply has the native 
soil exposed, with perhaps some grading done, but again no topping added. To my 
mind, neither of
these count as "paved".


On September 30, 2014 4:57:58 AM CDT, Erik Johansson  wrote:

These are more than 90% of values for surface, categorize them as
paved/unpaved the rest as unpaved.

surface=

asphalt
unpaved
paved
gravel
ground
dirt
grass
concrete
paving_stones
sand
cobblestone
compacted

paved=yes will remove then need for parsing those last % of surface=*
values, not sure it's worth it. To think that there is only one
definition of paved=yes, is a big mistake. There are few tags in OSM
that are specific enough to mean the same thing all over the world.

[...]


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[John F. Eldredge]

Compacted usually means compacted earth (the soil has been packed more densely, 
but no other hard surface has been added). A dirt road simply has the native 
soil exposed, with perhaps some grading done, but again no topping added.  To 
my mind, neither of these count as "paved".


On September 30, 2014 4:57:58 AM CDT, Erik Johansson  wrote:
>These are more than 90% of values for surface, categorize them as
>paved/unpaved the rest as unpaved.
>
>surface=
>
>asphalt
>unpaved
>paved
>gravel
>ground
>dirt
>grass
>concrete
>paving_stones
>sand
>cobblestone
>compacted
>
>paved=yes will remove then need for parsing those last % of surface=*
>values, not sure it's worth it. To think that there is only one
>definition of paved=yes, is a big mistake. There are few tags in OSM
>that are specific enough to mean the same thing all over the world.
>
>
>
>On Mon, Sep 22, 2014 at 1:42 AM, David Bannon
> wrote:
>> On Mon, 2014-09-22 at 00:23 +0200, Tomasz Kaźmierczak wrote:
>> ..A good suggestion ...
>>
>> So it seems that yet again, we are going to reject this attempt to
>solve
>> a real problem. Looking at the neg replies, because its not useful
>for
>> bike riders; not useful for a number of undefined edge cases; is a
>> duplicate of surface=.
>>
>> Thats just plain not true ! There is no suggestion that paved= should
>be
>> used instead of surface=. I use surface= on all unsealed roads I map
>and
>> would continue to do so if I also used paved=no.
>>
>> But there are 34 official values for surface= and 3581 values used.
>It
>> is very plain that the mapping community want surface= as a fine
>> grained, very detailed key. And thats great, people making
>specialised
>> maps or engines can use those values, display them in a meaningful
>way
>> to people they understand. My data will help them.
>>
>> But the vast majority of people just want to know that the road may
>not
>> be what they are used to. Thats all. And paved= does that easily.
>>
>> In places like Australia, that information can be a life or death
>thing.
>> People die here because they are inexperienced or ill equipped for
>roads
>> they tackle. Generally visitors from Europe or North America.
>>
>> Please folks, think of the big picture, not the edge cases.
>>
>> David
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>-- 
>/emj
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Erik Johansson]

These are more than 90% of values for surface, categorize them as
paved/unpaved the rest as unpaved.

surface=

asphalt
unpaved
paved
gravel
ground
dirt
grass
concrete
paving_stones
sand
cobblestone
compacted

paved=yes will remove then need for parsing those last % of surface=*
values, not sure it's worth it. To think that there is only one
definition of paved=yes, is a big mistake. There are few tags in OSM
that are specific enough to mean the same thing all over the world.



On Mon, Sep 22, 2014 at 1:42 AM, David Bannon  wrote:
> On Mon, 2014-09-22 at 00:23 +0200, Tomasz Kaźmierczak wrote:
> ..A good suggestion ...
>
> So it seems that yet again, we are going to reject this attempt to solve
> a real problem. Looking at the neg replies, because its not useful for
> bike riders; not useful for a number of undefined edge cases; is a
> duplicate of surface=.
>
> Thats just plain not true ! There is no suggestion that paved= should be
> used instead of surface=. I use surface= on all unsealed roads I map and
> would continue to do so if I also used paved=no.
>
> But there are 34 official values for surface= and 3581 values used. It
> is very plain that the mapping community want surface= as a fine
> grained, very detailed key. And thats great, people making specialised
> maps or engines can use those values, display them in a meaningful way
> to people they understand. My data will help them.
>
> But the vast majority of people just want to know that the road may not
> be what they are used to. Thats all. And paved= does that easily.
>
> In places like Australia, that information can be a life or death thing.
> People die here because they are inexperienced or ill equipped for roads
> they tackle. Generally visitors from Europe or North America.
>
> Please folks, think of the big picture, not the edge cases.
>
> David
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
/emj

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Georg Feddern]

Am 25.09.2014 11:48, schrieb Pieren:

I think the main issue raised in this thread is to decide if each data
consumer can decide alone what surface is paved or not (using this
"surface" key and its hundreds values) or if we are able to find a
common definition stored in the osm db (using this "paved" key).
With the first option, the "paved" attribut can be inconsistent
between applications. With the second option, the "paved" attribut is
subject of personal interpretations from the contributors but this
could be moderated when the surface key is also present.


Definitely now we all know that there are different opinions for e.g. 
gravel as paved or unpaved at mappers and consumers.


And where is the benefit to manifest the paved/unpaved meaning in the 
database?

Beside edit wars I see absolutely nothing ...
I vote for inconsistencies between applications - and not between mappers!

A second tag would not change the mind of a consumer about the meaning ...

Georg

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Pieren]

On Wed, Sep 24, 2014 at 8:16 PM, Pee Wee  wrote:
> No it not a language problem  or a dictionary issue. It's about an OSM data
> consumer (openfietmap)  that thinks it is important to for cyclist to know
> what type of paving can be expected.  Paved, unpaved and semi-paved to keep
> it simple. I think this is OK and it works for me.

I think the main issue raised in this thread is to decide if each data
consumer can decide alone what surface is paved or not (using this
"surface" key and its hundreds values) or if we are able to find a
common definition stored in the osm db (using this "paved" key).
With the first option, the "paved" attribut can be inconsistent
between applications. With the second option, the "paved" attribut is
subject of personal interpretations from the contributors but this
could be moderated when the surface key is also present.

Pieren

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

There's historic precident outside Kansas as well.  What is now the Arroyo
Seco Freeway in LA originally opened as a pinewood, limited access,
elevated bicycle tollway under the name of California Cycleway sometime
around 1890.

On Mon, Sep 22, 2014 at 9:32 AM, John F. Eldredge 
wrote:

> I am American, and the concept of a toll cycleway is not one I have
> encountered either.
>
>
>
>
> On September 22, 2014 3:55:03 AM p...@trigpoint.me.uk wrote:
>
>  Toll? I assume that means the same in US English as in UK English?
>>
>> You really have to pay to use cycleways? How is the toll collected and
>> enforced?
>>
>> Phil (trigpoint )
>>
>> On Sun Sep 21 2014 23:36:04 GMT+0100 (BST), Paul Johnson wrote:
>> > Along with this, I really hope renderers start computing surface=* and
>> > toll=* values for ALL ways.  I say this since "surface=asphalt,
>> > highway=cyclway" is an exceptionally rare combination in the midwestern
>> US,
>> > but "highway=cycleway, surface=gravel, toll=yes" is not.
>> >
>> > On Sun, Sep 21, 2014 at 2:29 AM, Pee Wee  wrote:
>> >
>> > > -1
>> > >
>> > > A renderer/router is perfectly capable of deciding what he thinks is
>> > > paved/unpaved. He can decide whether he calls gravel / fine_gravel
>> paved or
>> > > unpaved. Do not leave the decision paved/unpaved  up to the mapper.
>> Map
>> > > what you see. As you may have guessed I prefer surface=asphalt over
>> > > surface=paved since the last one could mean that it is gravel.
>> > >
>> > > Cheers
>> > > PeeWee32
>> > >
>> > > 2014-09-21 2:49 GMT+02:00 David Bannon :
>> > >
>> > >>
>> > >> yes, agree strongly. Surface= is a good tag, provides important info
>> but
>> > >> it is far too fine grained. Someone setting up a route cannot be
>> > >> expected to sift through all the possible values.
>> > >>
>> > >> Similarly, we may well have a chance to get the renderers to respect
>> a
>> > >> clear, on/off tag like the proposed and show it on the maps too.
>> > >>
>> > >> I see no problem with both tags being used.
>> > >>
>> > >> I think sometimes we put too much detail in the database and risk
>> making
>> > >> the data unusable because of that. Mention making the data usable, we
>> > >> see charges of "tagging for the renderer". But this is important, I
>> have
>> > >> detailed life threatening issues resulting from unclear maps. This
>> > >> proposal will provide valuable, dare I say "usable" info for
>> consumers !
>> > >>
>> > >> 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:
>> > >> > 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. Howev

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

On Mon, Sep 22, 2014 at 3:54 AM,  wrote:

> Toll? I assume that means the same in US English as in UK English?
>

Yes, as in you need to pay a fee to travel on it to use it.


> You really have to pay to use cycleways? How is the toll collected and
> enforced?
>

I've encountered them in a couple places.  In Oregon, these are as far as
I'm aware, exclusively on ferries, in which you hand off your quarter (or
is it a half dollar now?) to the ferry operator.  In Kansas, it's a receipt
system and you have unlimited travel for the X number of days you prepaid
for.  It's not uncommon (possibly preferred?) for people to tape their
receipt to the bars.  Fares are checked by local and county police along
the route as well as regular patrols by the KHP, and I think you're allowed
to camp short-term along the right of way in designated spots.

Basically, in the Kansas case, the cycleways are long distance, largely
extremely rural, and the fares pay for a) safety patrols to ensure the ways
are clear, not washed out, not flooded, nobody died or got stranded along
the way, and b) toll collection.

Not to say that the Kansas model would scale or is particularly well
enforced, I'm just saying Kansas has a lot of toll cycleway mileage and
it's something to be aware of.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Pee Wee]

No it not a language problem  or a dictionary issue. It's about an OSM data
consumer (openfietmap)  that thinks it is important to for cyclist to know
what type of paving can be expected.  Paved, unpaved and semi-paved to keep
it simple. I think this is OK and it works for me.

Cheers
Peewee32

2014-09-24 19:03 GMT+02:00 Martin Koppenhoefer :

>
> 2014-09-24 18:40 GMT+02:00 Pee Wee :
>
>> I would not call sand "paved" but when we look at e.g.gravel /
>> fine_gravel the opinions will vary. The OSM based Openfietsmap
>> (cycling map for Garmin
>> devices) has yet another value called "semi-paved".  All based on current
>> OSM tags. (surface, tracktype, smoothness etc. ) In my experience this
>> works pretty well.
>>
>
>
> "semi-paved" does not make any sense to me (besides maybe something
> divided in two along its direction, (that would probably be half-paved)) .
> I've looked the word "paved" up in an online dictionary and it seems to
> confirm what I thought it would mean.
> http://www.merriam-webster.com/dictionary/pave
>
> 1
> *:*  to lay or cover with material (as asphalt or concrete) that forms a
> firm level surface for travel
> 2
> *:*  to cover firmly and solidly as if with paving material
> 3
> *:*  to serve as a covering or pavement
>  of
>
>
> 1 is dealing with asphalt or concrete (firm level surface)
> 2 is dealing with different stuff (as if it was paved), i.e. comparing to
> 3 is not useful for us here
>
>
> gravel does not seem to fit into any of these categories. Maybe this is a
> language problem? E.g. in German you could translate "paved" as either
> "gepflastert"/"asphaltiert"/"betoniert" or as "befestigt", where the latter
> would indeed include gravel, fine gravel etc. (but in these cases "paved"
> would not be a suitable translation of "befestigt").
>
> cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Verbeter de wereld. Word mapper voor Openstreetmap
.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Martin Koppenhoefer]

2014-09-24 18:40 GMT+02:00 Pee Wee :

> I would not call sand "paved" but when we look at e.g.gravel / fine_gravel
> the opinions will vary. The OSM based Openfietsmap
> (cycling map for Garmin devices)
> has yet another value called "semi-paved".  All based on current OSM tags.
> (surface, tracktype, smoothness etc. ) In my experience this works pretty
> well.
>


"semi-paved" does not make any sense to me (besides maybe something divided
in two along its direction, (that would probably be half-paved)) . I've
looked the word "paved" up in an online dictionary and it seems to confirm
what I thought it would mean.
http://www.merriam-webster.com/dictionary/pave

1
*:*  to lay or cover with material (as asphalt or concrete) that forms a
firm level surface for travel
2
*:*  to cover firmly and solidly as if with paving material
3
*:*  to serve as a covering or pavement
 of


1 is dealing with asphalt or concrete (firm level surface)
2 is dealing with different stuff (as if it was paved), i.e. comparing to
3 is not useful for us here


gravel does not seem to fit into any of these categories. Maybe this is a
language problem? E.g. in German you could translate "paved" as either
"gepflastert"/"asphaltiert"/"betoniert" or as "befestigt", where the latter
would indeed include gravel, fine gravel etc. (but in these cases "paved"
would not be a suitable translation of "befestigt").

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Pee Wee]

>
> As per Peewee post - the definition of 'paved' vs 'unpaved' is open to
> interpretation. But I don't think anyone would accept 'sand' as being
> 'paved'?
>
I would not call sand "paved" but when we look at e.g.gravel / fine_gravel
the opinions will vary. The OSM based Openfietsmap
(cycling map for Garmin devices)
has yet another value called "semi-paved".  All based on current OSM tags.
(surface, tracktype, smoothness etc. ) In my experience this works pretty
well.

Cheers
PeeWee32
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Martin Koppenhoefer]

2014-09-24 1:40 GMT+02:00 Warin <61sundow...@gmail.com>:

> One more point against that I have not seen (yet)  ..  with this
> additional tag you can get conflicts e.g.
>
> Paved=yes
> Surface=Unpaved
>
> Oh .. you want to exclude paved/unpaved from surface? Ok, then we get
>
> Paved=yes
> Surface=sand
>



I think these conflicts are not worse than wrong data, actually they are
better, because you can see an obvious inconsistency and can resurvey,
while otherwise you would only have a wrong tag in the db and could not
find it easily.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Warin]

On 24/09/2014 1:27 AM, tagging-requ...@openstreetmap.org wrote:
Date: Tue, 23 Sep 2014 15:43:07 +0200 From: Martin Koppenhoefer 
 To: "Tag discussion, strategy and related 
tools"  Subject: Re: [Tagging] New key 
proposal - paved=yes/no Message-ID: 
 
Content-Type: text/plain; charset="utf-8" 2014-09-23 1:12 GMT+02:00 
David Bannon :


here we are on the tagging mailing list, to discuss tagging of objects 
in the OSM database. With current tags it is indeed possible to say 
whether a road is paved or not according to your own definition. The 
fact that a particular rendering (carto osm) doesn't currently display 
the paved attribute of a road has nothing to do when the question is 
whether current tagging works or not. In fact, the maintainers of 
carto osm have recently been discussing how to display unpaved roads 
differently from paved ones, so this could come in the future. This is 
really not an argument for the introduction of a new tag. cheers, 
Martin -- next part


Message: 3 Date: Tue, 23 Sep 2014 07:54:43 -0700 (PDT) From: Richard 
Fairhurst  To: Tagging@openstreetmap.org 
Subject: Re: [Tagging] New key proposal - paved=yes/no Message-ID: 
<1411484083204-5818261.p...@n5.nabble.com> Content-Type: text/plain; 
charset=us-ascii David Bannon wrote:

The truth is the paved/unpaved state of a road is being widely
ignored or incorrectly interpreted. The map at osm.org illustrates
my point, perhaps as well as an XKCD cartoon :-)

Yep, absolutely. But the way to fix that is to get the map at osm.org to
render surfaces, using the existing tags. (And I agree, that would be a
great enhancement.)

I was about to point you to
https://github.com/gravitystorm/openstreetmap-carto/issues/110 but then I
noticed that you're all over it already. :)

cheers
Richard



One more point against that I have not seen (yet)  ..  with this 
additional tag you can get conflicts e.g.


Paved=yes
Surface=Unpaved

Oh .. you want to exclude paved/unpaved from surface? Ok, then we get

Paved=yes
Surface=sand

As per Peewee post - the definition of 'paved' vs 'unpaved' is open to 
interpretation. But I don't think anyone would accept 'sand' as being 
'paved'?


Some might consider 'gravel' to be 'paved' .. most won't. It is an 
improvement over say sand, but then any track is an improvement over 
virgin territory. Much better to get the detail of the surface. I do tag 
surface=unpaved where the surface is made up of multiple things - one 
length would be sand, another dirt .. and probably some bits of 
bulldust, gibber and salt lake. Where it is substantially on type then 
I'll put that surface down. Then the renderer can decide what is 'paved' 
... anything else (including unknowns) should be classified as 'unpaved' 
... this is the safe way as more people selecting paved may not be able 
to use unpaved .. where as those selecting unpaved would be capable of 
using paved. (And as points out it is a rendering/routing problem that 
should be addressed by them, not the taggers).


Suggest the proposal is retracted, and other courses taken to rectify 
this issue?





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Richard Fairhurst]

David Bannon wrote:
> The truth is the paved/unpaved state of a road is being widely 
> ignored or incorrectly interpreted. The map at osm.org illustrates 
> my point, perhaps as well as an XKCD cartoon :-)

Yep, absolutely. But the way to fix that is to get the map at osm.org to
render surfaces, using the existing tags. (And I agree, that would be a
great enhancement.)

I was about to point you to
https://github.com/gravitystorm/openstreetmap-carto/issues/110 but then I
noticed that you're all over it already. :)

cheers
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/New-key-proposal-paved-yes-no-tp5817998p5818261.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Martin Koppenhoefer]

2014-09-23 1:12 GMT+02:00 David Bannon :

>
> Zoom in a bit at OSM and pop out the Key, it shows how unsurfaced roads
> are rendered. But you don't see that on the map. Current model does not
> work ! We can continue to argue is OK anyway or we can fix it. Choose.
>



here we are on the tagging mailing list, to discuss tagging of objects in
the OSM database. With current tags it is indeed possible to say whether a
road is paved or not according to your own definition. The fact that a
particular rendering (carto osm) doesn't currently display the paved
attribute of a road has nothing to do when the question is whether current
tagging works or not. In fact, the maintainers of carto osm have recently
been discussing how to display unpaved roads differently from paved ones,
so this could come in the future. This is really not an argument for the
introduction of a new tag.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[David Bannon]

Ah, Richard, its very hard to argue with someone who uses XKCD to
illustrate their point, unfair !

But, "no official tags" ? truish. But when I am speaking to someone, I
am free to make up new words and grammar, but should not expect to be
understood. Better to agree in advance.

And yes, bike riders have a different view of whats paved. At the risk
of incurring an horrendous attack from the lycra clad, when it comes to
looking at maps before travelling to new destinations, they are a
subset. Maybe not where you live. A subset that should use surface=,
should be allowed to and supported doing so. I'll keep using surface=

Thirdly, a bit more philosophical, do you think that all OSM keys are
locked in stone ?  Should we never have the chance to review whats
happening, decide we got it a bit wrong, try again ? The sins of the
father shall be visited upon the son.

The truth is the paved/unpaved state of a road is being widely ignored
or incorrectly interpreted. The map at osm.org illustrates my point,
perhaps as well as an XKCD cartoon :-)

Zoom in a bit at OSM and pop out the Key, it shows how unsurfaced roads
are rendered. But you don't see that on the map. Current model does not
work ! We can continue to argue is OK anyway or we can fix it. Choose.

David



On Mon, 2014-09-22 at 01:13 -0700, Richard Fairhurst wrote:
> Tomasz Kaźmierczak wrote:
> > I would like to suggest making the paved key for highways 
> > (and probably other types of elements) official.
> 
> First of all, this is OSM: there are no "official" or "unofficial" tags. Use
> what you like as long as it accords with core OSM tagging principles such as
> verifiability.
> 
> Secondly, however, as someone who parses surface tagging for both routing
> and rendering at http://cycle.travel/map, this proposal is unnecessary.
> (cycle.travel renders paved cycleways, firm unpaved and rough unpaved
> tracks/cycleways differently, and applies different routing penalties based
> on surface.)
> 
> Your use case is that the new tag would make it easier for data consumers to
> tell whether a road is paved or not. It wouldn't. It's already very easy.
> You simply have a list of the surface= values that your application counts
> as paved (and this isn't as universal as you might think: are cobblestones
> "paved"? They're fine if slow in a car, but torture on a thin-tyred road
> bike).
> 
> This is literally just two lines of code in an osm2pgsql Lua tag transform
> script, and thus available to anyone using the standard rendering toolchain.
> If you don't want to do it this way, you can run a Postgres query
> post-import, or just some extra conditions in your Mapnik/Carto .mml file.
> It's really not hard.
> 
> Please, please, please don't fall into the trap of trying to optimise for
> data consumers when you're not a data consumer. OSM has far too much of this
> and it's resulted in a lot of nonsense tags over the years. Since you'd
> never reach 100% coverage for paved=, the data consumer would need to
> continue to parse the surface= tag. So the main effect would be to make life
> _harder_ for data consumers, who would now have to check not just three
> surface-type tags (surface=, tracktype=, smoothness=) but four. Or in other
> words:
> 
> http://xkcd.com/927/
> 
> cheers
> Richard
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/New-key-proposal-paved-yes-no-tp5817998p5818124.html
> Sent from the Tagging mailing list archive at Nabble.com.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[John F. Eldredge]

I am American, and the concept of a toll cycleway is not one I have 
encountered either.




On September 22, 2014 3:55:03 AM p...@trigpoint.me.uk wrote:


Toll? I assume that means the same in US English as in UK English?

You really have to pay to use cycleways? How is the toll collected and 
enforced?


Phil (trigpoint )

On Sun Sep 21 2014 23:36:04 GMT+0100 (BST), Paul Johnson wrote:
> Along with this, I really hope renderers start computing surface=* and
> toll=* values for ALL ways.  I say this since "surface=asphalt,
> highway=cyclway" is an exceptionally rare combination in the midwestern US,
> but "highway=cycleway, surface=gravel, toll=yes" is not.
>
> On Sun, Sep 21, 2014 at 2:29 AM, Pee Wee  wrote:
>
> > -1
> >
> > A renderer/router is perfectly capable of deciding what he thinks is
> > paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or
> > unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map
> > what you see. As you may have guessed I prefer surface=asphalt over
> > surface=paved since the last one could mean that it is gravel.
> >
> > Cheers
> > PeeWee32
> >
> > 2014-09-21 2:49 GMT+02:00 David Bannon :
> >
> >>
> >> yes, agree strongly. Surface= is a good tag, provides important info but
> >> it is far too fine grained. Someone setting up a route cannot be
> >> expected to sift through all the possible values.
> >>
> >> Similarly, we may well have a chance to get the renderers to respect a
> >> clear, on/off tag like the proposed and show it on the maps too.
> >>
> >> I see no problem with both tags being used.
> >>
> >> I think sometimes we put too much detail in the database and risk making
> >> the data unusable because of that. Mention making the data usable, we
> >> see charges of "tagging for the renderer". But this is important, I have
> >> detailed life threatening issues resulting from unclear maps. This
> >> proposal will provide valuable, dare I say "usable" info for consumers !
> >>
> >> 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:
> >> > 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,
> >> >
>

Re: [Tagging] New key proposal - paved=yes/no

[Dave Swarthout]

Richard's arguments seem spot on. I hadn't thought it through that way, and
his viewpoint is coming from two regimes.

Richard wrote:
Please, please, please don't fall into the trap of trying to optimise for
data consumers when you're not a data consumer. OSM has far too much of this
and it's resulted in a lot of nonsense tags over the years. Since you'd
never reach 100% coverage for paved=, the data consumer would need to
continue to parse the surface= tag. So the main effect would be to make life
_harder_ for data consumers, who would now have to check not just three
surface-type tags (surface=, tracktype=, smoothness=) but four. Or in other
words:

+1

On Mon, Sep 22, 2014 at 3:54 PM,  wrote:

> Toll? I assume that means the same in US English as in UK English?
>
> You really have to pay to use cycleways? How is the toll collected and
> enforced?
>
> Phil (trigpoint )
>
> On Sun Sep 21 2014 23:36:04 GMT+0100 (BST), Paul Johnson wrote:
> > Along with this, I really hope renderers start computing surface=* and
> > toll=* values for ALL ways.  I say this since "surface=asphalt,
> > highway=cyclway" is an exceptionally rare combination in the midwestern
> US,
> > but "highway=cycleway, surface=gravel, toll=yes" is not.
> >
> > On Sun, Sep 21, 2014 at 2:29 AM, Pee Wee  wrote:
> >
> > > -1
> > >
> > > A renderer/router is perfectly capable of deciding what he thinks is
> > > paved/unpaved. He can decide whether he calls gravel / fine_gravel
> paved or
> > > unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map
> > > what you see. As you may have guessed I prefer surface=asphalt over
> > > surface=paved since the last one could mean that it is gravel.
> > >
> > > Cheers
> > > PeeWee32
> > >
> > > 2014-09-21 2:49 GMT+02:00 David Bannon :
> > >
> > >>
> > >> yes, agree strongly. Surface= is a good tag, provides important info
> but
> > >> it is far too fine grained. Someone setting up a route cannot be
> > >> expected to sift through all the possible values.
> > >>
> > >> Similarly, we may well have a chance to get the renderers to respect a
> > >> clear, on/off tag like the proposed and show it on the maps too.
> > >>
> > >> I see no problem with both tags being used.
> > >>
> > >> I think sometimes we put too much detail in the database and risk
> making
> > >> the data unusable because of that. Mention making the data usable, we
> > >> see charges of "tagging for the renderer". But this is important, I
> have
> > >> detailed life threatening issues resulting from unclear maps. This
> > >> proposal will provide valuable, dare I say "usable" info for
> consumers !
> > >>
> > >> 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:
> > >> > 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 us

Re: [Tagging] New key proposal - paved=yes/no

[phil]

Toll? I assume that means the same in US English as in UK English?

You really have to pay to use cycleways? How is the toll collected and 
enforced? 

Phil (trigpoint ) 

On Sun Sep 21 2014 23:36:04 GMT+0100 (BST), Paul Johnson wrote:
> Along with this, I really hope renderers start computing surface=* and
> toll=* values for ALL ways.  I say this since "surface=asphalt,
> highway=cyclway" is an exceptionally rare combination in the midwestern US,
> but "highway=cycleway, surface=gravel, toll=yes" is not.
> 
> On Sun, Sep 21, 2014 at 2:29 AM, Pee Wee  wrote:
> 
> > -1
> >
> > A renderer/router is perfectly capable of deciding what he thinks is
> > paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or
> > unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map
> > what you see. As you may have guessed I prefer surface=asphalt over
> > surface=paved since the last one could mean that it is gravel.
> >
> > Cheers
> > PeeWee32
> >
> > 2014-09-21 2:49 GMT+02:00 David Bannon :
> >
> >>
> >> yes, agree strongly. Surface= is a good tag, provides important info but
> >> it is far too fine grained. Someone setting up a route cannot be
> >> expected to sift through all the possible values.
> >>
> >> Similarly, we may well have a chance to get the renderers to respect a
> >> clear, on/off tag like the proposed and show it on the maps too.
> >>
> >> I see no problem with both tags being used.
> >>
> >> I think sometimes we put too much detail in the database and risk making
> >> the data unusable because of that. Mention making the data usable, we
> >> see charges of "tagging for the renderer". But this is important, I have
> >> detailed life threatening issues resulting from unclear maps. This
> >> proposal will provide valuable, dare I say "usable" info for consumers !
> >>
> >> 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:
> >> > 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
> >> > Tagging@openstreetmap.org
> >> > https://lis

Re: [Tagging] New key proposal - paved=yes/no

[Martin Koppenhoefer]

2014-09-22 0:42 GMT+02:00 Paul Johnson :

> On Sun, Sep 21, 2014 at 4:06 AM, Volker Schmidt  wrote:
>
>> For bicycle routing the paved information is not very useful.
>
>
> I strongly dispute this.  In the US, where practical bicycles are the
> exception, not the rule, surface information is exceptionally important.



Volker did not write that "surface" information did not matter, he said
that "paved" doesn't hit it. For example a road paved with cobblestones (or
even worse an antique roman road) are very hard to use in bicycle (mostly)
and you'd generally want to avoid it, still it would be "paved".

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Martin Koppenhoefer]

2014-09-22 0:36 GMT+02:00 Paul Johnson :

> Along with this, I really hope renderers start computing surface=* and
> toll=* values for ALL ways.  I say this since "surface=asphalt,
> highway=cyclway" is an exceptionally rare combination in the midwestern US,
> but "highway=cycleway, surface=gravel, toll=yes" is not.



You should probably file a ticket with some of the routing engines to have
this solved.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Richard Fairhurst]

Tomasz Kaźmierczak wrote:
> I would like to suggest making the paved key for highways 
> (and probably other types of elements) official.

First of all, this is OSM: there are no "official" or "unofficial" tags. Use
what you like as long as it accords with core OSM tagging principles such as
verifiability.

Secondly, however, as someone who parses surface tagging for both routing
and rendering at http://cycle.travel/map, this proposal is unnecessary.
(cycle.travel renders paved cycleways, firm unpaved and rough unpaved
tracks/cycleways differently, and applies different routing penalties based
on surface.)

Your use case is that the new tag would make it easier for data consumers to
tell whether a road is paved or not. It wouldn't. It's already very easy.
You simply have a list of the surface= values that your application counts
as paved (and this isn't as universal as you might think: are cobblestones
"paved"? They're fine if slow in a car, but torture on a thin-tyred road
bike).

This is literally just two lines of code in an osm2pgsql Lua tag transform
script, and thus available to anyone using the standard rendering toolchain.
If you don't want to do it this way, you can run a Postgres query
post-import, or just some extra conditions in your Mapnik/Carto .mml file.
It's really not hard.

Please, please, please don't fall into the trap of trying to optimise for
data consumers when you're not a data consumer. OSM has far too much of this
and it's resulted in a lot of nonsense tags over the years. Since you'd
never reach 100% coverage for paved=, the data consumer would need to
continue to parse the surface= tag. So the main effect would be to make life
_harder_ for data consumers, who would now have to check not just three
surface-type tags (surface=, tracktype=, smoothness=) but four. Or in other
words:

http://xkcd.com/927/

cheers
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/New-key-proposal-paved-yes-no-tp5817998p5818124.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Dave Swarthout]

On Sun, Sep 21, 2014 at 11:05 PM, Tod Fitch  wrote:

> On Sep 21, 2014, at 7:34 AM, Pee Wee wrote:
>
> >
> > Well if an unpaved  forest path would get gravel or fine_gravel thrown
> on top of it I would consider this some sort of paving that could be
> classified as "paved". You apparently don't. No need to argue about that ,
> it only goes to show that the suggested tag would not work. ;-)
> >
>
> In my part of the world, I can't imagine anyone in the general public
> considering a gravel surfaced path or road as being "paved".
>
>
> >
>
> In my mind, a good tagging scheme should have two main goals:
> 1. To be easy for a novice or entry level OpenStreetLevel mapper to do.
> 2. Be easy for data consumers to digest for wide spread uses.
>
> Looking at the first, in many cases we fail miserably at this. Where to go
> for definitive information (wiki, taginfo, mail lists, which of a couple
> help forums, etc.)? But we also fail when we try to get too sophisticated
> with our tagging. Despite being actively discouraged, "paved=yes/no" is
> used. And two of the top values for "surface=*" are "paved" and "unpaved",
> clearly taggers find the concept of "is paved" versus "is not paved" a
> natural one. And I strongly suspect you would get a more consistent result
> from an arbitrary person trying to "map what you see" if you asked them to
> look at a road and determine if it was paved or not than if you asked them
> to specify the name of the surface material. This is particularly true if
> their survey consists in driving from point A to point B and then asked (or
> trying to edit data in OSM) what the road surface was on each section road
> they used. They can probably tell you which sections were "unpaved" and
> which were "paved" but not tell you where the surface changed from concrete
> to asphalt, etc.
>
> On the second point, looking on printed maps of many vintages and at
> several routing engines, I see a distinction between "paved" and "unpaved".
> But not, with the exception of maps for a pretty specialized small group of
> people like highway engineers, between various paving types. So I think the
> biggest use of the "surface=*" tag is to determine "paved=yes/no". Giving a
> multivalued field to data consumers that need a boolean value requires a
> translation of some sort. We should not be "(mis)tagging for the (broken)
> renderer", but fundamentally we are "tagging for easy use by a software
> based data consumer" and in many years of software engineering I've noticed
> that every time you build a need for a translation in a process you build
> in a place for an error to creep in. So while "a renderer/router is
> perfectly capable of deciding" there can be inconsistencies in that
> translation between one data consumer and another leading people to suspect
> that something is flawed in data source.
>
> From both of the above, it seems that having "paved=yes/no" with
> "surface=*" would make it easier for both OSM mappers and OSM data
> consumers.
>

I agree with this assessment. As one can see from this discussion, the
various surfaces that one might tag mean different things to different
people, even to the extent that Pee Wee would consider a gravel covered
path as being paved. For me and most people in the U.S., gravel means
unpaved. Even if a road surface is hard and compacted, if the surface is
not some sort of _manufacured material_ (concrete, asphalt, paving_stone)
it is still "unpaved". In my mapping in Thailand, much of which is by
necessity done using aerial imagery (Bing), I use surface=paved and
surface=unpaved quite a bit. If I know the particular type of pavement,
I'll use that instead. Although I might argue against adding yet another
tag to the ones already defined is a bad idea, having the more generic
paved=yes/no tag along with surface=* to further clarify and expand on that
makes sense to me.

That said, I know that reaching consensus on this topic is going to be
exceedingly difficult. The discussion about the smoothness tag points up
the difficulties: There are bicyclists and roller-blade skaters,
wheelchairs and race cars, all trying to use the same map data to determine
a best route. That is why we have mappers already using tags that don't
_officially_ exist. In OSM you can invent your own tags, and maybe that's
the best way??? Make a tag, use it for a while, and have the discussion
after the fact 

Regards,

-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[David Bannon]

On Mon, 2014-09-22 at 00:23 +0200, Tomasz Kaźmierczak wrote:
..A good suggestion ...

So it seems that yet again, we are going to reject this attempt to solve
a real problem. Looking at the neg replies, because its not useful for
bike riders; not useful for a number of undefined edge cases; is a
duplicate of surface=.

Thats just plain not true ! There is no suggestion that paved= should be
used instead of surface=. I use surface= on all unsealed roads I map and
would continue to do so if I also used paved=no.

But there are 34 official values for surface= and 3581 values used. It
is very plain that the mapping community want surface= as a fine
grained, very detailed key. And thats great, people making specialised
maps or engines can use those values, display them in a meaningful way
to people they understand. My data will help them.

But the vast majority of people just want to know that the road may not
be what they are used to. Thats all. And paved= does that easily.

In places like Australia, that information can be a life or death thing.
People die here because they are inexperienced or ill equipped for roads
they tackle. Generally visitors from Europe or North America. 

Please folks, think of the big picture, not the edge cases.

David


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

On Sun, Sep 21, 2014 at 4:06 AM, Volker Schmidt  wrote:

> For bicycle routing the paved information is not very useful.


I strongly dispute this.  In the US, where practical bicycles are the
exception, not the rule, surface information is exceptionally important.
The overwhelming vast majority of bicycles are touring, MTB or BMX, with
city/cargo/cruiser bicycles being extremely extremely exceptional (and
often subject to unbearably expensive customs tax thanks to American laws
not differentiating bicycles on design purpose like it does motor vehicle
purpose, so a very heavy city bicycle from Holland with US-required
equipment permanently and inseperately installed ends up paying the same
import duty as a Chinese built 3-pound carbon fiber velodrome bicycle with
no brakes, where as a station wagon pays nearly no import tax and a
Maseratti pays about the same percentage as a bicycle).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

Along with this, I really hope renderers start computing surface=* and
toll=* values for ALL ways.  I say this since "surface=asphalt,
highway=cyclway" is an exceptionally rare combination in the midwestern US,
but "highway=cycleway, surface=gravel, toll=yes" is not.

On Sun, Sep 21, 2014 at 2:29 AM, Pee Wee  wrote:

> -1
>
> A renderer/router is perfectly capable of deciding what he thinks is
> paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or
> unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map
> what you see. As you may have guessed I prefer surface=asphalt over
> surface=paved since the last one could mean that it is gravel.
>
> Cheers
> PeeWee32
>
> 2014-09-21 2:49 GMT+02:00 David Bannon :
>
>>
>> yes, agree strongly. Surface= is a good tag, provides important info but
>> it is far too fine grained. Someone setting up a route cannot be
>> expected to sift through all the possible values.
>>
>> Similarly, we may well have a chance to get the renderers to respect a
>> clear, on/off tag like the proposed and show it on the maps too.
>>
>> I see no problem with both tags being used.
>>
>> I think sometimes we put too much detail in the database and risk making
>> the data unusable because of that. Mention making the data usable, we
>> see charges of "tagging for the renderer". But this is important, I have
>> detailed life threatening issues resulting from unclear maps. This
>> proposal will provide valuable, dare I say "usable" info for consumers !
>>
>> 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:
>> > 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
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> --
> Verbeter de wereld. Word mapper voor Openstreetmap
> .
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/l

Re: [Tagging] New key proposal - paved=yes/no

[moltonel 3x Combo]

On 21/09/2014, Tod Fitch  wrote:
> Despite being actively discouraged, "paved=yes/no" is
> used. And two of the top values for "surface=*" are "paved" and "unpaved",

A lot of those are historical values, before the practice of distinct
surface values took hold.

> clearly taggers find the concept of "is paved" versus "is not paved" a
> natural one. And I strongly suspect you would get a more consistent result
> from an arbitrary person trying to "map what you see" if you asked them to
> look at a road and determine if it was paved or not than if you asked them
> to specify the name of the surface material.

It would be nice if it was true, but it isn't. Consider
surface=compacted : while mappers do have a clear idea of what is
"paved" or not, that's the kind of surface thay'll yield
random/subjective paved=yes/no answers. Or consider
surface=cobblestones : while everybody would tag that paved=yes, a lot
of data users who look for "nicer" roads will want to avoid that
particular kind of paved=yes. They're just two examples amongs many
that show that a binary value is not as interesting as it sounds.

As a user, I'd avoid a router that only cares about paved=yes/no.
Looking at surface=* instead isn't hard. You can probaly afford to
just look at the ~30 most common values (ignoring typos and rare
items) and still get less issues than you'd get by looking at
paved=yes/no. As an added bonus, you can make your own selection of
what surface is "nice" for your usecase, and even use nuanced ratings.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Tom Pfeifer]

Tod Fitch wrote on 2014-09-21 18:05:

On the second point, looking on printed maps of many vintages and at several 
routing engines,

> I see a distinction between "paved" and "unpaved". But not, with the 
exception of maps for a
> pretty specialized small group of people like highway engineers, between 
various paving types.
> So I think the biggest use of the "surface=*" tag is to determine 
"paved=yes/no". Giving a
> multivalued field to data consumers that need a boolean value requires a 
translation of some sort.

As others already pointed out, the definition of 'paved' depends on the use. 
And OSM gives us the
chance, contrary to vintage printed maps, to customise maps to specialised 
users, even if that
group might be very small.

To cite the gravel road again, while the truck driver is happy that she does 
not sink in the mud,
and consider this as a kind of paving, the cyclist will avoid it if somehow 
possible.

Thus the detailed list of surface is fine, and the router can decide based on 
the user profile what
to use and to avoid, i.e. what this particular usage considers paving.

And the list is easy enough for a novice to understand, better than letting him 
make the
decision what paving means.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Tod Fitch]

On Sep 21, 2014, at 7:34 AM, Pee Wee wrote:

> 
> Well if an unpaved  forest path would get gravel or fine_gravel thrown on top 
> of it I would consider this some sort of paving that could be classified as 
> "paved". You apparently don't. No need to argue about that , it only goes to 
> show that the suggested tag would not work. ;-)
> 

In my part of the world, I can't imagine anyone in the general public 
considering a gravel surfaced path or road as being "paved".

On Sep 21, 2014, at 12:29 AM, Pee Wee wrote:

> -1
> 
> A renderer/router is perfectly capable of deciding what he thinks is 
> paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or 
> unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map what 
> you see. As you may have guessed I prefer surface=asphalt over surface=paved 
> since the last one could mean that it is gravel.
> 

In my mind, a good tagging scheme should have two main goals:
1. To be easy for a novice or entry level OpenStreetLevel mapper to do.
2. Be easy for data consumers to digest for wide spread uses.

Looking at the first, in many cases we fail miserably at this. Where to go for 
definitive information (wiki, taginfo, mail lists, which of a couple help 
forums, etc.)? But we also fail when we try to get too sophisticated with our 
tagging. Despite being actively discouraged, "paved=yes/no" is used. And two of 
the top values for "surface=*" are "paved" and "unpaved", clearly taggers find 
the concept of "is paved" versus "is not paved" a natural one. And I strongly 
suspect you would get a more consistent result from an arbitrary person trying 
to "map what you see" if you asked them to look at a road and determine if it 
was paved or not than if you asked them to specify the name of the surface 
material. This is particularly true if their survey consists in driving from 
point A to point B and then asked (or trying to edit data in OSM) what the road 
surface was on each section road they used. They can probably tell you which 
sections were "unpaved" and which were "paved" but not tell you where the 
surface changed from concrete to asphalt, etc.

On the second point, looking on printed maps of many vintages and at several 
routing engines, I see a distinction between "paved" and "unpaved". But not, 
with the exception of maps for a pretty specialized small group of people like 
highway engineers, between various paving types. So I think the biggest use of 
the "surface=*" tag is to determine "paved=yes/no". Giving a multivalued field 
to data consumers that need a boolean value requires a translation of some 
sort. We should not be "(mis)tagging for the (broken) renderer", but 
fundamentally we are "tagging for easy use by a software based data consumer" 
and in many years of software engineering I've noticed that every time you 
build a need for a translation in a process you build in a place for an error 
to creep in. So while "a renderer/router is perfectly capable of deciding" 
there can be inconsistencies in that translation between one data consumer and 
another leading people to suspect that something is flawed in data source.

From both of the above, it seems that having "paved=yes/no" with "surface=*" 
would make it easier for both OSM mappers and OSM data consumers.

Cheers
Tod

 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Pee Wee]

2014-09-21 15:37 GMT+02:00 Martin Koppenhoefer :

>
>
>
>
> > Il giorno 21/set/2014, alle ore 09:29, Pee Wee  ha
> scritto:
> >
> > As you may have guessed I prefer surface=asphalt over surface=paved
> since the last one could mean that it is gravel.
>
>
>
> while I also prefer asphalt over paved (more specific), I think it's
> difficult to find arguments for a gravel road to be considered "paved"


Well if an unpaved  forest path would get gravel or fine_gravel thrown on
top of it I would consider this some sort of paving that could be
classified as "paved". You apparently don't. No need to argue about that ,
it only goes to show that the suggested tag would not work. ;-)

Cheers
PeeWee32
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Martin Koppenhoefer]

> Il giorno 21/set/2014, alle ore 09:29, Pee Wee  ha 
> scritto:
> 
> As you may have guessed I prefer surface=asphalt over surface=paved since the 
> last one could mean that it is gravel.



while I also prefer asphalt over paved (more specific), I think it's difficult 
to find arguments for a gravel road to be considered "paved"

cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Volker Schmidt]

In addition there is a another problem, at least for bicycle routing,
independently of the way the paved yes/no information is tagged.
For bicycle routing the paved information is not very useful. What is
important is the smoothness information, either implicitly or explicitly.
That can be derived from the smoothness value or from the surface value.
That is the really important aspect for bicycle routing, not the paved
yes/no.

On 21 September 2014 09:29, Pee Wee  wrote:

> -1
>
> A renderer/router is perfectly capable of deciding what he thinks is
> paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or
> unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map
> what you see. As you may have guessed I prefer surface=asphalt over
> surface=paved since the last one could mean that it is gravel.
>
> Cheers
> PeeWee32
>
> 2014-09-21 2:49 GMT+02:00 David Bannon :
>
>>
>> yes, agree strongly. Surface= is a good tag, provides important info but
>> it is far too fine grained. Someone setting up a route cannot be
>> expected to sift through all the possible values.
>>
>> Similarly, we may well have a chance to get the renderers to respect a
>> clear, on/off tag like the proposed and show it on the maps too.
>>
>> I see no problem with both tags being used.
>>
>> I think sometimes we put too much detail in the database and risk making
>> the data unusable because of that. Mention making the data usable, we
>> see charges of "tagging for the renderer". But this is important, I have
>> detailed life threatening issues resulting from unclear maps. This
>> proposal will provide valuable, dare I say "usable" info for consumers !
>>
>> 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:
>> > 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
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> --
> Verbeter de wereld. Word mapper voor Openstreetmap
> 

Re: [Tagging] New key proposal - paved=yes/no

[Pee Wee]

-1

A renderer/router is perfectly capable of deciding what he thinks is
paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or
unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map
what you see. As you may have guessed I prefer surface=asphalt over
surface=paved since the last one could mean that it is gravel.

Cheers
PeeWee32

2014-09-21 2:49 GMT+02:00 David Bannon :

>
> yes, agree strongly. Surface= is a good tag, provides important info but
> it is far too fine grained. Someone setting up a route cannot be
> expected to sift through all the possible values.
>
> Similarly, we may well have a chance to get the renderers to respect a
> clear, on/off tag like the proposed and show it on the maps too.
>
> I see no problem with both tags being used.
>
> I think sometimes we put too much detail in the database and risk making
> the data unusable because of that. Mention making the data usable, we
> see charges of "tagging for the renderer". But this is important, I have
> detailed life threatening issues resulting from unclear maps. This
> proposal will provide valuable, dare I say "usable" info for consumers !
>
> 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:
> > 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
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Verbeter de wereld. Word mapper voor Openstreetmap
.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[David Bannon]

yes, agree strongly. Surface= is a good tag, provides important info but
it is far too fine grained. Someone setting up a route cannot be
expected to sift through all the possible values.

Similarly, we may well have a chance to get the renderers to respect a
clear, on/off tag like the proposed and show it on the maps too.

I see no problem with both tags being used.

I think sometimes we put too much detail in the database and risk making
the data unusable because of that. Mention making the data usable, we
see charges of "tagging for the renderer". But this is important, I have
detailed life threatening issues resulting from unclear maps. This
proposal will provide valuable, dare I say "usable" info for consumers !

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:
> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Tom Pfeifer]

-1, because:

Tomasz Kaźmierczak wrote on 2014-09-20 23:42:

I would like to suggest making the paved key for highways (and probably other 
types of elements) official.
Taginfo for paved:
http://taginfo.openstreetmap.org/keys/paved#values

The above shows that the key is already being used,


1648 times, compared to 9383813 of 'surface'.


but the Wiki doesn't describe this key, instead redirecting Key:paved
to the article about Key:surface.


to discourage the use of a duplicate key


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,


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?


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.


Not much simpler than checking for a member of a list.


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.


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. As we have surface=paved
we don't need paved=yes. And surface=asphalt implies paved.

Tod Fitch wrote on 2014-09-21 01:15:
> It might be considered duplicative, but what should a data consumer do if 
confronted
> with a surface=* value that is unknown to it (and the wiki)? We aren't 
talking human
> intelligence here where an informed guess is possible. Should such a way be 
considered
> paved or unpaved for purposes of routing? From that point of view, Richard's 
proposal gives a lot of clarity.

You would not want to add 9383813 unnecessary paved=yes/no just to cover
a few dozen undocumented values for surface, most of them probably typos.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

On Sat, Sep 20, 2014 at 6:15 PM, Tod Fitch  wrote:
>
> It might be considered duplicative, but what should a data consumer do if
> confronted with a surface=* value that is unknown to it (and the wiki)? We
> aren't talking human intelligence here where an informed guess is possible.
> Should such a way be considered paved or unpaved for purposes of routing?
> From that point of view, Richard's proposal gives a lot of clarity.
>

Same way as if the surface tag was missing.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Tod Fitch]

On Sep 20, 2014, at 4:00 PM, Paul Johnson wrote:

> 
> On Sat, Sep 20, 2014 at 4:59 PM, Richard Welty  wrote:
> 
> On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote:
>> I would like to suggest making the paved key for highways (and probably 
>> other types of elements) official. Taginfo for paved:
>> 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.
>> 
>> 
> 
> -1 
> 
> duplicative
> 
>  
> Seconded 

It might be considered duplicative, but what should a data consumer do if 
confronted with a surface=* value that is unknown to it (and the wiki)? We 
aren't talking human intelligence here where an informed guess is possible. 
Should such a way be considered paved or unpaved for purposes of routing? From 
that point of view, Richard's proposal gives a lot of clarity.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

On Sat, Sep 20, 2014 at 4:59 PM, Richard Welty 
wrote:

>
> On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote:
>
> I would like to suggest making the paved key for highways (and probably
> other types of elements) official. Taginfo for paved:
>
> 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.
>
>
> -1
>
> duplicative
>
>
Seconded
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Richard Welty]

On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote:
I would like to suggest making the paved key for highways (and 
probably other types of elements) official. Taginfo for paved:


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.





-1

duplicative

richard
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging