Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Yves]

I agree with Frederick here, lgbtq=yes looks like the access tags.
This discussion also reminds me the motorcycle-friendly thread not so long ago.
https://wiki.openstreetmap.org/wiki/Proposed_features/motorcycle_friendly
Yves

Le 23 octobre 2018 20:27:04 GMT+02:00, Rory McCann  a 
écrit :
>Hi all,
>
>I'd like to improve the state of mapping/tagging for LGBTQ topics, and
>I'd like feedback.
>
>There is an existing "gay" tag[1], which is used 650 times[2]. But it's
>a little restrictive. And it also suggested "gay:transgender=yes" which
>is just plain wrong.
>
>So to start off, I'm suggest a simple "lgbtq=yes" tag to
>mean "this thing is a LGBTQ thing". I've intermittently used
>"lgbt"/"lgbtq" tag in the past, but I think "lgbtq" ("lesbian gay
>bi trans queer") would probably be a little better.
>
>So "amenity=bar lgbtq=yes" is what is commonly called a "gay bar".
>"shop=books lgbtq=yes" is a LGBTQ book shop, "leisure=sauna lgbtq=yes"
>is a gay sauna, etc. We can expand the tagging later, or just use
>"lgbtq:(men|women|trans|cis|bears|...)=(yes|no)" straight () away.
>
>For trans issues, there's the whole topic of toilet tagging (unisex,
>etc), which is tagged separately, and maybe there's some good way to
>tag
>"informed consent" for medical clinics?
>
>*When* to add a lgbtq=yes tag can be hard to know. In some places a gay
>bar can be easily identified by a prominent rainbow flag. Some cultures
>are less accepting, so bars might not be so blatant (I've seen this in
>the EU). Using the common OSM rules of "local knowledge", people within
>the local LGBTQ community are probably the best place to make a final
>call.
>
>Like many things in OSM, most of the work will be the actual mapping.
>It's best to tag areas your familiar with, IME online directories can
>often have lots of facilities that no longer exist. At some point I
>want
>to create a custom map based on this data (a la the now dead
>OpenQueerMap).
>
>Thoughts? Comments? Feedback?
>
>--
>Rory
>
>[1] 
>https://wiki.openstreetmap.org/wiki/Proposed_features/Visitors_orientation#for_gay.3D.2A
>[2] https://taginfo.openstreetmap.org/search?q=gay
>
>
>___
>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] mast / tower / communication_tower (again)

[Graeme Fitzpatrick]

On Thu, 25 Oct 2018 at 09:41, Joseph Eisenberg 
wrote:

> 1. Multipurpose tower still seems a little ambiguous to me. Observation
> tower is closer for most of them, because they are big enough to have
> elevators and public observation decks, right?
>

Multipurpose certainly isn't ideal, but was the best thing I could come up
with! :-) Most of them do indeed have observation decks, restaurants & so
on, but they're usually also festooned with antennae.


> Since there are already tags for tower:type=observation and
> tower:type=communications, perhaps there is no need for
> man_made=communications_tower?
>

Quite possibly, especially as it's horribly misused, but, as someone said
earlier in the discussion, they do render differently to other towers, show
up on the map fairly early, & make fantastic landmarks.

2. In rendering style sheets it is possible to set the zoom level, the size
> of the icon and the presence of the name label based on height. For example:
> height>100 renders at z13,
> height>50 at z14,
> height>30 at z15,
> And if there is no height, at z17.
>
> So entering a numeric height value in meters provides the most data for
> database users, and the most flexibility for map renderers.
>

That's great, thanks.


> It can be challenging to measure the height of a 100m tall tower, but an
> individual can use a meter stick, a gps and trigonometry to check the
> height in person. Often the height is on a sign for big towers. Armchair
> mappers may be out of luck, unless the sun casts long shadows on the aerial
> imagery, but there are many things that cannot be mapped from one’s
> armchair.
>

Indeed it can be. A lot of the big ones will be listed somewhere on the
internet - the really big ones have their heights listed on that wiki page
I mentioned earlier, & I don't suppose it *really* matters if someone lists
a tower as being 100m when it's really only 80!

Thanks

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

Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Graeme Fitzpatrick]

On Thu, 25 Oct 2018 at 09:56, Joseph Eisenberg 
wrote:

> This is not my area of expertise.


Or mine! :-)


> So I believe this would be verifiable information. It would also be safe
> to tag women=no for bars or clubs even in countries where LGBT activity is
> illegal or persecuted. Men=designated could be used for bars that are
> mainly for gay, bi (and trans?) men, but which do not prohibit women
> explicitly.
>
> I haven’t heard of bars with a “no men” sign, but “women=designated” could
> work for bars catering to lesbian, bisexual )and trans?) women?
>

 How are "gentlemen's" clubs or "ladies only" gyms tagged?

Thanks

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Graeme Fitzpatrick]

On Thu, 25 Oct 2018 at 11:41, Warin <61sundow...@gmail.com> wrote:

> Err no.
>
> The 'government' is not 'foreign' but of federal/state/local jurisdiction
> to that place.
>
> landuse=diplomatic???
>

Yes, but that patch of ground is owned by the "Australian" govt - it's just
that it's located in the US or where-ever!

Thanks

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

Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Paul Johnson]

On Wed, Oct 24, 2018 at 6:56 PM Joseph Eisenberg 
wrote:

> This is not my area of expertise. But I’ve noticed that a number of bars
> that are designed for gay men in the USA have a sign on the door with a
> crossed out “W”. It looks like a no smoking sign but with a capital W
> instead of a cigarette.
>

I've literally never heard of this.  Usually GLBT friendly establishments
in the US and Canada have a rainbow flag out front or are overtly campy, or
in San Francisco's Castro District, *extremely both*.  And in both
countries, you don't have to be a specific gender or orientation to go in
there.  Heck, they'll even generally serve homophobes so long as they're
not disruptive or otherwise harshing the atmosphere:  Money talks, BS walks.


> This means “no women allowed.” My wife tells me this is still legal in the
> USA?!


It's not, 14th Amendment (1868), equal protection clause.  A century later,
we spent a decade re-litigating this in the streets because apparently it
wasn't made clear the first time around.


> There are also barber shops that exclude women (though these shops usually
> serve straight, gay and bi Men without distinctions)
>

There are gender-specific barber/hairdresser shops, but that isn't a
restriction on who they will serve but a description of the specialty of
what hairstyles they can turn out.  A men's barber shop will serve women,
but if they don't want a haircut that's popular among men, the result is
probably going to be on par with something they could get cheaper going to
a beauty school's open house (since that could be very well be the most
recently they've done such a cut, however long ago that was for the barber)
or not really possible at all (at least in the US, a men's barber shop,
especially older ones, might be so basic, particularly in small towns, as
to lack shampoo sinks and hair dryers).

Likewise, womens barbers don't turn away guys, but getting a guy's cut
there is not going to be ideal (my mom would take me to her hairdresser as
a kid sometimes when the whole family needed haircuts, and they'd totally
crush it out of the park with my mom and sister's hair, but totally butcher
mine; but I have full confidence that if I wanted the same cut as my sister
or mom, they'd have got it right).


> So I believe this would be verifiable information. It would also be safe
> to tag women=no for bars or clubs even in countries where LGBT activity is
> illegal or persecuted. Men=designated could be used for bars that are
> mainly for gay, bi (and trans?) men, but which do not prohibit women
> explicitly.
>
> I haven’t heard of bars with a “no men” sign, but “women=designated” could
> work for bars catering to lesbian, bisexual )and trans?) women?


 Pretty sure access tagging is a legal restriction/designation, not a
specialty one.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Paul Johnson]

On Wed, Oct 24, 2018 at 4:12 PM Graeme Fitzpatrick 
wrote:

> I've seen & wondered about the "gay" classification on places before.
>
> When going on holidays & checking accommodation / travel guides for
> options, you often see a number of hotels / motels which are listed as "gay
> friendly". Does this mean only gays stay there / a majority of guests are
> straight but gays are also welcome or what?
>
> To me, with a young family, it's always meant that we're not staying at
> that place!
>

In Oklahoma at least, I find "gay friendly" to be essentially a worthless
identifier or someplace that's a little more social than you would normally
expect from such a business (but tends to attract and cater to a *much* older
crowd, and I'm 36).  Everyplace is gay friendly, and it's not hurting your
family.  Those who are catering specifically to the gay community tend to
be nightclubs and vacation resorts at this point, in which case, it's not
family friendly because it's gay, it's not family friendly because kids
aren't allowed on the property because the liquor and/or gambling laws
either severely restrict where kids can go or ban them outright in the
first place.

However, I can say if I were in someplace more hostile (such as India) or
illegal (like, say, the UAE), and traveling with my boyfriend, I do know
that I'd probably avoid someplace that openly advertised itself as gay
friendly just because that would be an unwanted police and/or violence
magnet, and if we did seek out such an establishment it would be
exclusively under the guidance of a local we know and trust extremely well
(so, at least in the above example regions, we'd just not try since we
don't know anybody in either place).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Joseph Eisenberg]

If amenity=school, amenity=university and amenity=hospital count as a
landuse, then amenity=embassy / consulate can be treated like the landuse
of the area. I don’t think a separate landuse tag is needed if the embassy
is drawn as a closed way (“area”)
-Joseph

On Thu, Oct 25, 2018 at 10:41 AM Warin <61sundow...@gmail.com> wrote:

> Err no.
>
> The 'government' is not 'foreign' but of federal/state/local jurisdiction
> to that place.
>
> landuse=diplomatic???
>
>
>
> On 25/10/18 12:25, Allan Mustard wrote:
>
> I like Graeme's idea.  Round peg in round hole.  How would people feel
> about modifying the current Consulate proposal to encompass this?  Or
> should I leave the proposal for amenity=consulate as it is?
> On 10/25/2018 3:13 AM, Graeme Fitzpatrick wrote:
>
> Just had a thought :-)
>
> Would this work under the landuse=government / civic_admin / public_admin
> that was being discussed t'other day?
>
> Maybe something like:
>
> landuse=government
>
> government=diplomatic (rendering with the current "embassy" flag)
>
> diplomatic=embassy / consulate etc
>
> services=visa; passport etc
>
> Thanks
>
> Graeme
>
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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 - (consulate)

[Warin]

Err no.

The 'government' is not 'foreign' but of federal/state/local 
jurisdiction to that place.


landuse=diplomatic???



On 25/10/18 12:25, Allan Mustard wrote:


I like Graeme's idea.  Round peg in round hole.  How would people feel 
about modifying the current Consulate proposal to encompass this? Or 
should I leave the proposal for amenity=consulate as it is?


On 10/25/2018 3:13 AM, Graeme Fitzpatrick wrote:

Just had a thought :-)

Would this work under the landuse=government / civic_admin / 
public_admin that was being discussed t'other day?


Maybe something like:

landuse=government

government=diplomatic (rendering with the current "embassy" flag)

diplomatic=embassy / consulate etc

services=visa; passport etc

Thanks

Graeme




___
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] Feature Proposal - RFC - (consulate)

[Allan Mustard]

I like Graeme's idea.  Round peg in round hole.  How would people feel
about modifying the current Consulate proposal to encompass this?  Or
should I leave the proposal for amenity=consulate as it is?

On 10/25/2018 3:13 AM, Graeme Fitzpatrick wrote:
> Just had a thought :-)
>
> Would this work under the landuse=government / civic_admin /
> public_admin that was being discussed t'other day? 
>
> Maybe something like:
>
> landuse=government
>
> government=diplomatic (rendering with the current "embassy" flag)
>
> diplomatic=embassy / consulate etc
>
> services=visa; passport etc
>
> Thanks
>
> Graeme

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

Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Joseph Eisenberg]

This is not my area of expertise. But I’ve noticed that a number of bars
that are designed for gay men in the USA have a sign on the door with a
crossed out “W”. It looks like a no smoking sign but with a capital W
instead of a cigarette.

This means “no women allowed.” My wife tells me this is still legal in the
USA?! There are also barber shops that exclude women (though these shops
usually serve straight, gay and bi Men without distinctions)

So I believe this would be verifiable information. It would also be safe to
tag women=no for bars or clubs even in countries where LGBT activity is
illegal or persecuted. Men=designated could be used for bars that are
mainly for gay, bi (and trans?) men, but which do not prohibit women
explicitly.

I haven’t heard of bars with a “no men” sign, but “women=designated” could
work for bars catering to lesbian, bisexual )and trans?) women?
On Thu, Oct 25, 2018 at 6:11 AM Graeme Fitzpatrick 
wrote:

> I've seen & wondered about the "gay" classification on places before.
>
> When going on holidays & checking accommodation / travel guides for
> options, you often see a number of hotels / motels which are listed as "gay
> friendly". Does this mean only gays stay there / a majority of guests are
> straight but gays are also welcome or what?
>
> To me, with a young family, it's always meant that we're not staying at
> that place!
>
> Thanks
>
> Graeme
> ___
> 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] mast / tower / communication_tower (again)

[Joseph Eisenberg]

1. Multipurpose tower still seems a little ambiguous to me. Observation
tower is closer for most of them, because they are big enough to have
elevators and public observation decks, right?

Since there are already tags for tower:type=observation and
tower:type=communications, perhaps there is no need for
man_made=communications_tower?

2. In rendering style sheets it is possible to set the zoom level, the size
of the icon and the presence of the name label based on height. For example:
height>100 renders at z13,
height>50 at z14,
height>30 at z15,
And if there is no height, at z17.

So entering a numeric height value in meters provides the most data for
database users, and the most flexibility for map renderers.

It can be challenging to measure the height of a 100m tall tower, but an
individual can use a meter stick, a gps and trigonometry to check the
height in person. Often the height is on a sign for big towers. Armchair
mappers may be out of luck, unless the sun casts long shadows on the aerial
imagery, but there are many things that cannot be mapped from one’s
armchair.

-Joseph
On Thu, Oct 25, 2018 at 8:05 AM Graeme Fitzpatrick 
wrote:

>
> On Thu, 25 Oct 2018 at 08:19, Joseph Eisenberg 
> wrote:
>
>> FYI, currently the height and tower:type of man_made=tower is used to set
>> the zoom level where it appears on the Openstreetmap-carto style sheet
>> (“standard” style).
>>
>
> Thanks Joseph - I obviously misread it (or don't remember the exact
> wording!), but same thing applies - would splitting heights into 3 bands
> work?
>
> But man_made=communications_tower is assumed to be big and tall, so it
>> renders like a >100m tall tower with no type, or tower:type=communication
>> or observation, visible at zoom level 13.
>
>
> & I'd be happy for my suggested multipurpose tower to render the same way
> as they *are* massive structures that are visible for a long way - it's
> just that the tag is grossly misused as people obviously think that every
> phone tower is a =communications_tower, when it was never intended to be.
>
> Thanks
>
> Graeme
>
> ___
> 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] mast / tower / communication_tower (again)

[Graeme Fitzpatrick]

On Thu, 25 Oct 2018 at 08:19, Joseph Eisenberg 
wrote:

> FYI, currently the height and tower:type of man_made=tower is used to set
> the zoom level where it appears on the Openstreetmap-carto style sheet
> (“standard” style).
>

Thanks Joseph - I obviously misread it (or don't remember the exact
wording!), but same thing applies - would splitting heights into 3 bands
work?

But man_made=communications_tower is assumed to be big and tall, so it
> renders like a >100m tall tower with no type, or tower:type=communication
> or observation, visible at zoom level 13.


& I'd be happy for my suggested multipurpose tower to render the same way
as they *are* massive structures that are visible for a long way - it's
just that the tag is grossly misused as people obviously think that every
phone tower is a =communications_tower, when it was never intended to be.

Thanks

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

Re: [Tagging] mast / tower / communication_tower (again)

[Joseph Eisenberg]

FYI, currently the height and tower:type of man_made=tower is used to set
the zoom level where it appears on the Openstreetmap-carto style sheet
(“standard” style).

But man_made=communications_tower is assumed to be big and tall, so it
renders like a >100m tall tower with no type, or tower:type=communication
or observation, visible at zoom level 13.
On Thu, Oct 25, 2018 at 7:04 AM Graeme Fitzpatrick 
wrote:

>
>
> On Thu, 25 Oct 2018 at 04:03, SelfishSeahorse 
> wrote:
>
>>
>> Regarding the unclear man_made=communications_tower tag, nobody wrote
>> that she or he is opposed to deprecating it. Do we still need a
>> deprecation proposal? (Note that it wasn't introduced by a proposal.)
>>
>
> Just catching back up to OSM & this discussion after a week away.
>
> Do we also need a RFC / vote to amend the wiki page, or can I just amend
> it & clear up the bad reference photo's?
>
> I'd be looking at combining the mentioned engineering definition with the
> popular opinion expressed here to become:
>
> A mast is a tall, slim structure supported by guys, usually with external
> access only
>
> A tower is a tall, slim free-standing structure, usually with internal
> access. (Possible include from wiki: "Towers are specifically
> distinguished from "buildings "
> in that they are not built to be habitable but to serve other functions.")
>
> Replacing man_made=communications_tower with man-made=tower;
> tower=multi_purpose. Yes they're used for communication in that they have
> antennae mounted on them, but are also usually tourist spots with lookouts
> & so on, where normal TV towers etc aren't. I'd even suggest a automatic
> edit to reclassify them - TagInfo says there are currently ~3700
> communications_towers, whereas
> https://en.wikipedia.org/wiki/List_of_tallest_towers suggest there should
> probably be <100. As mentioned previously, there's currently ~200 of them
> tagged in Australia. From checking them at random, it would appear there
> should be 1!
>
> Do we need to worry about height for rendering purposes? (which is what
> this original discussion started from!) If so, would a simple break-down
> into height >30 (m), 30-150, 150+ work?
>
> Thanks
>
> Graeme
>
> ___
> 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 - (consulate)

[Graeme Fitzpatrick]

On Thu, 25 Oct 2018 at 07:37, Warin <61sundow...@gmail.com> wrote:

> On 25/10/18 07:51, Kevin Kenny wrote:
>
> On Wed, Oct 24, 2018 at 4:19 PM Allan Mustard  wrote:
>>
>>> Please do continue to comment and to offer suggestions, and to pose
>>> questions.
>>>
>>  This is pretty much based on gut feelings and may be partially or
>> completely wrong...
>>
>> I don't think "amenity" is a suitable tag for a consulate.  Amenities are
>> parks, or toilets, or similar.
>> "Should we go to the park or the consulate for a picnic today?"   "I'm
>> busting for a crap, where's the
>> nearest consulate?"  And I'm damned sure an embassy isn't an amenity (I'm
>> not even sure, in these
>> days of telecommunications, if it serves any purpose other than housing
>> spies, but if heads of state
>> do still use embassies for formal communication between governments
>> they're definitely not
>> amenities).
>>
>> I'm not going to worry too much about that particular tagging.
> 'amenity=*' is so overloaded in OSM (amenity=prison? Really?) that it can't
> possibly get any worse.
>
> :-)
>
> Since I already have to account for a great many different sorts of cases
> when processing 'amenity=*' for rendering or analysis, one more would be
> lost in the noise. I tend to think of OSM's 'amenity' as having a meaning
> not too far removed from 'thing'.
>
>
> I think of it as the miscellaneous folder of OSM, if it cannot fit
> anywhere else it goes in here.  The 'I give up' option.
>

Just had a thought :-)

Would this work under the landuse=government / civic_admin / public_admin
that was being discussed t'other day?

Maybe something like:

landuse=government

government=diplomatic (rendering with the current "embassy" flag)

diplomatic=embassy / consulate etc

services=visa; passport etc

Thanks

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

Re: [Tagging] mast / tower / communication_tower (again)

[Graeme Fitzpatrick]

On Thu, 25 Oct 2018 at 04:03, SelfishSeahorse 
wrote:

>
> Regarding the unclear man_made=communications_tower tag, nobody wrote
> that she or he is opposed to deprecating it. Do we still need a
> deprecation proposal? (Note that it wasn't introduced by a proposal.)
>

Just catching back up to OSM & this discussion after a week away.

Do we also need a RFC / vote to amend the wiki page, or can I just amend it
& clear up the bad reference photo's?

I'd be looking at combining the mentioned engineering definition with the
popular opinion expressed here to become:

A mast is a tall, slim structure supported by guys, usually with external
access only

A tower is a tall, slim free-standing structure, usually with internal
access. (Possible include from wiki: "Towers are specifically distinguished
from "buildings " in that they are
not built to be habitable but to serve other functions.")

Replacing man_made=communications_tower with man-made=tower;
tower=multi_purpose. Yes they're used for communication in that they have
antennae mounted on them, but are also usually tourist spots with lookouts
& so on, where normal TV towers etc aren't. I'd even suggest a automatic
edit to reclassify them - TagInfo says there are currently ~3700
communications_towers, whereas
https://en.wikipedia.org/wiki/List_of_tallest_towers suggest there should
probably be <100. As mentioned previously, there's currently ~200 of them
tagged in Australia. From checking them at random, it would appear there
should be 1!

Do we need to worry about height for rendering purposes? (which is what
this original discussion started from!) If so, would a simple break-down
into height >30 (m), 30-150, 150+ work?

Thanks

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

Re: [Tagging] Hot springs and Geysers

[Richard]

On Mon, Oct 22, 2018 at 08:42:40AM +0900, Joseph Eisenberg wrote:
> There are now over 500 hot springs mapped with natural=hot_spring. The tag
> was proposed way back in 2008 but the proposal was never approved. Wiki:
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dhot_spring
> Original proposal:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring
> 
> Some people have suggested tagging hot springs with natural=spring and a
> spring=hot subtag, but hot springs have a quite different geological origin
> and cultural significance. The wiki page for natural=spring has a link to
> hot spring:
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dspring
> 
> Geysers are also tagged natural=geyser. They could be considered a type of
> spring, but they are also similar to a fumarole or volcanic vent, and I
> would be quite surprised to see a geyser mapped as a “spring”
> Wiki:
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dgeyser
> 
> Thoughts on these tags? If natural=hot_springbkeeps climbing in use, we
> could start rendering it on the Openstreetmap-Carto style (“standard
> layer”) soon, if there is agreement on the tagging.

yep. I avoided a vote on the proposal because too many people were suggesting 
to use various combinations of natural=spring+temparature=XX and similar 
instead.

However Tag:natural=hot_spring has been created anyway, apparently is marked as 
"de facto" since 2015 and nobody complained since than so it would seem alright 
to file a ticket to OpenCarto asking to have it rendered.

Richard

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Warin]

On 25/10/18 07:51, Kevin Kenny wrote:



On Wed, Oct 24, 2018 at 4:19 PM Allan Mustard mailto:al...@mustard.net>> wrote:

Please do continue to comment and to offer suggestions, and
to pose questions.

 This is pretty much based on gut feelings and may be partially
or completely wrong...

I don't think "amenity" is a suitable tag for a consulate. 
Amenities are parks, or toilets, or similar.
"Should we go to the park or the consulate for a picnic today?"  
"I'm busting for a crap, where's the
nearest consulate?"  And I'm damned sure an embassy isn't an
amenity (I'm not even sure, in these
days of telecommunications, if it serves any purpose other than
housing spies, but if heads of state
do still use embassies for formal communication between
governments they're definitely not
amenities).


I'm not going to worry too much about that particular tagging.  
'amenity=*' is so overloaded in OSM (amenity=prison? Really?) that it 
can't possibly get any worse.

:-)
Since I already have to account for a great many different sorts of 
cases when processing 'amenity=*' for rendering or analysis, one more 
would be lost in the noise. I tend to think of OSM's 'amenity' as 
having a meaning not too far removed from 'thing'.


I think of it as the miscellaneous folder of OSM, if it cannot fit 
anywhere else it goes in here.  The 'I give up' option.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Graeme Fitzpatrick]

I've seen & wondered about the "gay" classification on places before.

When going on holidays & checking accommodation / travel guides for
options, you often see a number of hotels / motels which are listed as "gay
friendly". Does this mean only gays stay there / a majority of guests are
straight but gays are also welcome or what?

To me, with a young family, it's always meant that we're not staying at
that place!

Thanks

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Paul Allen]

On Wed, Oct 24, 2018 at 9:40 PM Warin <61sundow...@gmail.com> wrote:

>
> On 25/10/18 02:52, Paul Allen wrote:
>
> An alternative ... just use the diplomatic key alone.
>

I could live with that.  I think.  I have a vague feeling of unease about
it, for some reason I can't put
my finger on.  Maybe because it's an adjective and I think of keys as being
nouns.  Problem is,
diplomat=embassy would be silly.

I'm not happy with service:*=* acting as distinctions as service is used
elsewhere for other things.
It complicates editors as they have to do selective matching to figure out
which particular
service:* tags to offer up with a particular main tag.


Humm the 'sells' tag has the same problem.
>

That doesn't mean we should compound the error.  Each time something like
sells is used
the editor has to have special-case code to handle it properly.  Or it just
offers every possible sells=*
even when most are inappropriate in that context, which leads to errors and
confusion.

Free form entry is a reasonable way around this .. at least until some use
> has been made of it to see what is 'frequent' in use.
>

AKA "I wish we'd thought this through properly back in the beginning
instead of ending up with a mix of
incompatible tagging methods because people invent random stuff."  That's
how we ended up with
amenity=embassy...

-- 
Paul


___
> 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 - (consulate)

[Kevin Kenny]

>
> On Wed, Oct 24, 2018 at 4:19 PM Allan Mustard  wrote:
>
>> Please do continue to comment and to offer suggestions, and to pose
>> questions.
>>
>  This is pretty much based on gut feelings and may be partially or
> completely wrong...
>
> I don't think "amenity" is a suitable tag for a consulate.  Amenities are
> parks, or toilets, or similar.
> "Should we go to the park or the consulate for a picnic today?"   "I'm
> busting for a crap, where's the
> nearest consulate?"  And I'm damned sure an embassy isn't an amenity (I'm
> not even sure, in these
> days of telecommunications, if it serves any purpose other than housing
> spies, but if heads of state
> do still use embassies for formal communication between governments
> they're definitely not
> amenities).
>
> I'm not going to worry too much about that particular tagging.
'amenity=*' is so overloaded in OSM (amenity=prison? Really?) that it can't
possibly get any worse. Since I already have to account for a great many
different sorts of cases when processing 'amenity=*' for rendering or
analysis, one more would be lost in the noise. I tend to think of OSM's
'amenity' as having a meaning not too far removed from 'thing'.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Warin]

On 25/10/18 02:52, Paul Allen wrote:
On Wed, Oct 24, 2018 at 4:19 PM Allan Mustard > wrote:


Please do continue to comment and to offer suggestions, and to
pose questions.

 This is pretty much based on gut feelings and may be partially or 
completely wrong...


I don't think "amenity" is a suitable tag for a consulate.  Amenities 
are parks, or toilets, or similar.
"Should we go to the park or the consulate for a picnic today?"   "I'm 
busting for a crap, where's the
nearest consulate?"  And I'm damned sure an embassy isn't an amenity 
(I'm not even sure, in these
days of telecommunications, if it serves any purpose other than 
housing spies, but if heads of state
do still use embassies for formal communication between governments 
they're definitely not

amenities).

Embassies and consulates seem a slightly better fit in 
office=government, but still a square peg with

the corners filed down a little trying to fit into a round hole.


An alternative ... just use the diplomatic key alone.
If necessary diplomatic=yes could be used where the precise nature of 
the facility is unknown .. much like building=yes.




I'm not happy with service:*=* acting as distinctions as service is 
used elsewhere for other things.
It complicates editors as they have to do selective matching to figure 
out which particular

service:* tags to offer up with a particular main tag.


Humm the 'sells' tag has the same problem.
Free form entry is a reasonable way around this .. at least until some 
use has been made of it to see what is 'frequent' in use.




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

Re: [Tagging] Hot springs and geysers

[EthnicFood IsGreat]

Date: Mon, 22 Oct 2018 10:15:56 +1000
From: Graeme Fitzpatrick 
To: OSM Tag 
Subject: Re: [Tagging] Hot springs and Geysers

On Mon, 22 Oct 2018 at 09:44, Joseph Eisenberg 
wrote:

There are now over 500 hot springs mapped with natural=hot_spring. The tag
was proposed way back in 2008 but the proposal was never approved. Wiki:
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dhot_spring
Original proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring


Yep, sounds like a good idea



Some people have suggested tagging hot springs with natural=spring and a
spring=hot subtag, but hot springs have a quite different geological origin
and cultural significance. The wiki page for natural=spring has a link to
hot spring:
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dspring


Agree that hot spring & spring=hot are different


Geysers are also tagged natural=geyser. They could be considered a type of
spring, but they are also similar to a fumarole or volcanic vent, and I
would be quite surprised to see a geyser mapped as a “spring”
Wiki:
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dgeyser


Notice that they also suggested using hot spring for mud. I would think
that bubbling mud puddles would be a different thing again?


Thoughts on these tags? If natural=hot_springbkeeps climbing in use, we
could start rendering it on the Openstreetmap-Carto style (“standard
layer”) soon, if there is agreement on the tagging.


Thanks

Graeme




+1

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Steve Doerr]

On 24/10/2018 16:17, Allan Mustard wrote:

service:apostiles=yes· 



The Oxford English Dictionary recognizes two spellings, apostil and 
apostille, with the latter only being used in Oxford's more up-to-date 
dictionaries. Therefore, I would recommend



service=apostilles


--

Steve



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Rory McCann]

On 23/10/2018 23:53, Andy Mabbett wrote
>> "shop=books lgbtq=yes" is a LGBTQ book shop
>

Wouldn't that be "shop=books books=lgbtq"?


Good point.

On 24/10/2018 00:55, Martin Koppenhoefer wrote:

there may be lgbtq things, but there are also places which are
explicitly gay bars, i.e. for homosexual men. If you tag these as
lesbian queer trans ... it may not be right

Wouldn’t it be more consistent with what we already have, to add
lesbian, queer, trans and bi tags?


What kind of places are for gay (men) and not bi (men)? There's
an overlap (let's skip over the too prevalent biphobia in the LG
community). Lumping bi people of all gender into one category but
splitting gay (men) & lesbians seems odd. Often what as called "gay
bars" are open to all of the LGBTQ community. My proposal would allow
lgbtq:male=yes to cover cases you describe, right?

The existing tagging scheme prioritizes gay (men), which is subpar.


On 24/10/2018 10:27, Christoph Hormann wrote:

Based on what you wrote i have a bit of a problem seeing a
verifiable meaning of the tag you are contemplating here.  If there
is some sort of certification system for bars based on objective
criteria similar to hotel stars ratings that would be something that
can be tagged but a subjective assessment based on perceived
tolerance and friendliness or by statistics of the clientele seems
problematic.

Yes, "LGBTQ friendly" is subjective, but I don't mean that. "LGBTQ
bars" *do* exist. If you want a simple rule: Does the business refer
to itself as that? i.e. only map "out" gay bars, for security &
verifiability reasons.


On 24/10/2018 09:37, Frederik Ramm wrote:

usually "blah=yes" means that blah is available or blah is permitted,
not that the place is mostly/exclusively for blah. Conversely, in
your definition an "lgbtq=no" would then mean that the place is *not*
specifically an lgbtq place; many users could, however, misread
lgbtq=no (which would be a valid tag for the majority of places since
they don't specifically cater to lgbtq people) as "this place does
not admit lgbtq people" (which is probably/hopefully true only for a
very small number of places).

Good point.

One could say "OSM Tags are for machines, so consult the
docs", but I think tags should be readable to humans (one you learn to
speak OSM-tag-ese).


You don't want "lgbtq=only" since usually an lgbtq bar *will* admit

> straight people

Yes they will (plus some members of the LGBTQ community are straight, or
in relationship with straight people ). Wiki says diet:vegan=only
means "All *or almost all* products are vegan", so lgbtq=only is
consistent with that, but it seems too confusing, and doesn't read well,
so I think it's not the best.


Perhaps "lgbtq=designated"


That's close, *but* sounds like an official body has designed the place
as a LGBTQ venue, rather than someone choosing to run a business that
way. It could be the best contender.


--
Rory


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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Tue, 9 Oct 2018 at 16:07, Greg Troxel  wrote:
>
> The guy wires or not is made into the main thing here, but it's really a 
> detail.

Obviously, from a certain height, tall cylindrical structures like
masts need guy-wires for stabilisation. Otherwise, they need a larger
diameter or a conical shape. Thus, the presence of guy-wires is an
indicator for masts but not a requirement.

Imho, the current definition on the wiki according to which a tower
has internal access or platforms is practical and quite sensible.

Regarding the unclear man_made=communications_tower tag, nobody wrote
that she or he is opposed to deprecating it. Do we still need a
deprecation proposal? (Note that it wasn't introduced by a proposal.)

Regards
Markus

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

Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Jmapb]

On 10/24/2018 4:27 AM, Christoph Hormann wrote:




*When* to add a lgbtq=yes tag can be hard to know. In some places a
gay bar can be easily identified by a prominent rainbow flag. Some
cultures are less accepting, so bars might not be so blatant (I've
seen this in the EU). Using the common OSM rules of "local
knowledge", people within the local LGBTQ community are probably the
best place to make a final call.

Based on what you wrote i have a bit of a problem seeing a verifiable
meaning of the tag you are contemplating here.  If there is some sort
of certification system for bars based on objective criteria similar to
hotel stars ratings that would be something that can be tagged but a
subjective assessment based on perceived tolerance and friendliness or
by statistics of the clientele seems problematic.

I know many bars, restaurants, shops, and other businesses that fly a 
rainbow flag out of solidarity with the LGBTQ communities, but are not, 
best I can tell, gay establishments in any meaningful sense. Sometimes 
these flags appear when a business first opens, or sometimes they go up 
during Pride Week and simply remain indefinitely, like Halloween decor 
that somehow survives into the new year. I suppose you could interpret 
them as lgbtq=permissive (though frankly that sounds a little insulting) 
but not lgbtq=yes.


Obviously, though, gay (etc) businesses are a real thing! And it's a 
thing that many people would like to know about a place, whether they're 
seeking it or avoiding it. The venerability is tricky. As Justice Potter 
Stewart said, "I know it when I see it" -- but I can't imagine how a 
"certified gay" system would work.


The fact that homosexuality is criminalized or otherwise marginalized in 
many parts of the world adds to this problem. Some establishments might 
not want to draw attention to themselves in this way but would prefer to 
rely on word-of-mouth.


These are definitely tricky waters. My suggestion would be to only tag 
lgbtq=* if the establishment itself communicates this in an official way 
-- though written signs, fliers, official business website/social media 
account. Unfortunately this will exclude a large number of gay 
businesses, but I'd say that if they prefer a subtler approach it's not 
a mapper's job to out them.


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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Paul Allen]

On Wed, Oct 24, 2018 at 5:27 PM Allan Mustard  wrote:

I have no idea why amenity=embassy first came into existence.
>

The usual reasons.   Somebody needed to tag an embassy, couldn't find a
documented way of
doing it so used the first tag that came to mind.

There is another proposal to create amenity=diplomatic and then use the
> diplomatic=* tag to define more precisely what type of facility an object
> is.  I have added it to the proposal wiki, but assume you would not like
> it, either.
>

Not under amenity, no.  Maybe it works for other people, but my mental map
of what constitutes
an amenity doesn't include embassies and consulates.  Even though embassies
and consulates
both sometimes hold parties.

Paul, are you proposing office=diplomatic and diplomatic=[embassy, mission,
> nunciature, consulate, consulate_general, consular agency,
> honorary_consul], or something else?


Something along those lines.  I'm not sure office is a good fit either.  We
have amenity=doctors
and office=doctor but there are attempts to move those under healthcare,
which I think is a better
way of handling them.  I definitely don't like amenity here and office is
only slightly better.  A better
fit would be diplomatic_mission=consulate|embassy|nunciate|whatever but
underscores in keys
seem to be out of favour.  Is there another encompassing term?


> As for objection to the service=* tag, would a new consular:*=* tag be a
> better solution?  Just asking.  I'm not well versed in programing editors.
> It would be something like consular:immigrant_visas=yes,
> consular:nonimmigrant_visas=yes, consular:citizen_services=yes, etc.


Only if there is no need for an equivalent embassy: tag.  That is
everything that need be dealt with
for an embassy is listing which consular functions it also performs (if
any).  This assumes an
underlying model where an embassy can (but may not) do anything a consulate
can but all
embassies have the same non-consular functions.  Otherwise, if we had an
all-encompassing
term like diplomatic_mission=* we could then have
diplomatic_mission:citizen_services=yes.  Or
something like that.  I'm making this up as I go along. :)

As for whether embassies serve "any purpose other than housing spies," as a
> diplomat now for over 30 years, I can assure you that at least in the case
> of U.S. embassies, we diplomats do a lot more than that.


That's how it worked until recent times.  Now diplomacy-by-tweet seems to
be the norm in the US. :(

However, your experience does mean you have a good idea of what the tagging
scheme needs to
cover so it can be made coherent and possibly anticipate future needs.
It's always a pain to introduce
a new way of doing things and then find out a year down the line that it
can't handle something.

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

Well, at the moment the question as articulated in the wiki is whether
to split the existing amenity=embassy (which encompasses both embassies
and consulates) into amenity=embassy and amenity=consulate.  If in the
view of the OSM community amenity=consulate is inappropriate, then
logically so is amenity=embassy, and we need a new proposal to change
it.  I have no idea why amenity=embassy first came into existence. 
There is another proposal to create amenity=diplomatic and then use the
diplomatic=* tag to define more precisely what type of facility an
object is.  I have added it to the proposal wiki, but assume you would
not like it, either.

Paul, are you proposing office=diplomatic and diplomatic=[embassy,
mission, nunciature, consulate, consulate_general, consular agency,
honorary_consul], or something else?  I'll be happy to add your proposal
to the list of counterproposals on the wiki and promote discussion of it.

As for objection to the service=* tag, would a new consular:*=* tag be a
better solution?  Just asking.  I'm not well versed in programing
editors. It would be something like consular:immigrant_visas=yes,
consular:nonimmigrant_visas=yes, consular:citizen_services=yes, etc.

As for whether embassies serve "any purpose other than housing spies,"
as a diplomat now for over 30 years, I can assure you that at least in
the case of U.S. embassies, we diplomats do a lot more than that. 
Please take a look at the integrated country strategy of my embassy,
here: https://www.state.gov/documents/organization/285262.pdf for a
taste of what a small U.S. embassy does.  The larger U.S. embassies do
much more.  I cannot speak for the embassies of other nations.

On 10/24/2018 8:52 PM, Paul Allen wrote:
> On Wed, Oct 24, 2018 at 4:19 PM Allan Mustard  > wrote:
>
> Please do continue to comment and to offer suggestions, and to
> pose questions.
>
>  This is pretty much based on gut feelings and may be partially or
> completely wrong...
>
> I don't think "amenity" is a suitable tag for a consulate.  Amenities
> are parks, or toilets, or similar.
> "Should we go to the park or the consulate for a picnic today?"   "I'm
> busting for a crap, where's the
> nearest consulate?"  And I'm damned sure an embassy isn't an amenity
> (I'm not even sure, in these
> days of telecommunications, if it serves any purpose other than
> housing spies, but if heads of state
> do still use embassies for formal communication between governments
> they're definitely not
> amenities).
>
> Embassies and consulates seem a slightly better fit in
> office=government, but still a square peg with
> the corners filed down a little trying to fit into a round hole.
>
> I'm not happy with service:*=* acting as distinctions as service is
> used elsewhere for other things.
> It complicates editors as they have to do selective matching to figure
> out which particular
> service:* tags to offer up with a particular main tag.  It is also
> less easy to comprehend at a
> glance.  I'd say diplomatic=* is a better way to go because it is more
> obvious and easier for
> editors.
>
> I don't know what the answer is, all I can say is I'm not overly happy
> with what has been
> suggested so far.
>
> -- 
> Paul
>

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

Re: [Tagging] Another multipolygon question

[Adam Franco]

My pleasure, Dave! I'm glad to have helped even a little. :-)

Here's another short (2:25) video showing how I use the Relation Editor
window to sort and find disconnected segments:
https://youtu.be/87nRQHuatOE

Cheers!
Adam

On Wed, Oct 24, 2018 at 9:35 AM Dave Swarthout 
wrote:

> They say a picture is worth a thousand words and IMO that video says
> bushels about mapping relations. I was always a bit scared when fooling
> with them because as it turns out, their reputation is worse than the
> reality. The Reltoolbox is similar to the normal relation editor as Kevin
> points out but for me it makes the task ever so much faster. You can move
> along picking up pieces of whatever multipolygon you're constructing and it
> just magically adds them. I have one place where the same way is used for a
> place=island with its name, a NWR boundary, a wood multipolygon and a sand
> multipolygon. Freakin' awesome! I've learned more in the past day while
> mapping islands in the Kodiak Archipelago than in the past 5 years of
> working with multipolygons.
>
> Now all we need is a video tutorial showing how to analyze one during a
> debugging episode. Talk abut sorting, perhaps, an a walk through of a
> session where there is a "gap" in some relation that you cannot locate.
> What techniques and/or tools would one use in that case? And what about
> those little squiggles that appear at the end of each member's line in the
> relation editor. I know they indicate connectivity (a closed loop?) but
> what do you do if there is a problem, a "gap."??
>
> Anyway, thanks again to Adam. You've advanced my understanding immensely.
>
> Dave
>
> On Tue, Oct 23, 2018 at 10:39 PM Kevin Kenny 
> wrote:
>
>> On Mon, Oct 22, 2018 at 12:36 PM Adam Franco 
>> wrote:
>>
>>> Hi Dave, all,
>>>
>>> Based on this discussion I just recorded this short tutorial
>>>  of how I use JOSM and its Relation
>>> Toolbox plugin to to add adjoining land-cover areas as multipolygons with
>>> shared boundary ways to reduce duplication and overlapping ways.
>>>
>>
>> Thanks for recording that! Now I don't have to. :)
>>
>> Your workflow is essentially the same as mine, except that I use the
>> regular old relation editor to add and delete ways. Works well enough for
>> me, and I think it's only one or two clicks more than what you're doing. I
>> also make a lot of use of 'replace geometry' from utlilsplugin2, since a
>> lot of what I'm editing was born as imports and is being replaced with
>> updated data from the same sources. Yes, I'm very careful not to step on
>> the work of local mappers when I do it.
>>
>> Depending on what's going on in the field, I might have called that
>> hedgerow a tree_row or a hedge and used a linear feature to map it.
>> Similarly, at breaks in tree cover for things like power lines and
>> pipelines, I might use man_made=cutline. Speeds up the process a little bit
>> more. For what it's worth, I tend to restrict the 'cutline' tag to a
>> standard (in NY) four-rod right-of-way; if the cutting is larger than that,
>> it gets a polygon.
>>
>> Hopefully this will begin to show that for complex landcover, or
>> similarly complex admin boundaries, that multipolygons with shared ways are
>> actually quicker and easier to maintain than simple areas.  I know that
>> they're still controversial, even among experienced mappers, but for
>> something complicated like West Point
>> https://www.openstreetmap.org/relation/175474, with a whole bunch of
>> shared borders, rights-of-way cut out of it and what not, I'd be really
>> handicapped without shared ways.  I didn't get very far on the landcover
>> because I seldom map landcover other than in my own neighbourhood or when
>> fixing other people's mistakes.
>> ___
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Paul Allen]

On Wed, Oct 24, 2018 at 4:19 PM Allan Mustard  wrote:

> Please do continue to comment and to offer suggestions, and to pose
> questions.
>
 This is pretty much based on gut feelings and may be partially or
completely wrong...

I don't think "amenity" is a suitable tag for a consulate.  Amenities are
parks, or toilets, or similar.
"Should we go to the park or the consulate for a picnic today?"   "I'm
busting for a crap, where's the
nearest consulate?"  And I'm damned sure an embassy isn't an amenity (I'm
not even sure, in these
days of telecommunications, if it serves any purpose other than housing
spies, but if heads of state
do still use embassies for formal communication between governments they're
definitely not
amenities).

Embassies and consulates seem a slightly better fit in office=government,
but still a square peg with
the corners filed down a little trying to fit into a round hole.

I'm not happy with service:*=* acting as distinctions as service is used
elsewhere for other things.
It complicates editors as they have to do selective matching to figure out
which particular
service:* tags to offer up with a particular main tag.  It is also less
easy to comprehend at a
glance.  I'd say diplomatic=* is a better way to go because it is more
obvious and easier for
editors.

I don't know what the answer is, all I can say is I'm not overly happy with
what has been
suggested so far.

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

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

I have updated both the proposal page and the discussion page (with
e-mailed comments) of


  Proposed features/Consulate

https://wiki.openstreetmap.org/wiki/Proposed_features/Consulate

Please do continue to comment and to offer suggestions, and to pose
questions.  I am incorporating suggestions and one counterproposal into
the wiki page and look forward to reactions to them.  Many thanks to the
fellow mappers who have responded to this RFC!


Proposal

It is proposed to establish formally the amenity
=consulate

 tag,
which is already in use sporadically, in order to differentiate
consulates from embassies.

*Suggestions from Commenters*

  * To include an additional tag (e.g., service
=*) indicating
types of consular services (citizen services, non-immigrant visas,
immigrant visas, notarials, apostiles) offered. This tag could also
be used for embassies offering consular services.
  * To specify in such a tag types of services, e.g.,

service:apostiles=yes·   
service:immigrant_visas=yes·   
service:non-immigrant_visas=yes
service:notarials=yes

 This approach could be applied to avoid multiple values for the
same key, and are required because keys must be unique in OSM.

  * To use the tag diplomatic
=* to specify
the type of consulate (consulate general, consulate, consular
agency, honorary consul).

*Counterproposal*

Another user has counter-proposed (see the discussion page
):

I would opt for; depreciating amenity=embassy as they are used for
embassies, consulates etc so you don't know what they are (unless it
has a detailed sub tag) introducing amenity=diplomatic and use the
sub tag diplomatic=* to detail what it is - embassy/consulate/*



*
*



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

Re: [Tagging] Another multipolygon question

[EthnicFood IsGreat]

From: Kevin Kenny 
To: David Swarthout ,  "Tag discussion,
strategy and related tools" , bkil
, Mateusz Konieczny 
Subject: Re: [Tagging] Another multipolygon question

On Sun, Oct 21, 2018 at 7:34 AM bkil  wrote:


It seems many would find a short video tutorial depicting these steps very
handy. Would you mind sharing on Bitchute or on some other video hosting
site?


On Sun, Oct 21, 2018 at 9:00 AM Dave Swarthout 
wrote:


I was wishing that someone would write a short tutorial about relations,
the various concepts about tagging them, and problem solving when something
goes wrong with one. I have been unable to understand with any degree of
certainty how and why we create them, which is the reason I started this
thread and contributed to the other one about tagging groups of lakes. The
Wiki is helpful but leaves out a lot of details. A tutorial, video or
otherwise, would be extremely helpful.


On Sun, Oct 21, 2018 at 1:24 PM Mateusz Konieczny 
wrote:


Maybe improving wiki would be a good idea as the first [step].


I find that video tutorials don't often fit my learning style, so I don't
often use them and have never made one. Moreover, I'm an old man and
somewhat set in my ways. Nevertheless, they seem to be demanded, and if
nobody else steps forward, perhaps it will be possible to teach this old
dog that new trick.  I'd be willing to take a whack at a written tutorial,
but can't promise any particular time frame. Just at the moment, I'm
chronically busy.

[...]



If I were to take on this task (again, no guarantees about the time
frame), I could certainly address this issue with JOSM (and possibly
Meerkartor). I surely do not know Potlatch2, iD, or any other tool well
enough to manage anything but the simplest of relations in it, nor do I see
obvious things in the UI that would do what I need. It may well be
limitations of the tools, rather than limitations of knowledge and
training, that make people assert that relations are unmaintainable or that
drawing complex boundaries twice is easier than creating multipolygons with
shared ways. That last statement, however, may be nothing but a base libel
based on ignorance. In that case, I'm more than willing to be enlighened.
It would occasionally be handy to be able to make a quick change to a
multipolygon when I'm away from a machine that has my preferred tools and
simply working in a browser.


I would welcome a good reference on creating and editing relations. I 
understand the theory, but I've always wished for some good explanations 
of manipulating them in JOSM.


Mark

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

Re: [Tagging] Another multipolygon question

[Dave Swarthout]

They say a picture is worth a thousand words and IMO that video says
bushels about mapping relations. I was always a bit scared when fooling
with them because as it turns out, their reputation is worse than the
reality. The Reltoolbox is similar to the normal relation editor as Kevin
points out but for me it makes the task ever so much faster. You can move
along picking up pieces of whatever multipolygon you're constructing and it
just magically adds them. I have one place where the same way is used for a
place=island with its name, a NWR boundary, a wood multipolygon and a sand
multipolygon. Freakin' awesome! I've learned more in the past day while
mapping islands in the Kodiak Archipelago than in the past 5 years of
working with multipolygons.

Now all we need is a video tutorial showing how to analyze one during a
debugging episode. Talk abut sorting, perhaps, an a walk through of a
session where there is a "gap" in some relation that you cannot locate.
What techniques and/or tools would one use in that case? And what about
those little squiggles that appear at the end of each member's line in the
relation editor. I know they indicate connectivity (a closed loop?) but
what do you do if there is a problem, a "gap."??

Anyway, thanks again to Adam. You've advanced my understanding immensely.

Dave

On Tue, Oct 23, 2018 at 10:39 PM Kevin Kenny 
wrote:

> On Mon, Oct 22, 2018 at 12:36 PM Adam Franco  wrote:
>
>> Hi Dave, all,
>>
>> Based on this discussion I just recorded this short tutorial
>>  of how I use JOSM and its Relation
>> Toolbox plugin to to add adjoining land-cover areas as multipolygons with
>> shared boundary ways to reduce duplication and overlapping ways.
>>
>
> Thanks for recording that! Now I don't have to. :)
>
> Your workflow is essentially the same as mine, except that I use the
> regular old relation editor to add and delete ways. Works well enough for
> me, and I think it's only one or two clicks more than what you're doing. I
> also make a lot of use of 'replace geometry' from utlilsplugin2, since a
> lot of what I'm editing was born as imports and is being replaced with
> updated data from the same sources. Yes, I'm very careful not to step on
> the work of local mappers when I do it.
>
> Depending on what's going on in the field, I might have called that
> hedgerow a tree_row or a hedge and used a linear feature to map it.
> Similarly, at breaks in tree cover for things like power lines and
> pipelines, I might use man_made=cutline. Speeds up the process a little bit
> more. For what it's worth, I tend to restrict the 'cutline' tag to a
> standard (in NY) four-rod right-of-way; if the cutting is larger than that,
> it gets a polygon.
>
> Hopefully this will begin to show that for complex landcover, or similarly
> complex admin boundaries, that multipolygons with shared ways are actually
> quicker and easier to maintain than simple areas.  I know that they're
> still controversial, even among experienced mappers, but for something
> complicated like West Point https://www.openstreetmap.org/relation/175474,
> with a whole bunch of shared borders, rights-of-way cut out of it and what
> not, I'd be really handicapped without shared ways.  I didn't get very far
> on the landcover because I seldom map landcover other than in my own
> neighbourhood or when fixing other people's mistakes.
> ___
> 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] Feature Proposal - RFC - Research station

[Warin]

I think there are more research stations that are not so remote, not 
manned 24/7 nor have residences on site.


Some links to a diverse range of possible 'research stations'
https://www.csiro.au/en/Research/OandA/Areas/Assessing-our-climate/Greenhouse-gas-data
https://www.csiro.au/en/Research/AF/Areas/Boorowa-Agricultural-Research-Station
https://www.csiro.au/en/Research/Facilities/AAHL
https://australianmuseum.net.au/lizard-island-research-station


On 24/10/18 20:34, Jonathon Rossi wrote:
Here in Queensland Australia, our Department of Agriculture and 
Fisheries run many research stations 
 
obviously doing primary industries based research. Some universities 
do perform research there, but they are government owned and run stations.


I recently started mapping a local one 
 which is in a urban 
area. Wikipedia's definition of a research station isn't so strong 
about them being located in a remote area.


The local one I linked to above isn't self sufficient and people don't 
live there, however they recently installed a fancy research solar 
array. From your definition it doesn't sound like this one would 
qualify, as many others on the DAF list probably don't either, but I 
would think the chosen tag name applies.


Is your proposal that this tag applies to my example?

Thanks

On Wed, Oct 24, 2018 at 6:20 PM Bren Barnes > wrote:


https://wiki.openstreetmap.org/wiki/Proposed_features/Research_station

A *research station* is an amenity that is built for the purpose
of conducting scientific research. Research stations are often
located in remote areas of the world, such as in the polar regions
or oceans. Due to their remote nature they are usually
self-sufficient campuses, generating their power requirements from
non-grid sources and having food supplies for long seasons. The
stations are staffed by both research scientists and operational
staff who live and work on base 24/7


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



--
Jono


___
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 - (consulate)

[Warin]

Very happy to have left it alone!

I'll wait for awhile before I tag it.
At present it looks like it might get diplomatic=mission


On 24/10/18 20:08, Allan Mustard wrote:
Nuncios are specifically named in the Vienna Convention on Diplomatic 
Relations, as are envoys, ministers, and chargés d’affaires:


*Article 14*
1.Heads of mission are divided into three classes, namely:
(a) That of ambassadors or nuncios accredited to Heads of State, and 
other heads of mission of

equivalent rank;
(b) That of envoys, ministers and internuncios accredited to Heads of 
State;
(c) That of chargés d’affaires accredited to Ministers for Foreign 
Affairs.


> Tue, 23 Oct 2018 20:36:02 -0400 Kevin Kenny > wrote:


> The Holy See is sovereign, so its nunciatures are embassies by 
another name.


>> On Tue, Oct 23, 2018 at 8:20 PM Warin <61sundow...@gmail.com 
> wrote:


>> Umm .. here is some sort of exception.
>>
>> "Apostolic Nunciature of The Holy See" ... :-)
>>
>> Ok .. what is it (in OSM terms)? Presently in the data base as
>> amenity=embassy


___
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 - (consulate)

[Warin]

On 24/10/18 20:50, Martin Koppenhoefer wrote:



Am Mi., 24. Okt. 2018 um 03:48 Uhr schrieb Allan Mustard 
mailto:al...@mustard.net>>:


One of the commenters has suggested an additional tag indicating
what services a consulate or embassy provides, and that is one
option.  Not all consulates or consular sections of embassies
offer all visa types, for example.  The existent service=* tag
could possibly be used.  For example, one could add to either a
consulate or an embassy the tag service=[citizen services;
notarials; apostiles; immigrant visas; non-immigrant visas]. 
Thoughts?


the service tag is already used for several different purposes (e.g. 
subtype of service road, subtype of service rail), which creates some 
inconvenience for data consumers (it is not necessarily a big problem, 
but some people have denounced this in the past) and as the services 
offered by a consulate will likely be more than one, I would suggest 
using a scheme like we use for payment or available fuels, i.e. a 
property list of yes/no (no is usually omitted), see here for 
reference: https://wiki.openstreetmap.org/wiki/Key:payment


For consulates, using the examples you gave, this would translate to:
service:notarials=yes
service:apostiles=yes
service:immigrant_visas=yes
service:non-immigrant_visas=yes
etc.

Or (if there are only two types of visas), you could also combine the 
latter two to
service:visas=immigrant / non-immigrant / both / yes (if you don't 
know which types) / no (no visas at all)


These headstands are applied to avoid multiple values for the same 
key, and are required because keys must be unique in OSM.


You can add these suggested properties to your proposal, but you could 
also put them in another proposal (if you believe there is support for 
amenity=consulate but the tags about offered services could be disputed).


As these services are also available at some other 'embassies' they 
should get there own proposal so they can be used in things like 
'consulate_general', 'mission' etc.


For visas I'd go simple .. service:via=yes/no/*  There will be multiple 
types for different countries .. sorting through them will be too much 
for most, yes and no will probably be the most popular and useful.




___
As a slightly offtopic hint, by looking at the proposal page 
discussion, I got the impression you are using the digest mode for 
emails, which seems convenient at first (because you don't get your 
email account crammed with a plethora of mails), but the convenience 
is traded off for making it much harder to reply to the mails (you 
must adjust the subject every time and cannot reply to individual 
mails). Just in case you would want to change this, it can be set 
here: https://lists.openstreetmap.org/listinfo/tagging "Would you like 
to receive list mail batched in a daily digest?".


It can be handy to set up your mail client to separate out the various 
things into folders - you can have one for the tagging group, one for 
general osm stuff etc.



Still think best to have all these embassies/consulates/etc under one 
tag - the renders can then use the same symbol for all of them .. like 
they did for shops until they got inventive. The same will happen here, 
eventually consulates will be separated from embassies.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Research station

[Martin Koppenhoefer]

Am Mi., 24. Okt. 2018 um 10:20 Uhr schrieb Bren Barnes :

> https://wiki.openstreetmap.org/wiki/Proposed_features/Research_station
>
> A *research station* is an amenity that is built for the purpose of
> conducting scientific research. Research stations are often located in
> remote areas of the world, such as in the polar regions or oceans. Due to
> their remote nature they are usually self-sufficient campuses, generating
> their power requirements from non-grid sources and having food supplies for
> long seasons. The stations are staffed by both research scientists and
> operational staff who live and work on base 24/7
>



I would not require it is "built for the purpose", IMHO it is sufficien it
is "used for the purpose". I am also not sure whether people will have to
live there, and whether this has to be"24/7", this might be often the case,
but it isn't necessarily a requirement, is it?

I would reduce the definition to the absolute minimum, and put the prose
into a more verbose explanation section. Words like "usually" imply that
these aren't strict requirements (but can be indices/hints).

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

Am Mi., 24. Okt. 2018 um 03:48 Uhr schrieb Allan Mustard :

> One of the commenters has suggested an additional tag indicating what
> services a consulate or embassy provides, and that is one option.  Not all
> consulates or consular sections of embassies offer all visa types, for
> example.  The existent service=* tag could possibly be used.  For example,
> one could add to either a consulate or an embassy the tag service=[citizen
> services; notarials; apostiles; immigrant visas; non-immigrant visas].
> Thoughts?
>

the service tag is already used for several different purposes (e.g.
subtype of service road, subtype of service rail), which creates some
inconvenience for data consumers (it is not necessarily a big problem, but
some people have denounced this in the past) and as the services offered by
a consulate will likely be more than one, I would suggest using a scheme
like we use for payment or available fuels, i.e. a property list of yes/no
(no is usually omitted), see here for reference:
https://wiki.openstreetmap.org/wiki/Key:payment

For consulates, using the examples you gave, this would translate to:
service:notarials=yes
service:apostiles=yes
service:immigrant_visas=yes
service:non-immigrant_visas=yes
etc.

Or (if there are only two types of visas), you could also combine the
latter two to
service:visas=immigrant / non-immigrant / both / yes (if you don't know
which types) / no (no visas at all)

These headstands are applied to avoid multiple values for the same key, and
are required because keys must be unique in OSM.

You can add these suggested properties to your proposal, but you could also
put them in another proposal (if you believe there is support for
amenity=consulate but the tags about offered services could be disputed).

___
As a slightly offtopic hint, by looking at the proposal page discussion, I
got the impression you are using the digest mode for emails, which seems
convenient at first (because you don't get your email account crammed with
a plethora of mails), but the convenience is traded off for making it much
harder to reply to the mails (you must adjust the subject every time and
cannot reply to individual mails). Just in case you would want to change
this, it can be set here: https://lists.openstreetmap.org/listinfo/tagging
"Would you like to receive list mail batched in a daily digest?".


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

Re: [Tagging] Feature Proposal - RFC - Research station

[Jonathon Rossi]

Here in Queensland Australia, our Department of Agriculture and Fisheries
run many research stations

obviously doing primary industries based research. Some universities do
perform research there, but they are government owned and run stations.

I recently started mapping a local one
 which is in a urban area.
Wikipedia's definition of a research station isn't so strong about them
being located in a remote area.

The local one I linked to above isn't self sufficient and people don't live
there, however they recently installed a fancy research solar array. From
your definition it doesn't sound like this one would qualify, as many
others on the DAF list probably don't either, but I would think the chosen
tag name applies.

Is your proposal that this tag applies to my example?

Thanks

On Wed, Oct 24, 2018 at 6:20 PM Bren Barnes  wrote:

> https://wiki.openstreetmap.org/wiki/Proposed_features/Research_station
>
> A *research station* is an amenity that is built for the purpose of
> conducting scientific research. Research stations are often located in
> remote areas of the world, such as in the polar regions or oceans. Due to
> their remote nature they are usually self-sufficient campuses, generating
> their power requirements from non-grid sources and having food supplies for
> long seasons. The stations are staffed by both research scientists and
> operational staff who live and work on base 24/7
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

[Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

Nuncios are specifically named in the Vienna Convention on Diplomatic
Relations, as are envoys, ministers, and chargés d’affaires:

*Article 14*
1.Heads of mission are divided into three classes, namely:
(a) That of ambassadors or nuncios accredited to Heads of State, and other
heads of mission of
equivalent rank;
(b) That of envoys, ministers and internuncios accredited to Heads of State;
(c) That of chargés d’affaires accredited to Ministers for Foreign Affairs.

> Tue, 23 Oct 2018 20:36:02 -0400 Kevin Kenny 
wrote:

> The Holy See is sovereign, so its nunciatures are embassies by another
name.

>> On Tue, Oct 23, 2018 at 8:20 PM Warin <61sundow...@gmail.com> wrote:

>> Umm .. here is some sort of exception.
>>
>> "Apostolic Nunciature of The Holy See" ... :-)
>>
>> Ok .. what is it (in OSM terms)? Presently in the data base as
>> amenity=embassy
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Research station

[Christoph Hormann]

On Wednesday 24 October 2018, Bren Barnes wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Research_statio
>n

It is not quite clear what criteria qualify a place as a research 
station based on your proposal.  You might in particular want to 
consider the distinction from things like military outposts, park 
ranger stations in nature reserves, weather stations and similar.  In 
the Antarctic the situation is mostly clear due to the legal background 
but elsewhere many such stations are multi-purpose.

It is also not clear if this is meant as a supplemental tag to populated 
place tags or if as a replacement for those.  As a supplemental tag it 
seems fine provided there are clear criteria, as a main tag given the 
wide range of research stations that exist it would seem a step back 
from existing populated place tagging.

And like with populated places since in most cases research stations 
have a well defined center but not a well defined outline it makes much 
more sense to map them with a node than with a polygon.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Christoph Hormann]

On Tuesday 23 October 2018, Rory McCann wrote:
> [...]
>
> *When* to add a lgbtq=yes tag can be hard to know. In some places a
> gay bar can be easily identified by a prominent rainbow flag. Some
> cultures are less accepting, so bars might not be so blatant (I've
> seen this in the EU). Using the common OSM rules of "local
> knowledge", people within the local LGBTQ community are probably the
> best place to make a final call.

Based on what you wrote i have a bit of a problem seeing a verifiable 
meaning of the tag you are contemplating here.  If there is some sort 
of certification system for bars based on objective criteria similar to 
hotel stars ratings that would be something that can be tagged but a 
subjective assessment based on perceived tolerance and friendliness or 
by statistics of the clientele seems problematic.

What could make sense in countries with no general anti-discrimination 
laws w.r.t. gender identity and sexual orientation is lgbtq=no for 
establishments that specifically don't allow lgbtq people.  That would 
essentially be an access restriction.

-- 
Christoph Hormann
http://www.imagico.de/

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

[Tagging] Feature Proposal - RFC - Research station

[Bren Barnes]

https://wiki.openstreetmap.org/wiki/Proposed_features/Research_station

A *research station* is an amenity that is built for the purpose of
conducting scientific research. Research stations are often located in
remote areas of the world, such as in the polar regions or oceans. Due to
their remote nature they are usually self-sufficient campuses, generating
their power requirements from non-grid sources and having food supplies for
long seasons. The stations are staffed by both research scientists and
operational staff who live and work on base 24/7
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

[Frederik Ramm]

Hi,

On 23.10.2018 20:27, Rory McCann wrote:
> So to start off, I'm suggest a simple "lgbtq=yes" tag to
> mean "this thing is a LGBTQ thing". 

Bit difficult perhaps since usually "blah=yes" means that blah is
available or blah is permitted, not that the place is mostly/exclusively
for blah.

(e.g. smoking=yes, bus=yes, vegan=yes)

Conversely, in your definition an "lgbtq=no" would then mean that the
place is *not* specifically an lgbtq place; many users could, however,
misread lgbtq=no (which would be a valid tag for the majority of places
since they don't specifically cater to lgbtq people) as "this place does
not admit lgbtq people" (which is probably/hopefully true only for a
very small number of places).

Sadly I do not have a good suggestion. You don't want "lgbtq=only" since
usually an lgbtq bar *will* admit straight people (unless they're a hen
party maybe). You'd need something like "lgbtq=mainly" - which would
still not be exactly what you were looking for since it talks about who
goes there in practice, not whom the place tries to attract. Perhaps
"lgbtq=designated" combined with "straight=yes" ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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