Re: [Tagging] (Soapy) Massage Parlour
On 21.09.2014 11:04, Dan S wrote: It looks like there's this tag, including a tag suggested for your specific issue: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage please don't use shop=massage for this kind of places. I really don't want them to show up on a map next to Wat Pho massage just because the map creator does not take into account some additional tagging which says yes, it's tagged as a massage, but this tag tells you it isn't. Additional tags can specify something further, but should not change the meaning in general. Think of amenity=place_of_worship. They are all sort of religious place. If your map cares, it can distinguish between Buddhist, Christian or Muslim. But still it's a place of worship. Stephan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Soapy) Massage Parlour
2014-09-22 7:29 GMT+01:00 Stephan Knauss o...@stephans-server.de: On 21.09.2014 11:04, Dan S wrote: It looks like there's this tag, including a tag suggested for your specific issue: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage please don't use shop=massage for this kind of places. I really don't want them to show up on a map next to Wat Pho massage just because the map creator does not take into account some additional tagging which says yes, it's tagged as a massage, but this tag tells you it isn't. Additional tags can specify something further, but should not change the meaning in general. The original message said this kind of place offers bathing + massage services plus the sexual stuff. My advice was based on that description. You seem to be saying that these places _don't_ offer massage services. I don't actually know which of these is true! Dan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
No tags on the shared nodes - just shared nodes. What is IMHO a quite bad idea for two reasons: – It’s unlikely that there will be software supporting features when there is no tag. – You would introduce a concurrent solution to a node highway=traffic_signals. I do not think that it’s a good idea to have various ways to tag the same thing. Made a test to show you what I was thinking. https://www.openstreetmap.org/#map=18/36.32478/139.10396 And there, you see even more problems: – At https://www.openstreetmap.org/#map=19/36.32487/139.10370, you do not have a shared node between the highway and the area. But this would be necessary to have a reliably hint for routing/turn-to-turn navigation software, otherwise it will be hard to know there the area ends. This would make a working routing solution quite unlikely. – At https://www.openstreetmap.org/#map=19/36.32492/139.10357 you have the area nearly in parallel to the footway. There will be other situations, where it will be exactly parallel. This is not comfortable to edit. – At https://www.openstreetmap.org/#map=19/36.32492/139.10347 you do not have a shared node between the footway and the area. But footways are not oneway. So a routing engine does not know when you enter the area respectively when you leave it. – At https://www.openstreetmap.org/#map=19/36.32440/139.10395 the footway overlaps only slightly the area. There will be cases where it will not overlap at all. How to decide reliably for software if this footway passes through the junction or not? – At https://www.openstreetmap.org/#map=19/36.32440/139.10395 you have a shared node. But probably, when you are passing through the footway and go from south to est, you do not pass over the traffic signals. (You would to so only when you go from south to northwest, and the traffic signal node should be at the intersection between the footway and the highway: https://www.openstreetmap.org/#map=19/36.32445/139.10392 ) – The complicate roule when to share node and when not will in practice be prone to errors. It’s to difficult. – And: I still not see what you gain with this. – And overall: It would mean that you may not add any of these areas to OSM unless you know _exactly_ where the individual traffic signals are located. So, in practice, either the tagging will hardly be used, or (what I think is more likely) people will tag nevertheless the area, and just not comply with the rule of the shared nodes. – All in all, I do neither see this practicable nor do I see a gain. ___ 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] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
Dormitories are rooms with multiple beds, usually bunk beds and associated with youth hostels, certainly not suitable for student accommodation where there is typically one student in a room, maybe two but they are certainly not dormitories. Phil (trigpoint ) On Sat Sep 20 2014 23:12:24 GMT+0100 (BST), Eugene Alvin Villar wrote: On 9/20/14, Dan S danstowell+...@gmail.com wrote: 2014-09-19 15:52 GMT+01:00 Tobias Knerr o...@tobias-knerr.de: I still prefer (d) though if building=dormitory becomes widely accepted then I guess I shall have to swallow that loss for British english! Wouldn't be the first time if ever: http://wiki.openstreetmap.org/wiki/Tag:sport%3Dsoccer That said, to me dormitories may also apply to other institutionalized housing such as housing for staff of a manufacturing plant. Although I admit that dormitories are primarily for students in my understanding. This ambiguity can be resolved by careful definition in the Wiki if ever people accept *=dormitory. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Sent from my Jolla ___ 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] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Wow, you really went over it very carefully, thanks for all the input. I will
go over your list of issues again, but can you fix it to as how you would see
this tag used? I'm very interested to see how you would properly tag it, as you
know the parsing methods much better than I do ('cause I have an idea of how
they work, but no exact knowledge, so I'm dangerous).
I only have one question so far-
– At https://www.openstreetmap.org/#map=19/36.32440/139.10395 you have a
shared node. But probably, when you are passing through the footway and go
from south to est, you do not pass over the traffic signals. (You would to so
only when you go from south to northwest, and the traffic signal node should
be at the intersection between the footway and the highway:
https://www.openstreetmap.org/#map=19/36.32445/139.10392 )
You may not pass through the signal, but it is still the (sometimes named)
signal that you would turn right at, correct?
-Javbw
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
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] (Soapy) Massage Parlour
Hi Dan, I realise that it's my fault for not being very clear from the beginning. I think as John mentions, amenity=soapland is about right. I do suspect that the establishments in Thailand are based on the same concept as those which exist in Japan. Should I create an entry in the wiki for this? On 9/22/14 14:05, Dan S wrote: 2014-09-22 7:29 GMT+01:00 Stephan Knauss o...@stephans-server.de: On 21.09.2014 11:04, Dan S wrote: It looks like there's this tag, including a tag suggested for your specific issue: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage please don't use shop=massage for this kind of places. I really don't want them to show up on a map next to Wat Pho massage just because the map creator does not take into account some additional tagging which says yes, it's tagged as a massage, but this tag tells you it isn't. Additional tags can specify something further, but should not change the meaning in general. The original message said this kind of place offers bathing + massage services plus the sexual stuff. My advice was based on that description. You seem to be saying that these places _don't_ offer massage services. I don't actually know which of these is true! Dan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Best regards Mishari Muqbil EE32 64BD 7D1F 5946 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Soapy) Massage Parlour
2014-09-22 13:47 GMT+02:00 Mishari Muqbil mish...@mishari.net: I realise that it's my fault for not being very clear from the beginning. I think as John mentions, amenity=soapland is about right. I do suspect that the establishments in Thailand are based on the same concept as those which exist in Japan. That being the case I'd say they really do qualify as amenity=brothel. It doesn't really matter that they're not officially brothels, or don't label themselves as such, that doesn't change the fact. Nor should you be liable in any way for mapping facts. However, amenity=soapland would be more precise and give more information, and there's also a decent Wikipedia page about it. I'd say it's really a sub group/type of amenity=brothel though. -- Guttorm ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Soapy) Massage Parlour
Yea, it's a brothel - but it is avery particular style of brothel in Asia to get around the laws , and AFAIK has very different customs than what I imagine a more european or australian brothel is. because of the type of service that is expected, I don't believe it meshes well with what someone going to the red light district in Amsterdam would be expecting from a brothel. Amenity is jam packed with stuff, so amenity=soapland seems reasonable, but is there an adult=* key? or a brothel=* subtag? Javbw On Sep 22, 2014, at 9:49 PM, Guttorm Flatabø p...@guttormflatabo.com wrote: 2014-09-22 13:47 GMT+02:00 Mishari Muqbil mish...@mishari.net: I realise that it's my fault for not being very clear from the beginning. I think as John mentions, amenity=soapland is about right. I do suspect that the establishments in Thailand are based on the same concept as those which exist in Japan. That being the case I'd say they really do qualify as amenity=brothel. It doesn't really matter that they're not officially brothels, or don't label themselves as such, that doesn't change the fact. Nor should you be liable in any way for mapping facts. However, amenity=soapland would be more precise and give more information, and there's also a decent Wikipedia page about it. I'd say it's really a sub group/type of amenity=brothel though. -- Guttorm ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Understanding links
I have a question on highway link roads. I came across some trunk_links that seemed really out of place today, but they were recently added by a tagger that usually knows what they are doing. https://www.openstreetmap.org/#map=19/36.30046/139.19574 The frontage road for local access to the buildings along the road is marked as trunk link. As I understand it, the local access roads would be an unclassified road with bollards or a kind of barrier at each end, and with trunk links, (or one way unclassified roads?) that lead onto the actual new trunk road. This seems like an incorrect use of trunk_links for the frontage road along the buildings and maybe for the little entrance exit driveways that connect it to the trunk roads. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Soapy) Massage Parlour
On 22 September 2014 13:57, johnw jo...@mac.com wrote: Yea, it's a brothel - but it is avery particular style of brothel in Asia to get around the laws , and AFAIK has very different customs than what I imagine a more european or australian brothel is. because of the type of service that is expected, I don't believe it meshes well with what someone going to the red light district in Amsterdam would be expecting from a brothel. I don't think brothels masking as massage parlours are a typical Asian thing. I did some Googling, and I found: http://www.massagewereld.com/en A chain of 'massage parlours' in the Netherlands, Belgium and Germany http://www.paradisestudio.co.uk/ An English 'massage parlour' http://www.happyending.es/ 'Massages' in Spain The internet suggests the same concept exists in Norway, where prostitution is illegal. So it seems this kind of thing is quite widespread. I would prefer a tagging scheme that works worldwide, and I don't think the term 'soapland' would be understood in Europe. In fact, I have the same problem with tagging Gentlemen's Clubs in England. How do other mappers tag these? From the outside, it's often hard to decide whether they should be tagged as leisure=social_club (typically not...), amenity=stripclub, or amenity=brothel. In England, brothelkeeping is illegal, so tagging them as amenity=brothel without evidence might again be risky from a legal perspective. -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Simple Indoor Tagging
2014-09-22 1:43 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: wouldn't there typically be direct entrances and no corridors? I think if you are at this level of detail we could expect that you add the poi as a polygon, rather than adding nonexistent corridors ;-) I guess you're right. Corridor looks wrong to me too, but indoor=door, indoor=room or indoor=you_are_already_here looked even worse. I guess drawing a little approximate rectangle isn't that bad. Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
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] Feature Proposal - RFC - residential=gated
2014-09-21 17:53 GMT+02:00 Dan S danstowell+...@gmail.com: Motivated by the discussion around residential=* sub-tagging, I thought it would be useful to get a bit more clarity, by taking some existing sub-tagging and putting it through RFC. Here is a proposal for residential=gated: IMHO a gated community is much more than a residential landuse, very often you will have other landuses there as well (just like any other village). I would see this orthogonal to landuse and use a settlement object (something with a tag place with values like ''hamlet'', ''village or if part of another settlement ''neighbourhood'' or ''suburb'') as an area and add an attribute for the restricted access (if you don't like access=private this could also be a new tag). Typically I'd expect a fenced (or walled or both) area (fence as linear feature, together they are closed) and then a multipolygon relation with these barrier-ways as outer members. This multipolygon relation would get the tags to describe the area / gated community. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Student accommodation building
2014-09-21 19:57 GMT+02:00 Dan S danstowell+...@gmail.com: (Note: this is about tagging a building type; it's separate from Hno's amenity=student_accommodation proposal which aims to tag the usage.) I think the proposal is OK (even if it lists 5 different tagging options which is maybe not the best way to come to uniform tagging ;-) ), and I particularly like the fact that you emphasize that this is not about student accomodation but about buildings built as student accomodation. The typical end user will mostly be more interested in actual student accomodations and not in the building typology (my guess), so encouraging tagging the service (as well) seems vital. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Understanding links
Am 22.09.2014 15:06, schrieb johnw: I have a question on highway link roads. I came across some trunk_links that seemed really out of place today, but they were recently added by a tagger that usually knows what they are doing. https://www.openstreetmap.org/#map=19/36.30046/139.19574 The frontage road for local access to the buildings along the road is marked as trunk link. As I understand it, the local access roads would be an unclassified road with bollards or a kind of barrier at each end, and with trunk links, (or one way unclassified roads?) that lead onto the actual new trunk road. This seems like an incorrect use of trunk_links for the frontage road along the buildings and maybe for the little entrance exit driveways that connect it to the trunk roads. +1 I would tag the small links between the parallel highways with trunk_link and the outside highways look like residential/unclassified or even service. Looks like a tagging mistake, did you get into contact with the user ? cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
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
