Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
So the nodes where the signals_area intersects the highways is where the signals would normally be mapped for complex intersections? Not exactly. It would be difficult to do so if you have really complex junctions with really many individual traffic signals and you want to catch all of them – a zickzack that is not easy to draw and not practical to maintain. The area is drawn just _around_ everything that is considered the junction. About the individual traffic signals. We recommand as current best-practice to not map them if you use the area. Means: Don’t do both things. (But maybe in the future this could be considered useful and it could be done without breaking the tagging scheme just like every other normal traffic signal with highway=traffic_signals on a node.) ___ 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] (Soapy) Massage Parlour
Hi - It looks like there's this tag, including a tag suggested for your specific issue: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage Best Dan 2014-09-21 4:23 GMT+01:00 Mishari Muqbil mish...@mishari.net: Hi, Thailand has these places called entertainment complexes[1] that offers bathing + massage services and quite often the expectation is that there will be sexual services offered. However, I don't want to tag them as brothels as prostitution on the premises is legally not allowed[2]. I propose to tag this as leisure=massage_parlour since that's what the Thai English dictionary calls them[3] but I don't want it to be mistaken for more family friendly establishments in other parts of the world. Colloquially these places are called soapy massage so perhaps leisure=soapy_massage? :) One reason why they should be mapped is just how prominent they are as landmarks in general. For example, here's one called Utopia http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw Any thoughts? [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat [2] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act [3] http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94 -- Best regards Mishari Muqbil EE32 64BD 7D1F 5946 ___ 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
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] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
2014-09-21 0:49 GMT+01:00 Eugene Alvin Villar sea...@gmail.com: On Sun, Sep 21, 2014 at 7:09 AM, p...@trigpoint.me.uk wrote: 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. What you're saying is British English usage. Here in the Philippines, dormitories are understood to be buildings primarily for students. Thanks. So we've re-confirmed that the word dormitory has some ambiguities that might be problematic, especially considering that OSM is based on British English. Eugene points out sport=soccer which is a good example of OSM deliberately avoiding ambiguities, since in that case the common term football has one meaning in US and one in UK. In that case we avoided the British term as a special case, to avoid the ambiguity. Here dormitory is the ambiguous term. But that's all fine, since remember that Hno's tag proposal has already been altered to amenity=student_accommodation. https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dstudent_accommodation I agree with fly that it'd be nice to have a tag which didn't fix the profession (so that it could be used for nurses/lecturers/etc) but maybe that's not so bad. Cheers Dan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
2014-09-19 16:15 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-09-19 14:22 GMT+02:00 Dan S danstowell+...@gmail.com: for buildings: building=residential + residential=university + operator=* OR for sites: landuse=residential + residential=university + operator=* Note that the same scheme seems to me to work well for building and for landuse. I am not sure if this works. Have you been looking at current values for the residential key? These are the ones with more than 100 uses: rural http://taginfo.openstreetmap.org/tags/residential=rural 78 141 - urban http://taginfo.openstreetmap.org/tags/residential=urban 12 698 - garden http://taginfo.openstreetmap.org/tags/residential=garden 3 805 - gated http://taginfo.openstreetmap.org/tags/residential=gated 884 - apartments http://taginfo.openstreetmap.org/tags/residential=apartments 231 - single_family http://taginfo.openstreetmap.org/tags/residential=single_family 197 - detached http://taginfo.openstreetmap.org/tags/residential=detached 133 Thanks Martin. Yes I did look at these. NONE of them have a wiki page, nor does the residential=* tag in general, so I'm at a loss to work out what is intended by them! * Surely the rural/urban distinction is judged by location? Could you have residential=rural in the town centre? Maybe (since the tag isn't documented) but I would guess not. So what's the tag for? Does it designate context, building style, building density...? * Surely apartments/detached/single_family should be properties of the building objects? * residential=garden I quite like, but it seems to duplicate leisure=garden and it seems strange to me to consider gardens as residential since usually no-one lives in the garden. I wonder if it was ever discussed much. * residential=gated I like. In theory you can use barrier=* and access=* to indicate the unusual access constraints for gated residences, but actually it's not always obvious as that, since non-gated communities might also have fences etc. So this tag seems to me like it might make a useful distinction. There are already at least 3 different systems (one for rural / urban and one for the building typology (detached / single_family / apartments) and one for gated communities (what's this, socio-economic aspect of urbanism maybe?). Now you seem to be adding yet another one, university for student's appartments (not really self explaining IMHO). So if not self-explaining, what misunderstandings of residential=university could happen? It seems quite self-explaining to me, so I'd be grateful if you could offer your perspective of potential misunderstandings of residential=university. I would use a specific tag for the building typology (e.g. building=dormitory or student_accomodation or similar if the building was built as such) and another one if it is actually used as such (e.g. under the amenity key as suggested by Tobias). Understood. For the building, at least, the subtag works, if used to indicate building typology. I don't see this as a case for adding a specific landuse value, but I do agree that refining the generic residential into more differentiated values by subtagging might be a general option (regardless of this particular case of student accomodation), e.g. differentiate according to density and structure (open / closed, not sure about the precise term in English, for reference see these two pictures: open (=space between buildings) http://de.wikipedia.org/wiki/Offene_Bauweise_%28Baurecht%29#mediaviewer/File:Offene_Bauweise.png closed (buildings without space between them): http://de.wikipedia.org/wiki/Geschlossene_Bauweise_%28Baurecht%29#mediaviewer/File:Geschlossene_Bauweise.png In British English this seems to me to detached vs semi-detached vs terrace (though there's not a 1:1 concept match). Again, though, it's not clear to me why you'd want to tag residential areas as having these properties, since they're already commonly indicated via the tags/geometry of the building objects. Thanks again for your detailed reply. Best Dan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Soapy) Massage Parlour
@Dan S — Good answer. I was wondering how to tag such places myself. On Sun, Sep 21, 2014 at 4:04 PM, Dan S danstowell+...@gmail.com wrote: Hi - It looks like there's this tag, including a tag suggested for your specific issue: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage Best Dan 2014-09-21 4:23 GMT+01:00 Mishari Muqbil mish...@mishari.net: Hi, Thailand has these places called entertainment complexes[1] that offers bathing + massage services and quite often the expectation is that there will be sexual services offered. However, I don't want to tag them as brothels as prostitution on the premises is legally not allowed[2]. I propose to tag this as leisure=massage_parlour since that's what the Thai English dictionary calls them[3] but I don't want it to be mistaken for more family friendly establishments in other parts of the world. Colloquially these places are called soapy massage so perhaps leisure=soapy_massage? :) One reason why they should be mapped is just how prominent they are as landmarks in general. For example, here's one called Utopia http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw Any thoughts? [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat [2] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act [3] http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94 -- Best regards Mishari Muqbil EE32 64BD 7D1F 5946 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
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] (Soapy) Massage Parlour
Hi, I saw that, but I'm not convinced it's the right approach as what I'm referring require a specific massage parlor license to operate as opposed to a regular traditional massage establishment which is more suited for shop=massage. I think it would be akin to saying a convenience store and supermarket can all be tagged the same way. Also, I'm not comfortable with using sexual as it could be libelous to state that something illegal is taking place in these establishments (for example, you won't do shop=convenience+marijuana=yes in most parts of the world). How about something like a combination of: amenity=massage_parlour male=yes female=no min_age=21 This should be quite accurate. On 21/9/14 16:04, Dan S wrote: Hi - It looks like there's this tag, including a tag suggested for your specific issue: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage Best Dan 2014-09-21 4:23 GMT+01:00 Mishari Muqbil mish...@mishari.net: Hi, Thailand has these places called entertainment complexes[1] that offers bathing + massage services and quite often the expectation is that there will be sexual services offered. However, I don't want to tag them as brothels as prostitution on the premises is legally not allowed[2]. I propose to tag this as leisure=massage_parlour since that's what the Thai English dictionary calls them[3] but I don't want it to be mistaken for more family friendly establishments in other parts of the world. Colloquially these places are called soapy massage so perhaps leisure=soapy_massage? :) One reason why they should be mapped is just how prominent they are as landmarks in general. For example, here's one called Utopia http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw Any thoughts? [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat [2] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act [3] http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94 -- Best regards Mishari Muqbil EE32 64BD 7D1F 5946 ___ 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 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] (Soapy) Massage Parlour
Hi, Well, that suggestion specifies access limits (i.e. only males age 21 or more), and if those are true facts and they're what you want to indicate, then go ahead. The access limits don't really tell you if something is soapy or not, but if you decide you only want to imply that and not to state it explicitly, your approach sounds OK to me. However, there's NO reason to use amenity=massage_parlour when shop=massage already exists. Please use it. You said you want to avoid confusion between soapy and family-friendly, and your age-restriction works for that, no need to create a duplicate tag. Best Dan 2014-09-21 14:52 GMT+01:00 Mishari Muqbil mish...@mishari.net: Hi, I saw that, but I'm not convinced it's the right approach as what I'm referring require a specific massage parlor license to operate as opposed to a regular traditional massage establishment which is more suited for shop=massage. I think it would be akin to saying a convenience store and supermarket can all be tagged the same way. Also, I'm not comfortable with using sexual as it could be libelous to state that something illegal is taking place in these establishments (for example, you won't do shop=convenience+marijuana=yes in most parts of the world). How about something like a combination of: amenity=massage_parlour male=yes female=no min_age=21 This should be quite accurate. On 21/9/14 16:04, Dan S wrote: Hi - It looks like there's this tag, including a tag suggested for your specific issue: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage Best Dan 2014-09-21 4:23 GMT+01:00 Mishari Muqbil mish...@mishari.net: Hi, Thailand has these places called entertainment complexes[1] that offers bathing + massage services and quite often the expectation is that there will be sexual services offered. However, I don't want to tag them as brothels as prostitution on the premises is legally not allowed[2]. I propose to tag this as leisure=massage_parlour since that's what the Thai English dictionary calls them[3] but I don't want it to be mistaken for more family friendly establishments in other parts of the world. Colloquially these places are called soapy massage so perhaps leisure=soapy_massage? :) One reason why they should be mapped is just how prominent they are as landmarks in general. For example, here's one called Utopia http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw Any thoughts? [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat [2] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act [3] http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94 -- Best regards Mishari Muqbil EE32 64BD 7D1F 5946 ___ 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 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] Feature Proposal - RFC - cycleway=soft_lane
First of all: Thanks for all the comments on the proposal, so far. I have incorporated a lot of ideas into the proposal and I have restructured the page it a little, since there were many of comments/addition concerning cycle way infrastructure and tagging semantics in generals, which were really helpful but are not essential to the proposal. With this mail, I would like to ask for a another round of comments to see, if this proposal is ready for a vote. Best Regards Hubert From: Hubert [mailto:sg.fo...@gmx.de] Sent: Freitag, 12. September 2014 12:21 To: tagging@openstreetmap.org Subject: [Tagging] Feature Proposal - RFC - cycleway=soft_lane Hallo together. I would like to ask for any comments and opinions to this proposal https://wiki.openstreetmap.org/wiki/Soft_lane. Thank you for your time and Best Regards Hubert ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - residential=gated
Hi all, 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: http://wiki.openstreetmap.org/wiki/Proposed_features/residential%3Dgated I chose this tag because it's already used quite a bit, its meaning seems clear to me, and it seems potentially useful, though I can't predict if the community more generally will consider it useful. Please comment on the wiki talk page. Thanks Dan ___ 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] Feature Proposal - RFC - cycleway=soft_lane
A comment on your rendering proposals: In your proposal you write: Rendered as: a dashed line in blue off to one or both sides of a road (for example) : and cycleway https://wiki.openstreetmap.org/wiki/Key:cycleway=soft_lane https://wiki.openstreetmap.org/w/index.php?title=Tag:cycleway%3Dsoft_laneaction=editredlink=1 could be rendered as a solid, dashed, or dotted line in (for example) blue off to one or both sides to the road, similar to the way it is done by opencyclemap http://www.opencyclemap.org. The dashed blue line / solid blue line are used by OCM to render a parallel cycleway / an on-road cycle lane. So these two renderings are already taken in OCM and should be recommended for the new soft-lane tag. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] RFC: Student accommodation building
Hi all, Following the tagging conversation about student accommodation buildings, I created a proposal wiki page, to document the different tagging perspectives, and maybe one day work towards half a consensus ;) https://wiki.openstreetmap.org/wiki/Proposed_features/Student_accommodation_building (Note: this is about tagging a building type; it's separate from Hno's amenity=student_accommodation proposal which aims to tag the usage.) Best Dan ___ 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
Re: [Tagging] Simple Indoor Tagging
I've been thinking recently about simplified indoor tagging. I've made the next picture: http://i.imgur.com/V09c2KG.png We have two shops and three entrances, and it would be nice to know which entrances lead to which shops. Full indoor tagging would mean that we should draw rooms for both shops, but what if an average mapper doesn't want to draw all rooms for all shops? Would it be OK to tag the red lines as indoor=corridor? I'll be looking at this proposal a bit more, but for now it looks great. Janko 2014-09-21 3:57 GMT+02:00 Matthijs Melissen i...@matthijsmelissen.nl: On 20 September 2014 11:11, Peter Barth osm-tagg...@won2.de wrote: starting after the SOTM-EU we've worked hard on a new proposal for indoor tagging: Simple Indoor Tagging. The Proposal can be found here: https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging Thanks for your efforts. Two points: - Should the level tags be subsequent numerical values, or the level names signposted in the building (for instance in the lifts)? In England, levels are often named basement/lower ground/upper ground floor. In Germany, I have seen buildings that distinguish floor 0 and floor -0. If a building starts with for instance Ground, Mezzanine, Floor 1, Floor 2, then it might be confusing to use levels 0, 1, 2, 3 for that, as then each level key would be off by one with the signed level. Why not use level for signposted levels and layer for a numerical order? - What is the reason for using indoor=corridor rather than highway=footway and stairs=* rather than highway=steps? Can a way have both tags? Sometimes routing through shopping malls is optimal even for long-distance foot routing, so it would be nice if regular routers could keep make use of such footways. -- Matthijs ___ 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] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
It should be pretty trivial to have the area share nodes with the highway ways where the signals would normally be mapped. Like drawing a square around a tic-tac-toe board, but the shared nodes are only on one side at a time. Also, I think It could also share nodes with the walkways and other pedestrian oriented ways, as the signal would be part of their routing as well. Javbw On Sep 21, 2014, at 3:48 PM, Lukas Sommer sommer...@gmail.com wrote: So the nodes where the signals_area intersects the highways is where the signals would normally be mapped for complex intersections? Not exactly. It would be difficult to do so if you have really complex junctions with really many individual traffic signals and you want to catch all of them – a zickzack that is not easy to draw and not practical to maintain. The area is drawn just _around_ everything that is considered the junction. About the individual traffic signals. We recommand as current best-practice to not map them if you use the area. Means: Don’t do both things. (But maybe in the future this could be considered useful and it could be done without breaking the tagging scheme just like every other normal traffic signal with highway=traffic_signals on a node.) ___ 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] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
It should be pretty trivial to have the area share nodes with the highway ways where the signals would normally be mapped. Like drawing a square around a tic-tac-toe board, but the shared nodes are only on one side at a time. Here, I strongly disagree. The defination on the proposal page is clear: We do not want to have tags on the shared nodes. Only this way it is clear what is within the area, and what is without. We should not give up this possiblility. And your idea actually would give up this possiblilty. Next problem with your idea: You need to have shared nodes not only for incoming, but also for the outgoing oneways. And mostly there is no real traffic signal _after_ you have passed a crossroad. Nevertheless you have there a node. So later you won’t be able to know if on a specific node there is really a traffic signal or not. We don’t have any need to represent the individual traffic signals in the border. It would make the usage far to complicate. And you would not gain anything. If you want to mark individual traffic signals, use the existing tagging. But don’t invent a new one – don’t make it unnecessarily complicate! Also, I think It could also share nodes with the walkways and other pedestrian oriented ways, as the signal would be part of their routing as well. Here, I agree. I assumed that people would do so automatically, but I’ll also add it on the wiki page. Lukas Sommer 2014-09-21 21:30 GMT+00:00 John Willis jo...@mac.com: It should be pretty trivial to have the area share nodes with the highway ways where the signals would normally be mapped. Like drawing a square around a tic-tac-toe board, but the shared nodes are only on one side at a time. Also, I think It could also share nodes with the walkways and other pedestrian oriented ways, as the signal would be part of their routing as well. Javbw On Sep 21, 2014, at 3:48 PM, Lukas Sommer sommer...@gmail.com wrote: So the nodes where the signals_area intersects the highways is where the signals would normally be mapped for complex intersections? Not exactly. It would be difficult to do so if you have really complex junctions with really many individual traffic signals and you want to catch all of them – a zickzack that is not easy to draw and not practical to maintain. The area is drawn just _around_ everything that is considered the junction. About the individual traffic signals. We recommand as current best-practice to not map them if you use the area. Means: Don’t do both things. (But maybe in the future this could be considered useful and it could be done without breaking the tagging scheme just like every other normal traffic signal with highway=traffic_signals on a node.) ___ 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 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] Feature Proposal - RFC - cycleway=soft_lane
On Sun, Sep 21, 2014 at 10:36 AM, Hubert sg.fo...@gmx.de wrote: I would like to ask for any comments and opinions to this proposal https://wiki.opens https://wiki.openstreetmap.org/wiki/Soft_lane I'm against this. Along with cycleway=lane/hov=lane at this point. Just use per-lane tagging (bicycle:lanes=*) and lane change restriction tagging (change:lanes=*) as appropriate. ___ 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] Simple Indoor Tagging
Il giorno 21/set/2014, alle ore 22:51, Janko Mihelić jan...@gmail.com ha scritto: Would it be OK to tag the red lines as indoor=corridor? 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 ;-) cheers, Martin ___ 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
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Sep 22, 2014, at 6:48 AM, Lukas Sommer sommer...@gmail.com wrote: It should be pretty trivial to have the area share nodes with the highway ways where the signals would normally be mapped. Like drawing a square around a tic-tac-toe board, but the shared nodes are only on one side at a time. Here, I strongly disagree. The defination on the proposal page is clear: We do not want to have tags on the shared nodes. Only this way it is clear what is within the area, and what is without. We should not give up this possiblility. And your idea actually would give up this possiblilty. No tags on the shared nodes - just shared nodes. Next problem with your idea: You need to have shared nodes not only for incoming, but also for the outgoing oneways. And mostly there is no real traffic signal _after_ you have passed a crossroad. Nevertheless you have there a node. So later you won’t be able to know if on a specific node there is really a traffic signal or not. would the intersecting roads still have a shared (untagged) node in the center? We don’t have any need to represent the individual traffic signals in the border. It would make the usage far to complicate. And you would not gain anything. If you want to mark individual traffic signals, use the existing tagging. But don’t invent a new one – don’t make it unnecessarily complicate! I thought the shared nodes with the areas would easily represent what the signal_area is affecting, and when it is affecting it (before entering the intersection). Made a test to show you what I was thinking. https://www.openstreetmap.org/#map=18/36.32478/139.10396 Also, I think It could also share nodes with the walkways and other pedestrian oriented ways, as the signal would be part of their routing as well. Yea - at the intersection where the decision to change routes is made. Here, I agree. I assumed that people would do so automatically, but I’ll also add it on the wiki page. Lukas Sommer - Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
Another difference between college dormitories and apartments is that dormitory rooms usually lack cooking facilities, and, at least in older buildings, may have communal toilet/shower facilities rather than en suite facilities. On September 20, 2014 8:47:08 AM sabas88 saba...@gmail.com wrote: On 19 Sep 2014 16:54, Tobias Knerr o...@tobias-knerr.de wrote: On 19.09.2014 14:22 Dan S wrote: for buildings: building=residential + residential=university + operator=* OR for sites: landuse=residential + residential=university + operator=* Note that the same scheme seems to me to work well for building and for landuse. I thought this had been discussed on tagging recently, but I can't find it, all I can find is the RFC for amenity=dormitory, currently used 263 times. (I will add that dormitory is certainly a little odd from a British English point of view, notwithstanding the comments already made to the RFC.) That proposal now suggests amenity=student_accommodation, precisely because of the oddness involved with the term dormitory. Personally, I prefer using the amenity key rather than building or landuse. Landuse lacks the implication that this is one distinct facility, and building values are not supposed to represent usage, but how the building is built. +1 I tagged some student residences as tourism=guest_house previously, but they aren't buildings (some are apartments inside buildings, but owned by the local government agency for student services). Stefano ___ 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 mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Soapy) Massage Parlour
Hi, To avoid having the word massage throwing off the discussion, I'll refer to it under it's legal name of entertainment place. I'll go ahead with the restrictions then, but the other issue is the specific legal classification that entertainment places fall under[1] as opposed to a regular, much smaller place which offer massages and have the same restrictions posted on the door. You need a specific license to operate a entertainment place which makes it subject to zoning, taxes and other laws and an establishment that operates under this legal definition and license should be tagged accordingly. [1] http://www.lawreform.go.th/lawreform/eng/index.php?option=com_homelawreformentask=showtoclid=705gid=6eword=Pename=Acts%20of%20Parliamentelawname=Public%20Entertainment%20Place%20Act,%20B.E.%202509%20%281966%29 On 9/21/14 22:07, Dan S wrote: Hi, Well, that suggestion specifies access limits (i.e. only males age 21 or more), and if those are true facts and they're what you want to indicate, then go ahead. The access limits don't really tell you if something is soapy or not, but if you decide you only want to imply that and not to state it explicitly, your approach sounds OK to me. However, there's NO reason to use amenity=massage_parlour when shop=massage already exists. Please use it. You said you want to avoid confusion between soapy and family-friendly, and your age-restriction works for that, no need to create a duplicate tag. Best Dan 2014-09-21 14:52 GMT+01:00 Mishari Muqbil mish...@mishari.net: Hi, I saw that, but I'm not convinced it's the right approach as what I'm referring require a specific massage parlor license to operate as opposed to a regular traditional massage establishment which is more suited for shop=massage. I think it would be akin to saying a convenience store and supermarket can all be tagged the same way. Also, I'm not comfortable with using sexual as it could be libelous to state that something illegal is taking place in these establishments (for example, you won't do shop=convenience+marijuana=yes in most parts of the world). How about something like a combination of: amenity=massage_parlour male=yes female=no min_age=21 This should be quite accurate. On 21/9/14 16:04, Dan S wrote: Hi - It looks like there's this tag, including a tag suggested for your specific issue: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage Best Dan 2014-09-21 4:23 GMT+01:00 Mishari Muqbil mish...@mishari.net: Hi, Thailand has these places called entertainment complexes[1] that offers bathing + massage services and quite often the expectation is that there will be sexual services offered. However, I don't want to tag them as brothels as prostitution on the premises is legally not allowed[2]. I propose to tag this as leisure=massage_parlour since that's what the Thai English dictionary calls them[3] but I don't want it to be mistaken for more family friendly establishments in other parts of the world. Colloquially these places are called soapy massage so perhaps leisure=soapy_massage? :) One reason why they should be mapped is just how prominent they are as landmarks in general. For example, here's one called Utopia http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw Any thoughts? [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat [2] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act [3] http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94 -- Best regards Mishari Muqbil EE32 64BD 7D1F 5946 ___ 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 mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ 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
The name tag can be whatever it is, but making a amenity=soapland might be what you are looking for. That way there is no confusion with massage places and clearly understood to be for adult services. Javbw. Sent from my iPhone On Sep 22, 2014, at 1:05 PM, Mishari Muqbil mish...@mishari.net wrote: Hi, To avoid having the word massage throwing off the discussion, I'll refer to it under it's legal name of entertainment place. I'll go ahead with the restrictions then, but the other issue is the specific legal classification that entertainment places fall under[1] as opposed to a regular, much smaller place which offer massages and have the same restrictions posted on the door. You need a specific license to operate a entertainment place which makes it subject to zoning, taxes and other laws and an establishment that operates under this legal definition and license should be tagged accordingly. [1] http://www.lawreform.go.th/lawreform/eng/index.php?option=com_homelawreformentask=showtoclid=705gid=6eword=Pename=Acts%20of%20Parliamentelawname=Public%20Entertainment%20Place%20Act,%20B.E.%202509%20%281966%29 On 9/21/14 22:07, Dan S wrote: Hi, Well, that suggestion specifies access limits (i.e. only males age 21 or more), and if those are true facts and they're what you want to indicate, then go ahead. The access limits don't really tell you if something is soapy or not, but if you decide you only want to imply that and not to state it explicitly, your approach sounds OK to me. However, there's NO reason to use amenity=massage_parlour when shop=massage already exists. Please use it. You said you want to avoid confusion between soapy and family-friendly, and your age-restriction works for that, no need to create a duplicate tag. Best Dan 2014-09-21 14:52 GMT+01:00 Mishari Muqbil mish...@mishari.net: Hi, I saw that, but I'm not convinced it's the right approach as what I'm referring require a specific massage parlor license to operate as opposed to a regular traditional massage establishment which is more suited for shop=massage. I think it would be akin to saying a convenience store and supermarket can all be tagged the same way. Also, I'm not comfortable with using sexual as it could be libelous to state that something illegal is taking place in these establishments (for example, you won't do shop=convenience+marijuana=yes in most parts of the world). How about something like a combination of: amenity=massage_parlour male=yes female=no min_age=21 This should be quite accurate. On 21/9/14 16:04, Dan S wrote: Hi - It looks like there's this tag, including a tag suggested for your specific issue: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage Best Dan 2014-09-21 4:23 GMT+01:00 Mishari Muqbil mish...@mishari.net: Hi, Thailand has these places called entertainment complexes[1] that offers bathing + massage services and quite often the expectation is that there will be sexual services offered. However, I don't want to tag them as brothels as prostitution on the premises is legally not allowed[2]. I propose to tag this as leisure=massage_parlour since that's what the Thai English dictionary calls them[3] but I don't want it to be mistaken for more family friendly establishments in other parts of the world. Colloquially these places are called soapy massage so perhaps leisure=soapy_massage? :) One reason why they should be mapped is just how prominent they are as landmarks in general. For example, here's one called Utopia http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw Any thoughts? [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat [2] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act [3] http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94 -- Best regards Mishari Muqbil EE32 64BD 7D1F 5946 ___ 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 mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ 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
