Re: [Tagging] New key proposal - paved=yes/no
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 erjo...@gmail.com 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 dban...@internode.on.net 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
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 erjo...@gmail.com 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
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 dban...@internode.on.net 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
On Wed, Sep 24, 2014 at 8:16 PM, Pee Wee piewi...@gmail.com 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
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
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
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 http://www.openfietsmap.nl/home/legenda(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
2014-09-24 18:40 GMT+02:00 Pee Wee piewi...@gmail.com: I would not call sand paved but when we look at e.g.gravel / fine_gravel the opinions will vary. The OSM based Openfietsmap http://www.openfietsmap.nl/home/legenda(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 http://www.merriam-webster.com/dictionary/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
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 dieterdre...@gmail.com: 2014-09-24 18:40 GMT+02:00 Pee Wee piewi...@gmail.com: I would not call sand paved but when we look at e.g.gravel / fine_gravel the opinions will vary. The OSM based Openfietsmap http://www.openfietsmap.nl/home/legenda(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 http://www.merriam-webster.com/dictionary/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 http://www.openstreetmap.org. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
On Mon, Sep 22, 2014 at 3:54 AM, p...@trigpoint.me.uk 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
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 j...@jfeldredge.com 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 piewi...@gmail.com 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 dban...@internode.on.net: 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
Re: [Tagging] New key proposal - paved=yes/no
2014-09-23 1:12 GMT+02:00 David Bannon dban...@internode.on.net: 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 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
On 24/09/2014 1:27 AM, tagging-requ...@openstreetmap.org wrote: Date: Tue, 23 Sep 2014 15:43:07 +0200 From: Martin Koppenhoefer dieterdre...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] New key proposal - paved=yes/no Message-ID: cabptjtd7kbdbxzs9p8kz-anrnb-d9g91d3hk1tfmsnk+dmh...@mail.gmail.com Content-Type: text/plain; charset=utf-8 2014-09-23 1:12 GMT+02:00 David Bannon dban...@internode.on.net: 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 rich...@systemed.net 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
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
2014-09-22 0:36 GMT+02:00 Paul Johnson ba...@ursamundi.org: 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
2014-09-22 0:42 GMT+02:00 Paul Johnson ba...@ursamundi.org: On Sun, Sep 21, 2014 at 4:06 AM, Volker Schmidt vosc...@gmail.com 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
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 piewi...@gmail.com 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 dban...@internode.on.net: 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 http://www.openstreetmap.org.
Re: [Tagging] New key proposal - paved=yes/no
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, 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 piewi...@gmail.com 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 dban...@internode.on.net: 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
Re: [Tagging] New key proposal - paved=yes/no
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 piewi...@gmail.com 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 dban...@internode.on.net: 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
Re: [Tagging] New key proposal - paved=yes/no
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
-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 dban...@internode.on.net: 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 http://www.openstreetmap.org. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
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 piewi...@gmail.com 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 dban...@internode.on.net: 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 http://www.openstreetmap.org. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging
Re: [Tagging] New key proposal - paved=yes/no
Il giorno 21/set/2014, alle ore 09:29, Pee Wee piewi...@gmail.com 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
2014-09-21 15:37 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: Il giorno 21/set/2014, alle ore 09:29, Pee Wee piewi...@gmail.com 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
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
On 21/09/2014, Tod Fitch t...@fitchdesign.com 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
[Tagging] New key proposal - paved=yes/no
W dniu 21 września 2014 02:10 użytkownik Tom Pfeifer napisał: 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? Didn’t want to name particular software, but if you ask, then OsmAnd 1.8.3 thinks that highway=tertiary + surface=dirt is a paved way, and setting “avoid unpaved roads” in its configuration doesn’t prevent it from routing through such a road (car navigation mode). Please look at this issue: https://code.google.com/p/osmand/issues/detail?id=1956 As you can see, they have “fixed” the issue more than a year ago, in version 1.4.1. Then I forgot about this and didn’t check whether it really worked. Yes, I should have probably reopened the issue and tell them that they didn’t really understand what it was all about. But on the other hand, I believe I was clear enough in my description. I stated clearly that the problem is that they do not support _various different_ values of the surface key, yet they only went for adding support for _one most general_ value. I had pointed them to that very long list of possible values for “unpaved” surfaces, yet they have decided to add support for only one of them. So, again: 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. True. OsmAnd, as a popular navigation software, does so Untrue, unfortunately. And answering this particular question of yours: [...] and why such incompleteness cannot be fixed within the router/renderer? Don’t as me. They apparently have chosen not to. Moving on: 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. Yes, I forgot that the highway tag is used also for these. So this would be a bad idea indeed to assume that highways are paved by default. 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. I wouldn’t agree that I’m arguing against my proposal here. I’m supplementing it. As we have surface=paved we don't need paved=yes. Yes, that’s what I meant – if a highway has surface=paved, then it doesn’t need paved=yes. And surface=asphalt implies paved. And what about surface=dirt? Doesn’t seem to mean surface=unpaved for everybody. Besides all the above, and besides all the answers all of you have written, another thing has just came to my mind – don't you think that using the “surface” key for saying _either_ that a highway is paved/unpaved _or_ what particular surface the highway has, is a bit inconsistent? What I mean: don’t you think that a property called “surface” should describe what highway is made of/consists of (asphalt, paving stones, grass, mud, dirt, ice, etc.) and not how it has been made (it has been _paved_ or has been left _unpaved_)? In my opinion these are fundamentally two different properties (although one of them is a derivative of the other). Regards, Tomek ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
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 piewi...@gmail.com 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 dban...@internode.on.net: 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 http://www.openstreetmap.org. ___ 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
On Sun, Sep 21, 2014 at 4:06 AM, Volker Schmidt vosc...@gmail.com 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
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
On Sun, Sep 21, 2014 at 11:05 PM, Tod Fitch t...@fitchdesign.com 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 g 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
[Tagging] New key proposal - paved=yes/no
Hello all, I've posted the below message on the forum[1], 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[2] 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 *highway*s 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 *highway*s could be /yes/, so that it would be consistent with the assumption that *highway*s 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 [1] http://forum.openstreetmap.org/viewtopic.php?pid=451593 [2] http://taginfo.openstreetmap.org/keys/paved#values ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
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
Re: [Tagging] New key proposal - paved=yes/no
On Sat, Sep 20, 2014 at 4:59 PM, Richard Welty rwe...@averillpark.net 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
On Sep 20, 2014, at 4:00 PM, Paul Johnson wrote: On Sat, Sep 20, 2014 at 4:59 PM, Richard Welty rwe...@averillpark.net 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
On Sat, Sep 20, 2014 at 6:15 PM, Tod Fitch t...@fitchdesign.com 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
-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
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
