Re: [Tagging] (Soapy) Massage Parlour
2014-09-22 7:29 GMT+01:00 Stephan Knauss : > 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 : > 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 : > On Sun, Sep 21, 2014 at 4:06 AM, Volker Schmidt wrote: > >> For bicycle routing the paved information is not very useful. > > > I strongly dispute this. In the US, where practical bicycles are the > exception, not the rule, surface information is exceptionally important. Volker did not write that "surface" information did not matter, he said that "paved" doesn't hit it. For example a road paved with cobblestones (or even worse an antique roman road) are very hard to use in bicycle (mostly) and you'd generally want to avoid it, still it would be "paved". cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] 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 wrote: > > 2014-09-19 15:52 GMT+01:00 Tobias Knerr : > > 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 wrote: > > > -1 > > > > A renderer/router is perfectly capable of deciding what he thinks is > > paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or > > unpaved. Do not leave the decision paved/unpaved up to the mapper. Map > > what you see. As you may have guessed I prefer surface=asphalt over > > surface=paved since the last one could mean that it is gravel. > > > > Cheers > > PeeWee32 > > > > 2014-09-21 2:49 GMT+02:00 David Bannon : > > > >> > >> yes, agree strongly. Surface= is a good tag, provides important info but > >> it is far too fine grained. Someone setting up a route cannot be > >> expected to sift through all the possible values. > >> > >> Similarly, we may well have a chance to get the renderers to respect a > >> clear, on/off tag like the proposed and show it on the maps too. > >> > >> I see no problem with both tags being used. > >> > >> I think sometimes we put too much detail in the database and risk making > >> the data unusable because of that. Mention making the data usable, we > >> see charges of "tagging for the renderer". But this is important, I have > >> detailed life threatening issues resulting from unclear maps. This > >> proposal will provide valuable, dare I say "usable" info for consumers ! > >> > >> David > >> > >> On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote: > >> > Hello all, > >> > > >> > I've posted the below message on the forum, and have been directed > >> > from there to this mailing list, thus re-posting it. > >> > > >> > Idea > >> > > >> > I would like to suggest making the paved key for highways (and > >> > probably other types of elements) official. Taginfo for paved: > >> > http://taginfo.openstreetmap.org/keys/paved#values > >> > > >> > The above shows that the key is already being used, but the Wiki > >> > doesn't describe this key, instead redirecting Key:paved to the > >> > article about Key:surface. > >> > > >> > Rationale > >> > > >> > Currently, the surface key is being used as a way of saying that a > >> > given highway is paved or unpaved, but often the value for the surface > >> > key is not a generic paved or unpaved, but a specific surface type is > >> > given.This is of course very useful for describing the particular > >> > surface type a given highway has. However, in some cases, a simple > >> > information on just whether a highway is paved or not, would be very > >> > useful. One such case would be navigation software – if a user chooses > >> > to avoid unpaved roads, the software can check the value of the > >> > surface key, but in practice most (all?) of the navigation software > >> > only checks for a subset of all the possible values the surface key > >> > can have. This leads to incorrect (in terms of what the user expects) > >> > navigation when, for example, the surface is set to some value that > >> > describes an unpaved road, not recognized by the navigation software – > >> > if the software assumes that all highways are paved, unless explicitly > >> > stated otherwise (by recognized values of known keys), then, in > >> > consequence, it assumes that the road in question is paved. > >> > > >> > If the paved key was widely used, then the navigation software would > >> > have a simple and clear way of checking whether a given road is paved > >> > or not. The default value of the paved key for highways could be yes, > >> > so that it would be consistent with the assumption that highways in > >> > general are paved. > >> > > >> > I don't mean that we should stop using the paved and unpaved values > >> > for the surface key – I'm sure those generic values are useful in some > >> > cases. However, using the paved key would be also very useful. Also, > >> > the surface=paved could also implicate paved=yes and similarly > >> > surface=unpaved could implicate paved=no, so that duplication of the > >> > information could be avoided when the generic paved and unpaved values > >> > are set for the surface key. > >> > > >> > I believe that adding an article for the paved key to the Wiki would > >> > encourage people to use this tag, and navigation software makers to > >> > implement support for it in their applications. > >> > > >> > What do you think about that? > >> > > >> > > >> > > >> > Regards, > >> > > >> > Tomek > >> > > >> > ___ > >> > Tagging mailing list > >> > Tagging@openstreetmap.org > >> > https://lis
Re: [Tagging] 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, wrote: > Toll? I assume that means the same in US English as in UK English? > > You really have to pay to use cycleways? How is the toll collected and > enforced? > > Phil (trigpoint ) > > On Sun Sep 21 2014 23:36:04 GMT+0100 (BST), Paul Johnson wrote: > > Along with this, I really hope renderers start computing surface=* and > > toll=* values for ALL ways. I say this since "surface=asphalt, > > highway=cyclway" is an exceptionally rare combination in the midwestern > US, > > but "highway=cycleway, surface=gravel, toll=yes" is not. > > > > On Sun, Sep 21, 2014 at 2:29 AM, Pee Wee wrote: > > > > > -1 > > > > > > A renderer/router is perfectly capable of deciding what he thinks is > > > paved/unpaved. He can decide whether he calls gravel / fine_gravel > paved or > > > unpaved. Do not leave the decision paved/unpaved up to the mapper. Map > > > what you see. As you may have guessed I prefer surface=asphalt over > > > surface=paved since the last one could mean that it is gravel. > > > > > > Cheers > > > PeeWee32 > > > > > > 2014-09-21 2:49 GMT+02:00 David Bannon : > > > > > >> > > >> yes, agree strongly. Surface= is a good tag, provides important info > but > > >> it is far too fine grained. Someone setting up a route cannot be > > >> expected to sift through all the possible values. > > >> > > >> Similarly, we may well have a chance to get the renderers to respect a > > >> clear, on/off tag like the proposed and show it on the maps too. > > >> > > >> I see no problem with both tags being used. > > >> > > >> I think sometimes we put too much detail in the database and risk > making > > >> the data unusable because of that. Mention making the data usable, we > > >> see charges of "tagging for the renderer". But this is important, I > have > > >> detailed life threatening issues resulting from unclear maps. This > > >> proposal will provide valuable, dare I say "usable" info for > consumers ! > > >> > > >> David > > >> > > >> On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote: > > >> > Hello all, > > >> > > > >> > I've posted the below message on the forum, and have been directed > > >> > from there to this mailing list, thus re-posting it. > > >> > > > >> > Idea > > >> > > > >> > I would like to suggest making the paved key for highways (and > > >> > probably other types of elements) official. Taginfo for paved: > > >> > http://taginfo.openstreetmap.org/keys/paved#values > > >> > > > >> > The above shows that the key is already being used, but the Wiki > > >> > doesn't describe this key, instead redirecting Key:paved to the > > >> > article about Key:surface. > > >> > > > >> > Rationale > > >> > > > >> > Currently, the surface key is being used as a way of saying that a > > >> > given highway is paved or unpaved, but often the value for the > surface > > >> > key is not a generic paved or unpaved, but a specific surface type > is > > >> > given.This is of course very useful for describing the particular > > >> > surface type a given highway has. However, in some cases, a simple > > >> > information on just whether a highway is paved or not, would be very > > >> > useful. One such case would be navigation software – if a user > chooses > > >> > to avoid unpaved roads, the software can check the value of the > > >> > surface key, but in practice most (all?) of the navigation software > > >> > only checks for a subset of all the possible values the surface key > > >> > can have. This leads to incorrect (in terms of what the user > expects) > > >> > navigation when, for example, the surface is set to some value that > > >> > describes an unpaved road, not recognized by the navigation > software – > > >> > if the software assumes that all highways are paved, unless > explicitly > > >> > stated otherwise (by recognized values of known keys), then, in > > >> > consequence, it assumes that the road in question is paved. > > >> > > > >> > If the paved key was widely used, then the navigation software would > > >> > have a simple and clear way of checking whether a given road is > paved > > >> > or not. The default value of the paved key for highways could be > yes, > > >> > so that it would be consistent with the assumption that highways in > > >> > general are paved. > > >> > > > >> > I don't mean that we should stop us
Re: [Tagging] (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 : > > 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 : > 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ø wrote: > 2014-09-22 13:47 GMT+02:00 Mishari Muqbil : > 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 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 : > > 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 wrote: > > > -1 > > > > A renderer/router is perfectly capable of deciding what he thinks is > > paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or > > unpaved. Do not leave the decision paved/unpaved up to the mapper. Map > > what you see. As you may have guessed I prefer surface=asphalt over > > surface=paved since the last one could mean that it is gravel. > > > > Cheers > > PeeWee32 > > > > 2014-09-21 2:49 GMT+02:00 David Bannon : > > > >> > >> yes, agree strongly. Surface= is a good tag, provides important info but > >> it is far too fine grained. Someone setting up a route cannot be > >> expected to sift through all the possible values. > >> > >> Similarly, we may well have a chance to get the renderers to respect a > >> clear, on/off tag like the proposed and show it on the maps too. > >> > >> I see no problem with both tags being used. > >> > >> I think sometimes we put too much detail in the database and risk making > >> the data unusable because of that. Mention making the data usable, we > >> see charges of "tagging for the renderer". But this is important, I have > >> detailed life threatening issues resulting from unclear maps. This > >> proposal will provide valuable, dare I say "usable" info for consumers ! > >> > >> David > >> > >> On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote: > >> > Hello all, > >> > > >> > I've posted the below message on the forum, and have been directed > >> > from there to this mailing list, thus re-posting it. > >> > > >> > Idea > >> > > >> > I would like to suggest making the paved key for highways (and > >> > probably other types of elements) official. Taginfo for paved: > >> > http://taginfo.openstreetmap.org/keys/paved#values > >> > > >> > The above shows that the key is already being used, but the Wiki > >> > doesn't describe this key, instead redirecting Key:paved to the > >> > article about Key:surface. > >> > > >> > Rationale > >> > > >> > Currently, the surface key is being used as a way of saying that a > >> > given highway is paved or unpaved, but often the value for the surface > >> > key is not a generic paved or unpaved, but a specific surface type is > >> > given.This is of course very useful for describing the particular > >> > surface type a given highway has. However, in some cases, a simple > >> > information on just whether a highway is paved or not, would be very > >> > useful. One such case would be navigation software – if a user chooses > >> > to avoid unpaved roads, the software can check the value of the > >> > surface key, but in practice most (all?) of the navigation software > >> > only checks for a subset of all the possible values the surface key > >> > can have. This leads to incorrect (in terms of what the user expects) > >> > navigation when, for example, the surface is set to some value that > >> > describes an unpaved road, not recognized by the navigation software – > >> > if the software assumes that all highways are paved, unless explicitly > >> > stated otherwise (by recognized values of known keys), then, in > >> > consequence, it assumes that the road in question is paved. > >> > > >> > If the paved key was widely used, then the navigation software would > >> > have a simple and clear way of checking whether a given road is paved > >> > or not. The default value of the paved key for highways could be yes, > >> > so that it would be consistent with the assumption that highways in > >> > general are paved. > >> > > >> > I don't mean that we should stop using the paved and unpaved values > >> > for the surface key – I'm sure those generic values are useful in some > >> > cases. However, using the paved key would be also very useful. Also, > >> > the surface=paved could also implicate paved=yes and similarly > >> > surface=unpaved could implicate paved=no, so that duplication of the > >> > information could be avoided when the generic paved and unpaved values > >> > are set for the surface key. > >> > > >> > I believe that adding an article for the paved key to the Wiki would > >> > encourage people to use this tag, and navigation software makers to > >> > implement support for it in their applications. > >> > > >> > What do you think about that? > >> > > >> > > >> > > >> > Regards, > >> > >
Re: [Tagging] Feature Proposal - RFC - residential=gated
2014-09-21 17:53 GMT+02:00 Dan S : > 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 : > (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
