Re: [Tagging] New key proposal - paved=yes/no

[Pee Wee]

-1

A renderer/router is perfectly capable of deciding what he thinks is
paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or
unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map
what you see. As you may have guessed I prefer surface=asphalt over
surface=paved since the last one could mean that it is gravel.

Cheers
PeeWee32

2014-09-21 2:49 GMT+02:00 David Bannon :

>
> yes, agree strongly. Surface= is a good tag, provides important info but
> it is far too fine grained. Someone setting up a route cannot be
> expected to sift through all the possible values.
>
> Similarly, we may well have a chance to get the renderers to respect a
> clear, on/off tag like the proposed and show it on the maps too.
>
> I see no problem with both tags being used.
>
> I think sometimes we put too much detail in the database and risk making
> the data unusable because of that. Mention making the data usable, we
> see charges of "tagging for the renderer". But this is important, I have
> detailed life threatening issues resulting from unclear maps. This
> proposal will provide valuable, dare I say "usable" info for consumers !
>
> David
>
> On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote:
> > Hello all,
> >
> > I've posted the below message on the forum, and have been directed
> > from there to this mailing list, thus re-posting it.
> >
> > Idea
> >
> > I would like to suggest making the paved key for highways (and
> > probably other types of elements) official. Taginfo for paved:
> > http://taginfo.openstreetmap.org/keys/paved#values
> >
> > The above shows that the key is already being used, but the Wiki
> > doesn't describe this key, instead redirecting Key:paved to the
> > article about Key:surface.
> >
> > Rationale
> >
> > Currently, the surface key is being used as a way of saying that a
> > given highway is paved or unpaved, but often the value for the surface
> > key is not a generic paved or unpaved, but a specific surface type is
> > given.This is of course very useful for describing the particular
> > surface type a given highway has. However, in some cases, a simple
> > information on just whether a highway is paved or not, would be very
> > useful. One such case would be navigation software – if a user chooses
> > to avoid unpaved roads, the software can check the value of the
> > surface key, but in practice most (all?) of the navigation software
> > only checks for a subset of all the possible values the surface key
> > can have. This leads to incorrect (in terms of what the user expects)
> > navigation when, for example, the surface is set to some value that
> > describes an unpaved road, not recognized by the navigation software –
> > if the software assumes that all highways are paved, unless explicitly
> > stated otherwise (by recognized values of known keys), then, in
> > consequence, it assumes that the road in question is paved.
> >
> > If the paved key was widely used, then the navigation software would
> > have a simple and clear way of checking whether a given road is paved
> > or not. The default value of the paved key for highways could be yes,
> > so that it would be consistent with the assumption that highways in
> > general are paved.
> >
> > I don't mean that we should stop using the paved and unpaved values
> > for the surface key – I'm sure those generic values are useful in some
> > cases. However, using the paved key would be also very useful. Also,
> > the surface=paved could also implicate paved=yes and similarly
> > surface=unpaved could implicate paved=no, so that duplication of the
> > information could be avoided when the generic paved and unpaved values
> > are set for the surface key.
> >
> > I believe that adding an article for the paved key to the Wiki would
> > encourage people to use this tag, and navigation software makers to
> > implement support for it in their applications.
> >
> > What do you think about that?
> >
> >
> >
> > Regards,
> >
> > Tomek
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Verbeter de wereld. Word mapper voor Openstreetmap
.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] (Soapy) Massage Parlour

[Dan S]

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 :
> 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

[Volker Schmidt]

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  wrote:

> -1
>
> A renderer/router is perfectly capable of deciding what he thinks is
> paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or
> unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map
> what you see. As you may have guessed I prefer surface=asphalt over
> surface=paved since the last one could mean that it is gravel.
>
> Cheers
> PeeWee32
>
> 2014-09-21 2:49 GMT+02:00 David Bannon :
>
>>
>> yes, agree strongly. Surface= is a good tag, provides important info but
>> it is far too fine grained. Someone setting up a route cannot be
>> expected to sift through all the possible values.
>>
>> Similarly, we may well have a chance to get the renderers to respect a
>> clear, on/off tag like the proposed and show it on the maps too.
>>
>> I see no problem with both tags being used.
>>
>> I think sometimes we put too much detail in the database and risk making
>> the data unusable because of that. Mention making the data usable, we
>> see charges of "tagging for the renderer". But this is important, I have
>> detailed life threatening issues resulting from unclear maps. This
>> proposal will provide valuable, dare I say "usable" info for consumers !
>>
>> David
>>
>> On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote:
>> > Hello all,
>> >
>> > I've posted the below message on the forum, and have been directed
>> > from there to this mailing list, thus re-posting it.
>> >
>> > Idea
>> >
>> > I would like to suggest making the paved key for highways (and
>> > probably other types of elements) official. Taginfo for paved:
>> > http://taginfo.openstreetmap.org/keys/paved#values
>> >
>> > The above shows that the key is already being used, but the Wiki
>> > doesn't describe this key, instead redirecting Key:paved to the
>> > article about Key:surface.
>> >
>> > Rationale
>> >
>> > Currently, the surface key is being used as a way of saying that a
>> > given highway is paved or unpaved, but often the value for the surface
>> > key is not a generic paved or unpaved, but a specific surface type is
>> > given.This is of course very useful for describing the particular
>> > surface type a given highway has. However, in some cases, a simple
>> > information on just whether a highway is paved or not, would be very
>> > useful. One such case would be navigation software – if a user chooses
>> > to avoid unpaved roads, the software can check the value of the
>> > surface key, but in practice most (all?) of the navigation software
>> > only checks for a subset of all the possible values the surface key
>> > can have. This leads to incorrect (in terms of what the user expects)
>> > navigation when, for example, the surface is set to some value that
>> > describes an unpaved road, not recognized by the navigation software –
>> > if the software assumes that all highways are paved, unless explicitly
>> > stated otherwise (by recognized values of known keys), then, in
>> > consequence, it assumes that the road in question is paved.
>> >
>> > If the paved key was widely used, then the navigation software would
>> > have a simple and clear way of checking whether a given road is paved
>> > or not. The default value of the paved key for highways could be yes,
>> > so that it would be consistent with the assumption that highways in
>> > general are paved.
>> >
>> > I don't mean that we should stop using the paved and unpaved values
>> > for the surface key – I'm sure those generic values are useful in some
>> > cases. However, using the paved key would be also very useful. Also,
>> > the surface=paved could also implicate paved=yes and similarly
>> > surface=unpaved could implicate paved=no, so that duplication of the
>> > information could be avoided when the generic paved and unpaved values
>> > are set for the surface key.
>> >
>> > I believe that adding an article for the paved key to the Wiki would
>> > encourage people to use this tag, and navigation software makers to
>> > implement support for it in their applications.
>> >
>> > What do you think about that?
>> >
>> >
>> >
>> > Regards,
>> >
>> > Tomek
>> >
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> --
> Verbeter de wereld. Word mapper voor Openstreetmap
> 

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Dan S]

2014-09-21 0:49 GMT+01:00 Eugene Alvin Villar :
> On Sun, Sep 21, 2014 at 7:09 AM,  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)

[Dan S]

2014-09-19 16:15 GMT+01:00 Martin Koppenhoefer :

>
> 2014-09-19 14:22 GMT+02:00 Dan S :
>
>>
>>  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 
> 78 141
>
> -
>
> urban 
> 12 698
>
> -
>
> garden 
> 3 805
>
> -
>
> gated 
> 884
>
> -
>
> apartments 
> 231
>
> -
>
> single_family
> 
> 197
>
> -
>
> 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

[Dave Swarthout]

@Dan S — Good answer. I was wondering how to tag such places myself.

On Sun, Sep 21, 2014 at 4:04 PM, 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 :
> > 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

[Martin Koppenhoefer]

> Il giorno 21/set/2014, alle ore 09:29, Pee Wee  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

[Mishari Muqbil]

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 :
>> 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

[Pee Wee]

2014-09-21 15:37 GMT+02:00 Martin Koppenhoefer :

>
>
>
>
> > Il giorno 21/set/2014, alle ore 09:29, Pee Wee  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

[Dan S]

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 :
> 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 :
>>> 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

[Hubert]

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

[Dan S]

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

[Tod Fitch]

On Sep 21, 2014, at 7:34 AM, Pee Wee wrote:

> 
> Well if an unpaved  forest path would get gravel or fine_gravel thrown on top 
> of it I would consider this some sort of paving that could be classified as 
> "paved". You apparently don't. No need to argue about that , it only goes to 
> show that the suggested tag would not work. ;-)
> 

In my part of the world, I can't imagine anyone in the general public 
considering a gravel surfaced path or road as being "paved".

On Sep 21, 2014, at 12:29 AM, Pee Wee wrote:

> -1
> 
> A renderer/router is perfectly capable of deciding what he thinks is 
> paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or 
> unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map what 
> you see. As you may have guessed I prefer surface=asphalt over surface=paved 
> since the last one could mean that it is gravel.
> 

In my mind, a good tagging scheme should have two main goals:
1. To be easy for a novice or entry level OpenStreetLevel mapper to do.
2. Be easy for data consumers to digest for wide spread uses.

Looking at the first, in many cases we fail miserably at this. Where to go for 
definitive information (wiki, taginfo, mail lists, which of a couple help 
forums, etc.)? But we also fail when we try to get too sophisticated with our 
tagging. Despite being actively discouraged, "paved=yes/no" is used. And two of 
the top values for "surface=*" are "paved" and "unpaved", clearly taggers find 
the concept of "is paved" versus "is not paved" a natural one. And I strongly 
suspect you would get a more consistent result from an arbitrary person trying 
to "map what you see" if you asked them to look at a road and determine if it 
was paved or not than if you asked them to specify the name of the surface 
material. This is particularly true if their survey consists in driving from 
point A to point B and then asked (or trying to edit data in OSM) what the road 
surface was on each section road they used. They can probably tell you which 
sections were "unpaved" and which were "paved" but not tell you where the 
surface changed from concrete to asphalt, etc.

On the second point, looking on printed maps of many vintages and at several 
routing engines, I see a distinction between "paved" and "unpaved". But not, 
with the exception of maps for a pretty specialized small group of people like 
highway engineers, between various paving types. So I think the biggest use of 
the "surface=*" tag is to determine "paved=yes/no". Giving a multivalued field 
to data consumers that need a boolean value requires a translation of some 
sort. We should not be "(mis)tagging for the (broken) renderer", but 
fundamentally we are "tagging for easy use by a software based data consumer" 
and in many years of software engineering I've noticed that every time you 
build a need for a translation in a process you build in a place for an error 
to creep in. So while "a renderer/router is perfectly capable of deciding" 
there can be inconsistencies in that translation between one data consumer and 
another leading people to suspect that something is flawed in data source.

From both of the above, it seems that having "paved=yes/no" with "surface=*" 
would make it easier for both OSM mappers and OSM data consumers.

Cheers
Tod

 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Tom Pfeifer]

Tod Fitch wrote on 2014-09-21 18:05:

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.

As others already pointed out, the definition of 'paved' depends on the use. 
And OSM gives us the
chance, contrary to vintage printed maps, to customise maps to specialised 
users, even if that
group might be very small.

To cite the gravel road again, while the truck driver is happy that she does 
not sink in the mud,
and consider this as a kind of paving, the cyclist will avoid it if somehow 
possible.

Thus the detailed list of surface is fine, and the router can decide based on 
the user profile what
to use and to avoid, i.e. what this particular usage considers paving.

And the list is easy enough for a novice to understand, better than letting him 
make the
decision what paving means.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - cycleway=soft_lane

[Volker Schmidt]

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 =soft_lane

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 .

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

[Dan S]

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

[moltonel 3x Combo]

On 21/09/2014, Tod Fitch  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

[Janko Mihelić]

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 :

> On 20 September 2014 11:11, Peter Barth  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

[John Willis]

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  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

[Lukas Sommer]

> 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 :

> 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  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

Re: [Tagging] (Soapy) Massage Parlour

[John Willis]

The word you are looking for soapland. Japan has the same "give you a bath and 
then have naughty fun" places called soaplands.  They are becoming rarer and 
rarer, but that is the term for them. Fits pretty well with the "soapy 
massage". Using massage is not right because they are more for adult 
entertainment or sex services than for massage. You would never go to them for 
sore muscles, but for adult interaction with the masseuse. (Like a strip club) 
or for services (like a brothel) 

Sent from my iPad

> On Sep 21, 2014, at 6:04 PM, 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 :
>> 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] New key proposal - paved=yes/no

[Tomasz Kaźmierczak]

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

[Paul Johnson]

Along with this, I really hope renderers start computing surface=* and
toll=* values for ALL ways.  I say this since "surface=asphalt,
highway=cyclway" is an exceptionally rare combination in the midwestern US,
but "highway=cycleway, surface=gravel, toll=yes" is not.

On Sun, Sep 21, 2014 at 2:29 AM, Pee Wee  wrote:

> -1
>
> A renderer/router is perfectly capable of deciding what he thinks is
> paved/unpaved. He can decide whether he calls gravel / fine_gravel paved or
> unpaved. Do not leave the decision paved/unpaved  up to the mapper. Map
> what you see. As you may have guessed I prefer surface=asphalt over
> surface=paved since the last one could mean that it is gravel.
>
> Cheers
> PeeWee32
>
> 2014-09-21 2:49 GMT+02:00 David Bannon :
>
>>
>> yes, agree strongly. Surface= is a good tag, provides important info but
>> it is far too fine grained. Someone setting up a route cannot be
>> expected to sift through all the possible values.
>>
>> Similarly, we may well have a chance to get the renderers to respect a
>> clear, on/off tag like the proposed and show it on the maps too.
>>
>> I see no problem with both tags being used.
>>
>> I think sometimes we put too much detail in the database and risk making
>> the data unusable because of that. Mention making the data usable, we
>> see charges of "tagging for the renderer". But this is important, I have
>> detailed life threatening issues resulting from unclear maps. This
>> proposal will provide valuable, dare I say "usable" info for consumers !
>>
>> David
>>
>> On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote:
>> > Hello all,
>> >
>> > I've posted the below message on the forum, and have been directed
>> > from there to this mailing list, thus re-posting it.
>> >
>> > Idea
>> >
>> > I would like to suggest making the paved key for highways (and
>> > probably other types of elements) official. Taginfo for paved:
>> > http://taginfo.openstreetmap.org/keys/paved#values
>> >
>> > The above shows that the key is already being used, but the Wiki
>> > doesn't describe this key, instead redirecting Key:paved to the
>> > article about Key:surface.
>> >
>> > Rationale
>> >
>> > Currently, the surface key is being used as a way of saying that a
>> > given highway is paved or unpaved, but often the value for the surface
>> > key is not a generic paved or unpaved, but a specific surface type is
>> > given.This is of course very useful for describing the particular
>> > surface type a given highway has. However, in some cases, a simple
>> > information on just whether a highway is paved or not, would be very
>> > useful. One such case would be navigation software – if a user chooses
>> > to avoid unpaved roads, the software can check the value of the
>> > surface key, but in practice most (all?) of the navigation software
>> > only checks for a subset of all the possible values the surface key
>> > can have. This leads to incorrect (in terms of what the user expects)
>> > navigation when, for example, the surface is set to some value that
>> > describes an unpaved road, not recognized by the navigation software –
>> > if the software assumes that all highways are paved, unless explicitly
>> > stated otherwise (by recognized values of known keys), then, in
>> > consequence, it assumes that the road in question is paved.
>> >
>> > If the paved key was widely used, then the navigation software would
>> > have a simple and clear way of checking whether a given road is paved
>> > or not. The default value of the paved key for highways could be yes,
>> > so that it would be consistent with the assumption that highways in
>> > general are paved.
>> >
>> > I don't mean that we should stop using the paved and unpaved values
>> > for the surface key – I'm sure those generic values are useful in some
>> > cases. However, using the paved key would be also very useful. Also,
>> > the surface=paved could also implicate paved=yes and similarly
>> > surface=unpaved could implicate paved=no, so that duplication of the
>> > information could be avoided when the generic paved and unpaved values
>> > are set for the surface key.
>> >
>> > I believe that adding an article for the paved key to the Wiki would
>> > encourage people to use this tag, and navigation software makers to
>> > implement support for it in their applications.
>> >
>> > What do you think about that?
>> >
>> >
>> >
>> > Regards,
>> >
>> > Tomek
>> >
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> --
> Verbeter de wereld. Word mapper voor Openstreetmap
> .
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/l

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

On Sun, Sep 21, 2014 at 4:06 AM, Volker Schmidt  wrote:

> For bicycle routing the paved information is not very useful.


I strongly dispute this.  In the US, where practical bicycles are the
exception, not the rule, surface information is exceptionally important.
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

[Paul Johnson]

On Sun, Sep 21, 2014 at 10:36 AM, Hubert  wrote:

> I would like to ask for any comments and opinions to this proposal
> https://wiki.opens 
>

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

[David Bannon]

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

[Martin Koppenhoefer]

> Il giorno 21/set/2014, alle ore 22:51, Janko Mihelić  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

[Dave Swarthout]

On Sun, Sep 21, 2014 at 11:05 PM, Tod Fitch  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 

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

[johnw]

On Sep 22, 2014, at 6:48 AM, Lukas Sommer  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)

[John F. Eldredge]

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  wrote:


On 19 Sep 2014 16:54, "Tobias Knerr"  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

[Mishari Muqbil]

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_homelawreformen&task=showtoc&lid=705&gid=6&eword=P&ename=Acts%20of%20Parliament&elawname=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 :
>> 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 :
 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

[John Willis]

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  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_homelawreformen&task=showtoc&lid=705&gid=6&eword=P&ename=Acts%20of%20Parliament&elawname=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 :
>>> 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 :
> 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] (Soapy) Massage Parlour

[Stephan Knauss]

On 21.09.2014 11:04, Dan S wrote:

It looks like there's this tag, including a tag suggested for your
specific issue:
http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage


please don't use shop=massage for this kind of places.

I really don't want them to show up on a map next to Wat Pho massage 
just because the map creator does not take into account some additional 
tagging which says "yes, it's tagged as a massage, but this tag tells 
you it isn't".


Additional tags can specify something further, but should not change the 
meaning in general.


Think of amenity=place_of_worship. They are all sort of religious place. 
If your map cares, it can distinguish between Buddhist, Christian or 
Muslim. But still it's a place of worship.



Stephan


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging