[Tagging] Simple Indoor Tagging
Hi, 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 We think that this proposal is simple and holistic at once and ready to be used. Anyhow, we'd like to hear your opinion if there's something we missed. Please comment either here, at the proposal's discussion page or in the original thread in the forum (http://forum.openstreetmap.org/viewtopic.php?pid=451544). Peda -- ___ 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 15:52 GMT+01:00 Tobias Knerr o...@tobias-knerr.de: 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. Ah yes, thanks. So now it assumes the occupants are students and not lecturers ;) (I'm just being cheeky. I know of universities in which lecturers do stay in similar accommodation blocks, but that point is not important enough to argue about...) Personally, I prefer using the amenity key rather than building or landuse. Landuse lacks the implication that this is one distinct facility OK. I understand why you'd prefer amenity for tagging the usage. If that tag gets accepted I guess I should use that instead of landuse, and I understand your arguments there. I feel differently, because I feel the analogy between a housing estate and a multi-building student halls site is quite a strong analogy, neatly represented by a named area of landuse=residential. But there we go. and building values are not supposed to represent usage, but how the building is built. This week I stayed in university accommodation (even though I'm not a student ;), and the buildings were purpose-built student halls, so it would be nice to tag the building appropriately. Alternatives include: (a) building=residential (without subtagging), which is fine if vague; (b) building=apartments, which is tolerable but not quite appropriate; (c) building=dormitory which is in use, but it's US English, and to my Brit English mind just feels wrong. Sorry to moan about the US/UK difference, but it is indeed a difference: http://dictionary.cambridge.org/dictionary/british/dormitory, http://www.oxforddictionaries.com/definition/english/dormitory (d) building=residential + residential=university, the approach I was using recently. Not as widely used. It has an advantage of graceful fallback (meaning data-users can understand the objects as building=residential even if they ignore the subtag). I still prefer (d) though if building=dormitory becomes widely accepted then I guess I shall have to swallow that loss for British english! 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)
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
Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
Students accommodation is neither tourism or guesthouse, I would have gone for hall_of_residence. Phil (trigpoint ) On Sat Sep 20 2014 14:46:17 GMT+0100 (BST), sabas88 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 -- Sent from my Jolla ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
Am 20.09.2014 18:32, schrieb p...@trigpoint.me.uk: Students accommodation is neither tourism or guesthouse, +1 I would have gone for hall_of_residence. Do not know if hall_of_residence is the right term. I know this accommodations for staff of hospitals (nurses) , too. Would be nice if could find some tag to describe it without profession. cu fly On Sat Sep 20 2014 14:46:17 GMT+0100 (BST), sabas88 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
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
Am 20.09.2014 02:03, schrieb johnw: So the solution for a complex intersection is to have a signal_area area with an outline that intersects with all the nodes where the signal would affect the traffic? This would let the renderer use one icon, and still have the ways marked in the proper spot for the intersection, right? (assuming they will support signal_area). Not sure if the single traffic_signals node need to be parent of the area but they should be at least within the area as a hint for the renderer. Thanks for considering some extra tag(-combinations) for the area. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
On 09/20/2014 12:41 PM, fly wrote: Am 20.09.2014 18:32, schrieb p...@trigpoint.me.uk: I would have gone for hall_of_residence. Do not know if hall_of_residence is the right term. hall_of_residence would work. i would have proposed the shorter, less formal term residence_hall which is what you will find in US usage. richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
Il giorno 20/set/2014, alle ore 13:47, Dan S danstowell+...@gmail.com ha scritto: I still prefer (d) though if building=dormitory becomes widely accepted then I guess I shall have to swallow that loss for British english! I'm also for a specific value, if dormitory doesn't hit it for the British, maybe there is an analog term? cheers Martin ___ 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
Okay, I’ve adapted the proposal wiki page. We can propose to tag complex traffic signal areas _only_ using the area, and not to tag the individual traffic signals. That makes it easier for renderers to display only one icon per traffic signal area. However, I feel we should not completly exclude for all time the possibility to tag also the individual traffic signals – it is at least a valid information, even if it is not necessary for traditional japanese maps. The individual traffic signals are simple nodes that are located within the area. We would not make it a rule, but just recommand to _not_ tag the individual traffic signals for Japan. As described in the proposal, the area is simply drawn around the approximative area that is affected by the traffic signals. It encloses everything, but shares nodes only with the incoming and outgoing highways. Lukas Sommer 2014-09-20 16:45 GMT+00:00 fly lowfligh...@googlemail.com: Am 20.09.2014 02:03, schrieb johnw: So the solution for a complex intersection is to have a signal_area area with an outline that intersects with all the nodes where the signal would affect the traffic? This would let the renderer use one icon, and still have the ways marked in the proper spot for the intersection, right? (assuming they will support signal_area). Not sure if the single traffic_signals node need to be parent of the area but they should be at least within the area as a hint for the renderer. Thanks for considering some extra tag(-combinations) for the area. cu fly ___ 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
Hello all, I've posted the below message on the forum[1], and have been directed from there to this mailing list, thus re-posting it. *Idea* I would like to suggest making the *paved* key for highways (and probably other types of elements) official. Taginfo for *paved*: http://taginfo.openstreetmap.org/keys/paved#values[2] The above shows that the key is already being used, but the Wiki doesn't describe this key, instead redirecting Key:paved to the article about Key:surface. *Rationale* Currently, the *surface* key is being used as a way of saying that a given *highway* is paved or unpaved, but often the value for the *surface* key is not a generic /paved/ or /unpaved/, but a specific surface type is given.This is of course very useful for describing the particular surface type a given highway has. However, in some cases, a simple information on just whether a highway is paved or not, would be very useful. One such case would be navigation software – if a user chooses to avoid unpaved roads, the software can check the value of the *surface* key, but in practice most (all?) of the navigation software only checks for a subset of all the possible values the *surface* key can have. This leads to incorrect (in terms of what the user expects) navigation when, for example, the *surface* is set to some value that describes an unpaved road, not recognized by the navigation software – if the software assumes that all *highway*s are paved, unless explicitly stated otherwise (by recognized values of known keys), then, in consequence, it assumes that the road in question is paved. If the *paved* key was widely used, then the navigation software would have a simple and clear way of checking whether a given road is paved or not. The default value of the *paved* key for *highway*s could be /yes/, so that it would be consistent with the assumption that *highway*s in general are paved. I don't mean that we should stop using the /paved/ and /unpaved/ values for the *surface* key – I'm sure those generic values are useful in some cases. However, using the *paved* key would be also very useful. Also, the *surface*=/paved/ could also implicate *paved*=/yes/ and similarly *surface*=/unpaved/ could implicate *paved*=/no/, so that duplication of the information could be avoided when the generic /paved/ and /unpaved/ values are set for the *surface* key. I believe that adding an article for the *paved* key to the Wiki would encourage people to use this tag, and navigation software makers to implement support for it in their applications. What do you think about that? Regards, Tomek [1] http://forum.openstreetmap.org/viewtopic.php?pid=451593 [2] http://taginfo.openstreetmap.org/keys/paved#values ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote: I would like to suggest making the paved key for highways (and probably other types of elements) official. Taginfo for paved: http://taginfo.openstreetmap.org/keys/paved#values The above shows that the key is already being used, but the Wiki doesn't describe this key, instead redirecting Key:paved to the article about Key:surface. -1 duplicative richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
On 9/20/14, Dan S danstowell+...@gmail.com wrote: 2014-09-19 15:52 GMT+01:00 Tobias Knerr o...@tobias-knerr.de: I still prefer (d) though if building=dormitory becomes widely accepted then I guess I shall have to swallow that loss for British english! Wouldn't be the first time if ever: http://wiki.openstreetmap.org/wiki/Tag:sport%3Dsoccer That said, to me dormitories may also apply to other institutionalized housing such as housing for staff of a manufacturing plant. Although I admit that dormitories are primarily for students in my understanding. This ambiguity can be resolved by careful definition in the Wiki if ever people accept *=dormitory. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
On Sat, Sep 20, 2014 at 4:59 PM, Richard Welty rwe...@averillpark.net wrote: On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote: I would like to suggest making the paved key for highways (and probably other types of elements) official. Taginfo for paved: http://taginfo.openstreetmap.org/keys/paved#values The above shows that the key is already being used, but the Wiki doesn't describe this key, instead redirecting Key:paved to the article about Key:surface. -1 duplicative Seconded ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
Dormitories are rooms with multiple beds, usually bunk beds and associated with youth hostels, certainly not suitable for student accommodation where there is typically one student in a room, maybe two but they are certainly not dormitories. Phil (trigpoint ) On Sat Sep 20 2014 23:12:24 GMT+0100 (BST), Eugene Alvin Villar wrote: On 9/20/14, Dan S danstowell+...@gmail.com wrote: 2014-09-19 15:52 GMT+01:00 Tobias Knerr o...@tobias-knerr.de: I still prefer (d) though if building=dormitory becomes widely accepted then I guess I shall have to swallow that loss for British english! Wouldn't be the first time if ever: http://wiki.openstreetmap.org/wiki/Tag:sport%3Dsoccer That said, to me dormitories may also apply to other institutionalized housing such as housing for staff of a manufacturing plant. Although I admit that dormitories are primarily for students in my understanding. This ambiguity can be resolved by careful definition in the Wiki if ever people accept *=dormitory. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Sent from my Jolla ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
On Sep 20, 2014, at 4:00 PM, Paul Johnson wrote: On Sat, Sep 20, 2014 at 4:59 PM, Richard Welty rwe...@averillpark.net wrote: On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote: I would like to suggest making the paved key for highways (and probably other types of elements) official. Taginfo for paved: http://taginfo.openstreetmap.org/keys/paved#values The above shows that the key is already being used, but the Wiki doesn't describe this key, instead redirecting Key:paved to the article about Key:surface. -1 duplicative Seconded It might be considered duplicative, but what should a data consumer do if confronted with a surface=* value that is unknown to it (and the wiki)? We aren't talking human intelligence here where an informed guess is possible. Should such a way be considered paved or unpaved for purposes of routing? From that point of view, Richard's proposal gives a lot of clarity. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)
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. For example, in the Ateneo de Manila University, we have the Cervini Residence Hall for males and Eliazo Residence Hall for females: Note that the Wikipedia article classifies these are dormitories in accordance to local usage even if the official name uses Residence Hall: https://en.wikipedia.org/wiki/Cervini-Eliazo_Residence_Halls In the University of the Philippines, we have several dormitories such as Kalayaan Hall, Ilang-Ilang Hall, Molave Hall, etc. There are also private businesses that run student dormitories, usually located very near universities such as Manila Dormitory across the University of Santo Tomas: http://maniladormitory.com/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
On Sat, Sep 20, 2014 at 6:15 PM, Tod Fitch t...@fitchdesign.com wrote: It might be considered duplicative, but what should a data consumer do if confronted with a surface=* value that is unknown to it (and the wiki)? We aren't talking human intelligence here where an informed guess is possible. Should such a way be considered paved or unpaved for purposes of routing? From that point of view, Richard's proposal gives a lot of clarity. Same way as if the surface tag was missing. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
-1, because: Tomasz Kaźmierczak wrote on 2014-09-20 23:42: I would like to suggest making the paved key for highways (and probably other types of elements) official. Taginfo for paved: http://taginfo.openstreetmap.org/keys/paved#values The above shows that the key is already being used, 1648 times, compared to 9383813 of 'surface'. but the Wiki doesn't describe this key, instead redirecting Key:paved to the article about Key:surface. to discourage the use of a duplicate key However, in some cases, a simple information on just whether a highway is paved or not, would be very useful. One such case would be navigation software – if a user chooses to avoid unpaved roads, Navigation software is pretty able to consider a short list of specific pavings as 'paved' and another short list as 'unpaved', they are already structured in the wiki. OsmAnd, as a popular navigation software, does so, and in the pre-1.9 nightlies you can switch on colour coding for different surfaces. the software can check the value of the surface key, but in practice most (all?) of the navigation software only checks for a subset of all the possible values the surface key can have. Could you please support your argument with examples of such software, and why such incompleteness cannot be fixed within the router/renderer? If the paved key was widely used, then the navigation software would have a simple and clear way of checking whether a given road is paved or not. Not much simpler than checking for a member of a list. The default value of the paved key for highways could be yes, so that it would be consistent with the assumption that highways in general are paved. This does not work as a general assumption. I would assume a motorway as paved, but a track or path as unpaved, unless shown otherwise. Also, the surface=paved could also implicate paved=yes and similarly surface=unpaved could implicate paved=no, so that duplication of the information could be avoided when the generic paved and unpaved values are set for the surface key. You are just arguing against your proposal. As we have surface=paved we don't need paved=yes. And surface=asphalt implies paved. Tod Fitch wrote on 2014-09-21 01:15: It might be considered duplicative, but what should a data consumer do if confronted with a surface=* value that is unknown to it (and the wiki)? We aren't talking human intelligence here where an informed guess is possible. Should such a way be considered paved or unpaved for purposes of routing? From that point of view, Richard's proposal gives a lot of clarity. You would not want to add 9383813 unnecessary paved=yes/no just to cover a few dozen undocumented values for surface, most of them probably typos. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
yes, agree strongly. Surface= is a good tag, provides important info but it is far too fine grained. Someone setting up a route cannot be expected to sift through all the possible values. Similarly, we may well have a chance to get the renderers to respect a clear, on/off tag like the proposed and show it on the maps too. I see no problem with both tags being used. I think sometimes we put too much detail in the database and risk making the data unusable because of that. Mention making the data usable, we see charges of tagging for the renderer. But this is important, I have detailed life threatening issues resulting from unclear maps. This proposal will provide valuable, dare I say usable info for consumers ! David On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote: Hello all, I've posted the below message on the forum, and have been directed from there to this mailing list, thus re-posting it. Idea I would like to suggest making the paved key for highways (and probably other types of elements) official. Taginfo for paved: http://taginfo.openstreetmap.org/keys/paved#values The above shows that the key is already being used, but the Wiki doesn't describe this key, instead redirecting Key:paved to the article about Key:surface. Rationale Currently, the surface key is being used as a way of saying that a given highway is paved or unpaved, but often the value for the surface key is not a generic paved or unpaved, but a specific surface type is given.This is of course very useful for describing the particular surface type a given highway has. However, in some cases, a simple information on just whether a highway is paved or not, would be very useful. One such case would be navigation software – if a user chooses to avoid unpaved roads, the software can check the value of the surface key, but in practice most (all?) of the navigation software only checks for a subset of all the possible values the surface key can have. This leads to incorrect (in terms of what the user expects) navigation when, for example, the surface is set to some value that describes an unpaved road, not recognized by the navigation software – if the software assumes that all highways are paved, unless explicitly stated otherwise (by recognized values of known keys), then, in consequence, it assumes that the road in question is paved. If the paved key was widely used, then the navigation software would have a simple and clear way of checking whether a given road is paved or not. The default value of the paved key for highways could be yes, so that it would be consistent with the assumption that highways in general are paved. I don't mean that we should stop using the paved and unpaved values for the surface key – I'm sure those generic values are useful in some cases. However, using the paved key would be also very useful. Also, the surface=paved could also implicate paved=yes and similarly surface=unpaved could implicate paved=no, so that duplication of the information could be avoided when the generic paved and unpaved values are set for the surface key. I believe that adding an article for the paved key to the Wiki would encourage people to use this tag, and navigation software makers to implement support for it in their applications. What do you think about that? Regards, Tomek ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named
On Sep 21, 2014, at 5:13 AM, Lukas Sommer sommer...@gmail.com wrote: As described in the proposal, the area is simply drawn around the approximative area that is affected by the traffic signals. It encloses everything, but shares nodes only with the incoming and outgoing highways. So the nodes where the signals_area intersects the highways is where the signals would normally be mapped for complex intersections? Sounds like an even simpler solution. - Javbw___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Simple Indoor Tagging
This looks like a great piece of work. Thank you for your efforts. I would like to suggest somehow adding access to your proposal (as a level subkey?). Many times there are levels in a building that are restricted for one reason or another and it would help to know which these are. From the examples it would seem there is a way to add a name to a level but it's not clear to me how one would go about tagging it. Access could be added in a similar fashion. Cheers, Dave On Sat, Sep 20, 2014 at 5:11 PM, Peter Barth osm-tagg...@won2.de wrote: Hi, 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 We think that this proposal is simple and holistic at once and ready to be used. Anyhow, we'd like to hear your opinion if there's something we missed. Please comment either here, at the proposal's discussion page or in the original thread in the forum ( http://forum.openstreetmap.org/viewtopic.php?pid=451544). Peda -- ___ 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] Simple Indoor Tagging
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] (Soapy) Massage Parlour
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
