date:20190414

Currently place=locality is main in the database from imports, and it
is also used as a way to tag a feature which is not currently rendered
by most map renders so that the name will show.

Since place=locality was originally defined as "a named place that has
no population" it's easy to see how this (mis)use came about.

There are certainly places that really should be tagged place=locality.

The wiki mentions places that used to have a population, but are not
longer inhabited; eg "ghost towns" and railway junctions in the USA.
This features are often still shown on other maps, and may still have
a sign that shows the location, but even if they are only know by
local knowledge they may be useful for orientation.

For example, the locations of old mining camps by the river were still
used by fire fighters and police to specify locations of incidents in
my home area in rural California.

See https://wiki.openstreetmap.org/wiki/Tag:place=locality

What we need is a way to distinguish the correctly-tagged features and
those that are double-tagging for rendering. I would suggest that a
subtag such as "locality=*" could be useful.

https://taginfo.openstreetmap.org/keys/locality#values

This tag is already used 65,000 times, but actually on boundaries; it
was used for an import in Ireland with the values locality=townland
and locality=subtownland. (These seem to be incorrect usages, because
townlands seem to be populated places)

Besides the import, it's been used 26 times with locality=junction
(which could also be tagged railway=junction
https://wiki.openstreetmap.org/wiki/Tag:railway%3Djunction)? The other
values look incorrect; they are all populated places, or backwards
(locality=place).

So I think the key "locality=*" could be used to specify the type of
locality. This would allow database users to decide which localities
to render, out of the 1.3 million

The most important value would be one for a locality that is a former
populated place but no longer has a population.

Ideas for the value?

locality=ghost_town seems too American

locality=formerly_inhabited could work but is rather wordy

locality=abandoned_farm or =abandoned_hamlet might work?

Are there other types of valid localities which cannot be better
described with a different tag, other than former inhabited places?

-Joseph

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

Re: [Tagging] Requiring area=yes with barrier=wall, barrier=hedge and other usually linear features when mapped as an area`1

Gates can be mapped as nodes, so the fence or hedge or wall can be
mapped as a single way that goes around the field, and the gates or
stiles as nodes of that way.

I agree with everyone who says that it is best practice to map a
"barrier=hedge" as separate feature from a "landuse=meadow", but in
reality many mappers like to use the same way for both features.

Perhaps some of them think of it as a sub-tag like "fenced=yes" - it
isn't always clear if a tag is a separate feature or a characteristic
of another feature.

But at any rate, we would like to avoid confusing mappers with the
rendering result at Openstreetmap-Carto. These are the 2 options for
how to deal with closed ways that are tagged with another feature.

1) As now, keep rendering a closed way tagged as "barrier=hedge" and
"landuse=*" or "natural=*" as a hedge area, with dark green fill color
over the whole field. Sometimes this gives mappers a hint to change
the rendering, but this combination is still very common in the
database, and the rendering is clearly not what the mapper intended.

2) Render the hedge fill color only for closed ways mapped with
"barrier=hedge" AND "area=yes". This is the recommended way to map a
hedge (or most other features that are usually linear) as an area.

So in case of option 2,
- a closed way that was tagged "barrier=hedge" only will be rendered as a line.
- a closed way tagged as "barrier=hedge" AND "area=yes" will be
rendered with a green fill for the whole area.
- a closed way tagged as "tourism=camp_site" and "barrier=hedge" will
render with a hedge line around the outside, but the campsite color
fill on the inside.
- a closed way (mis-)tagged as "landuse=meadow" and "barrier=hedge"
"AND "area=yes" will render with the green hedge fill for the whole
area, because this is a tagging mistake.

My question to everyone on this forum: does option 2 makes sense to
you as a mapper? Is it less confusing that the current situation
(option 1)

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

Re: [Tagging] airport check in counters


On 15/04/19 06:35, Martin Koppenhoefer wrote:


sent from a phone


On 13. Apr 2019, at 15:21, bkil  wrote:

* Check-in counters: yes! Also include their count and whether there
are any restrictions between the different counters (with/without
bags, online only, etc).


I am also supporting the idea of specific proposed tags for airport checkin 
counters, ref would probably be an important property. Not sure how often the 
airlines change counters, but probably not that often.


The airline may change counters from time to time(not often) but the ref would 
not change .. well not here as they are labelled A, B, C etc... in sequence.


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

Re: [Tagging] Requiring area=yes with barrier=wall, barrier=hedge and other usually linear features when mapped as an area`1


A barrier on a park will have some means of getting in!!!

So the barrier will not be continuous - having gate/s or gaps etc.

The park boundary would then consist of the way that is the fence/barrier and 
other ways (possibly a gate etc) and that then meets the definition for a 
multipolygon relation.



On 14/04/19 16:49, Martin Koppenhoefer wrote:


sent from a phone


On 14. Apr 2019, at 08:37, Shawn K. Quinn  wrote:

This makes even less sense and is even clumsier, especially for those
using iD if memory serves correctly.


I did not experience problems with id in such cases, but I also would not let 
the mapping concepts be lead by a single editing software. Editors can always 
be updated if they cannot cope with certain concepts, while there is no easy 
fix for ambiguous map data.



Single-member multipolygons are
also a clear misuse of the multipolygon relation; the prefix "multi"
means more than one.


it is not a misuse, the minimum requirements for multipolygon members is one 
outer way, at most it is an unfortunate name for the kind of relation.




If, for some reason, the fence or the park boundary
differ, I can see making one or both a multipolygon, but if they are the
same then they should be tagged on the same way (at least as I see it).


If you tag them “on the same way” you state that they are the same thing and 
that all tags apply to it contemporaneously. I would say they could be mapped 
with the same way delimiting them (but as distinct objects). The fence is the 
boundary of the park, there is some connection between the two, but they are 
not the same thing.

Cheers, Martin
___
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] tags for a live stock sale yard


In Australia commercial livestock (sheep, cattle) are sold through these 
livestock markets.

They may be transported for several days to get to the market, rested there 
before sale to recover from their trip.

As such the market can be large with feeding etc.

Once sold they are then transported again, possibly overseas.

https://www.abc.net.au/cm/rimage/10839250-3x2-large.jpg?v=2

https://www.abc.net.au/cm/rimage/10839176-3x2-large.jpg?v=2

I do not see them as 'shops'... in the typical physical sense.


On 14/04/19 17:51, bkil wrote:

In Hungary, market auctions do not exist. Instead you go to the
livestock market, purchase some chicks, then go to the producers'
market to grab some grain for them. Many markets are open to a little
haggling, though.

We de have online auctions and also some official ones related to
liquidation or taxation for example, but vehicles and machinery are
much more common to pop up on these than livestock, and they are not a
permanent feature anyway.

What ratio of livestock purchases are executed through auctions in the
USA? If not a majority, I'd recommend we stay with amenity=marketplace
and introduce a new tag for auction=yes (or specify the kind of
auction here). This is also assuming that livestock markets commonly
have the word "market" in their name. Can you always take home the
livestock you have purchased, or are these organized at distant
auction houses, having the goods transported later on to the winner?
Maybe we need to come up with a tag for this as well (delivery=only?).

If livestock auctions are the norm there, we may introduce a new tag
for this, though shop=auction + auction=livestock isn't that far off
in this case. What else is commonly auctioned there? Is it common for
agricultural supplies as well, like pesticide, fertilizer, seed, tools
or machinery?

https://en.wikipedia.org/wiki/Auction#Common_uses

On Sun, Apr 14, 2019 at 5:35 AM Joseph Eisenberg
 wrote:

I saw that proposal, but it seems to be discussing auction houses that
sell goods from estates, or collectibles, rather than a commodity
auction.

For a livestock auction, I would suggest using amenity=auction or
amenity=auction_house with auction=livestock.

But there do seem to be some marketplaces where livestock is sold via
general negotiation in Asia, eg. here in Indonesia we had a
marketplace called "Pasar Sapi" or "Cattle Market" which mainly sold
fruits and vegetables, but occasionally had cattle or goats for sale.
And the marketplace in my town here in New Guinea always has pigs and
chickens for sale (live), price negotiable but not auctioned.

If there are cases like this, amenity=marketplace +
marketplace=livestock could work (assuming it is primarily a livestock
market).

___
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] Waterway tributary role

Le 13.04.19 à 16:25, Florian Lohoff a écrit :
> On Sat, Apr 13, 2019 at 11:48:28AM +, marc marc wrote:
>> It's a little more than a personal note.
>>
>> I feel like I remember several discussions about this on talk-fr,
>> but I didn't look for any other links that had been posted.
>> I also don't remember if the page as updated after a thread
>> or not. it's a several years old :)
>>
>> destination is the opposite, no ?
>> if river A go into river B  :
>> in relation A : destination=B
>> in relation B : A with rôle tributary
> 
> I dont think this is necessary to make it that complicated.

I also do not like the tributary role.
because it can be deduced from the geometry of the way waterway.
I only answered the one who was looking for the doc of this tag
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Requiring area=yes with barrier=wall, barrier=hedge and other usually linear features when mapped as an area`1

Le 13.04.19 à 02:37, Joseph Eisenberg a écrit :
> Will validators in JOSM and other editors be able to point out a
> problem if a closed way is tagged with both "area=yes",
> "barrier=hedge" and "landuse=meadow"?

a area with a fence as an attribute of this area
is better described with fenced=yes
maybe we need a value for fenced in with a hedge
like fenced=hedge
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?

The same plastic barriers are used in Australia. While they may be
capable of retaining water .. I am yet to see one with water in it ...
probably too much trouble and we do have a lack of water too.
Where weight is required the concrete ones look to be used, possibly
easier and quicker to do that than the plastic ones then fill with
water, then drain etc.

On 15/04/19 03:53, Tony Shield wrote:

I was unfamiliar with the term jersey_barrier - but then there are
other barriers I was unfamiliar with. I'm happy to use it - I'm
English in England - as there are no dual-uses I am aware of.

https://www.mapillary.com/map/im/Wp18aKeOYiiFWti5nTqorQ in my opinion
shows some very posh jersey-barriers outside the Palace of Westminster.

I've noticed that many of the plastic barriers used on UK motorways
are filled with water - presumably as they can be located by hand then
filled from a mobile water tank - no crane required.

Tony

On 14/04/2019 10:56, Joseph Eisenberg wrote:

Thanks, Martin! I couldn’t find that link.

I wish the OSM wiki search feature had a better algorithm.

Can anyone from England confirm that this tag is intelligible in your
dialect? Are there other names for these that should be mentioned on
the page?

Joseph

On Sun, Apr 14, 2019 at 4:57 PM Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

sent from a phone

On 14. Apr 2019, at 04:43, Joseph Eisenberg
mailto:joseph.eisenb...@gmail.com>>
wrote:

I want to know so that the wiki page can be edited to show the
correct status: approved vs in use.

I went back into the archives and it seems it was included and
approved in my more barrier types proposal 2011:

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/New_barrier_types=684703
Not sure where the tag name for jersey barriers came from,
probably from tagging ml discussion (it is not a word I have in
my vocabulary)

Cheers, Martin

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

Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch

Le 14.04.19 à 21:35, Martin Koppenhoefer a écrit :
>> On 14. Apr 2019, at 18:36, marc marc  wrote:

>> one of the problems is that each key has its own logic
>> a part of a amenity=building is building:part=*
>> a part of the amenity=parking is amenity=parking_space
>> a part of a leisure=sports_centre is leisure=pitch unless it is water
>> then it is leisure=swimming_pool
>>
>> new keys deserve to have some consistency.
>> e.g. :part if the part does not have a name in itself

> I don’t follow this, a part of a park is a park:part (bench, tree etc)? A 
> part of a city? 
> This would be ridiculous or ambiguous or arbitrary most of the time, but for 
> buildings it works well, also if the part has its own name.

I was obviously talking about the case where the parts have the same 
characteristics as the whole. an amenity=parking capacity=1 have the 
same characteristic as a parking_space capacity=1.
I wasn't talking about dividing a park into lots of :part
for every tree, every bench, every blade of grass.
a bench is not part of a park, it is an equipment found in some of them.

if you cut a leisure=park in 2 to say that one part has a different tag 
from the other (for example, a part closed at night), it would be a bit 
silly to invent a new term to say "part of a park" or to have to claim 
that there are 2 parks.

there was the same kind of discussion also with the relationships 
grouping several natural=wood and whose relationship is used to put
the tag name

I find also strange it's perfect to have parking_space camping_pitch
and that it would be arbitrary to call it X:part or any other sufixe 
instead of inventing a new one for each value
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] airport check in counters

sent from a phone

> On 13. Apr 2019, at 15:21, bkil  wrote:
> 
> * Check-in counters: yes! Also include their count and whether there
> are any restrictions between the different counters (with/without
> bags, online only, etc).

I am also supporting the idea of specific proposed tags for airport checkin 
counters, ref would probably be an important property. Not sure how often the 
airlines change counters, but probably not that often.
(operator?)

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

Re: [Tagging] shelter_type=rock_shelter

sent from a phone

> On 14. Apr 2019, at 14:13, Andrew Harvey  wrote:
> 
> The Australian community has indicated that amenity=shelter + 
> shelter_type=rock_shelter is not an appropriate tag in this case since these 
> are natural features not man made features so shouldn't be under the amenity 
> key

shelter is under the amenity key because it is shelter _for_ humans, it implies 
minimum dimensions (shelter for mice would have different requirements). It is 
one way to look on things and it is not the only way of course, you could add 
natural=overhang or whatever, to distinguish them.

Cheers, Martin 

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

Re: [Tagging] shelter_type=rock_shelter

Le 14.04.19 à 14:13, Andrew Harvey a écrit :
> natural=cave_entrance

if it were to be done from scratch, the right way would have
been natural/man_made=cave on a node if we don't know
its extent + entrance=yes

> The Australian community has indicated that amenity=shelter + 
> shelter_type=rock_shelter is not an appropriate tag in this case since 
> these are natural features not man made features so shouldn't be under 
> the amenity key [2] [3] [4].

amenity describes often/also a function,
not if done with a natural<>man_made stuff.
e.g. a parking on "natural" ground remains described
with amenity=parking

what is the solution proposed in this discussion?
natural=shelter for natural shelters ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch



sent from a phone

> On 14. Apr 2019, at 18:36, marc marc  wrote:
> 
> one of the problems is that each key has its own logic
> a part of a amenity=building is building:part=*
> a part of the amenity=parking is amenity=parking_space
> a part of a leisure=sports_centre is leisure=pitch unless it is water 
> then it is leisure=swimming_pool
> 
> new keys deserve to have some consistency.
> e.g. :part if the part does not have a name in itself


I don’t follow this, a part of a park is a park:part (bench, tree etc)? A part 
of a city? This would be ridiculous or ambiguous or arbitrary most of the time, 
but for buildings it works well, also if the part has its own name.

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

Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?

2019-04-14 Thread Tony Shield

I was unfamiliar with the term jersey_barrier - but then there are other
barriers I was unfamiliar with. I'm happy to use it - I'm English in
England - as there are no dual-uses I am aware of.

https://www.mapillary.com/map/im/Wp18aKeOYiiFWti5nTqorQ in my opinion
shows some very posh jersey-barriers outside the Palace of Westminster.

I've noticed that many of the plastic barriers used on UK motorways are
filled with water - presumably as they can be located by hand then
filled from a mobile water tank - no crane required.

Tony

On 14/04/2019 10:56, Joseph Eisenberg wrote:

Thanks, Martin! I couldn’t find that link.

I wish the OSM wiki search feature had a better algorithm.

Can anyone from England confirm that this tag is intelligible in your
dialect? Are there other names for these that should be mentioned on
the page?

Joseph

On Sun, Apr 14, 2019 at 4:57 PM Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

sent from a phone

On 14. Apr 2019, at 04:43, Joseph Eisenberg
mailto:joseph.eisenb...@gmail.com>>
wrote:

I want to know so that the wiki page can be edited to show the
correct status: approved vs in use.

I went back into the archives and it seems it was included and
approved in my more barrier types proposal 2011:

Cheers, Martin

___
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] what is the meaning of bicycle=yes on highway=path

sent from a phone

> On 12. Apr 2019, at 15:47, Joseph Eisenberg  
> wrote:
> 
> My understanding is that highway=path is rather problematic if there
> are no additional tags, because it's not clear if all paths are open
> to bicycles or horses. See
> https://wiki.openstreetmap.org/wiki/Path_controversy

it is clear with no additional tags (everything unmotorized is yes), a question 
may arise if other tags are added, e.g. foot=yes but more foot=designated 
(according to the jurisdiction this can mean bicycles are allowed or not)

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

Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch

Le 14.04.19 à 17:28, Martin Koppenhoefer a écrit :
> Camping pitches could become their own key:

one of the problems is that each key has its own logic
a part of a amenity=building is building:part=*
a part of the amenity=parking is amenity=parking_space
a part of a leisure=sports_centre is leisure=pitch unless it is water 
then it is leisure=swimming_pool

new keys deserve to have some consistency.
e.g. :part if the part does not have a name in itself
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch



sent from a phone

> On 14. Apr 2019, at 15:46, Joseph Eisenberg  
> wrote:
> 
> By using a different key, like "camp_site=*", this is more clearly a
> "sub-feature" of tourism=camp_site


IMHO the tag indicates a subtype of camp site, rather than a feature.
I am not opposing a new key, but why “site”? E.g.
camping=pitch
or
camp=pitch 

There are already types of camping sites tagged with the camp_site key:
https://taginfo.openstreetmap.org/keys/camp_site#values
admittedly fewer than camp_site=camp_pitch

There is also noteworthy usage of 
camp_pitch:type
https://taginfo.openstreetmap.org/keys/camp_pitch%3Atype

Camping pitches could become their own key:
camp_pitch=motorhome / tent / see taginfo for camp_pitch:type=*

is it camp_pitch or would camping_pitch be better?

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

Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?



sent from a phone

> On 14. Apr 2019, at 14:43, "ajt1...@gmail.com"  wrote:
> 
> but I can't think of anything other than "concrete barrier" for these.


yes, which is very unspecific and doesn’t include those made of plastic

Cheers, Martin 


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

Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?

Thanks!
I usually browse the wiki with images turned off to save on data (I
pay $20 per Gigabyte), so sometimes I miss these things. I wish all
the important images had an alt-text.

On 4/14/19, Tobias Knerr  wrote:
> On 14.04.19 11:56, Joseph Eisenberg wrote:
>> Thanks, Martin! I couldn’t find that link.
>
> On many wiki pages, the infobox template will show an icon next to the
> status (e.g. "approved"). Clicking that icon links to the proposal.
>
> The link is based on the "statuslink" field of the template, and I find
> it very useful for locating the proposal that a tag originated in.
>
> Tobias
>
> ___
> 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 - Camp_site=camp_pitch

Martin, do you have a suggestion for a different key or value for this tag?

I mentioned "tourism=camp_pitch" or "amenity=camp_pitch" above, but I
think this could cause people to start using this as a stand-alone
feature, perhaps for small or remote campsites that have only one
pitch. However, I don't think this would be good. Mappers should use
the established tag "tourism=camp_site" to map the outline of the
whole camping area, whether it is for 1 tent or 1000.

By using a different key, like "camp_site=*", this is more clearly a
"sub-feature" of tourism=camp_site

Joseph

On 4/14/19, Sven Geggus  wrote:
> Martin Koppenhoefer  wrote:
>
>> I would not say it is used frequently, we have 100.000 camp sites tagged,
>> and only 7000 pitches with this tag
>
> Given the fact, that about half of them do not have more tags than name
> (about a quarter lack even name)  this ratio is not all that bad.
>
> Regards
>
> Sven
>
> --
> .. this message has been created using an outdated OS (UNIX-like) with an
> outdated mail- or newsreader (text-only) :-P
>
> /me is giggls@ircnet, http://sven.gegg.us/ on the Web
>
> ___
> 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] Was barrier=jersey_barrier approved in a proposal?

2019-04-14 Thread Tobias Knerr

On 14.04.19 11:56, Joseph Eisenberg wrote:
> Thanks, Martin! I couldn’t find that link.

On many wiki pages, the infobox template will show an icon next to the
status (e.g. "approved"). Clicking that icon links to the proposal.

The link is based on the "statuslink" field of the template, and I find
it very useful for locating the proposal that a tag originated in.

Tobias

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

Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?

Great. Thank you

On Sun, Apr 14, 2019 at 9:45 PM ajt1...@gmail.com  wrote:

> On 14/04/2019 10:56, Joseph Eisenberg wrote:
> > Can anyone from England confirm that this tag is intelligible in your
> > dialect? Are there other names for these that should be mentioned on
> > the page?
>
> It's not in common non-trade use in the UK, but trade sites certainly
> use that name.  Maybe others can (I'm sure there are a few UK highway
> engineers on this list), but I can't think of anything other than
> "concrete barrier" for these.
>
> Partly the reason might be that they're a relatively recent introduction
> to the UK - divided roads historically had a grass median, later with
> added Armco or a metal catch rope (designed to deflect wayward traffic
> back into their lane, not just stop it). As the median (and hard
> shoulders) came to be viewed as "wasted space" there's more concrete
> around now - but the US name hasn't really crossed the Atlantic into
> general UK use.
>
> Most importantly I'd say "Jersey Barrier" doesn't mean something
> _different_ here.  If it did, that would be a problem.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> 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] Was barrier=jersey_barrier approved in a proposal?

2019-04-14 Thread ajt1...@gmail.com


On 14/04/2019 10:56, Joseph Eisenberg wrote:
Can anyone from England confirm that this tag is intelligible in your 
dialect? Are there other names for these that should be mentioned on 
the page?


It's not in common non-trade use in the UK, but trade sites certainly 
use that name.  Maybe others can (I'm sure there are a few UK highway 
engineers on this list), but I can't think of anything other than 
"concrete barrier" for these.


Partly the reason might be that they're a relatively recent introduction 
to the UK - divided roads historically had a grass median, later with 
added Armco or a metal catch rope (designed to deflect wayward traffic 
back into their lane, not just stop it). As the median (and hard 
shoulders) came to be viewed as "wasted space" there's more concrete 
around now - but the US name hasn't really crossed the Atlantic into 
general UK use.


Most importantly I'd say "Jersey Barrier" doesn't mean something 
_different_ here.  If it did, that would be a problem.


Best Regards,

Andy



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

Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?

Thanks, Martin! I couldn’t find that link.

I wish the OSM wiki search feature had a better algorithm.

Can anyone from England confirm that this tag is intelligible in your
dialect? Are there other names for these that should be mentioned on the
page?

Joseph

On Sun, Apr 14, 2019 at 4:57 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 14. Apr 2019, at 04:43, Joseph Eisenberg 
> wrote:
>
> I want to know so that the wiki page can be edited to show the correct
> status: approved vs in use.
>
>
>
> I went back into the archives and it seems it was included and approved in
> my more barrier types proposal 2011:
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/New_barrier_types=684703
> Not sure where the tag name for jersey barriers came from, probably from
> tagging ml discussion (it is not a word I have in my vocabulary)
>
> Cheers, Martin
>
> ___
> 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] shelter_type=rock_shelter

2019-04-14 Thread Andrew Harvey

The wiki documents amenity=shelter + shelter_type=rock_shelter [1] as "A
rock shelter is a shallow cave-like opening at the base of a bluff or
cliff." It has ~500 uses globally.

In Australia these rock shelters known as rock overhangs or cliff overhangs
are extensively mistagged as natural=cave_entrance. Although many of these
overhangs are named as a cave like "Darks Cave", I don't think they are
quite the same as natural=cave_entrance, which seems more for entrances to
underground cavities which you walk into with at times a narrow  opening,
ie a proper cave.

The Australian community has indicated that amenity=shelter +
shelter_type=rock_shelter is not an appropriate tag in this case since
these are natural features not man made features so shouldn't be under the
amenity key [2] [3] [4].

I think the amenity/natural key is just a historical artefact, and doesn't
need to strictly imply natural/non-natural.

Should we create a new natural tag and deprecate shelter_type=rock_shelter,
or just accept the tag as in use?

Appreciate any comments either way. I just want to see single globally
accepted tag to avoid tag proliferation.

[1] https://wiki.openstreetmap.org/wiki/Key%3Ashelter_type
[2] https://lists.openstreetmap.org/pipermail/talk-au/2019-April/012578.html
[3] https://lists.openstreetmap.org/pipermail/talk-au/2019-March/012529.html
[4] https://lists.openstreetmap.org/pipermail/talk-au/2019-March/012530.html
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch

2019-04-14 Thread Sven Geggus

Martin Koppenhoefer  wrote:

> I would not say it is used frequently, we have 100.000 camp sites tagged,
> and only 7000 pitches with this tag

Given the fact, that about half of them do not have more tags than name
(about a quarter lack even name)  this ratio is not all that bad.

Regards

Sven

-- 
.. this message has been created using an outdated OS (UNIX-like) with an 
outdated mail- or newsreader (text-only) :-P

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?

2019-04-14 Thread Dave Swarthout

>From Wikipedia:

Jersey barriers were developed in the 1950s, beginning in the U.S. state of New
Jersey  as separators between
lanes of a highway. Over time, they grew taller (as their effectiveness was
demonstrated) and became more modular (as their usefulness as temporary
barriers became apparent). Taller barriers have the added advantage of
blocking most oncoming headlights.

So it has an American heritage. Seeing as it's a widely used term in OSM,
I'd say it's a small payback for forcing us to use the English spelling of
things like centre and neighbourhood.  LOL

Dave

On Sun, Apr 14, 2019 at 3:57 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 14. Apr 2019, at 04:43, Joseph Eisenberg 
> wrote:
>
> I want to know so that the wiki page can be edited to show the correct
> status: approved vs in use.
>
>
>
> I went back into the archives and it seems it was included and approved in
> my more barrier types proposal 2011:
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/New_barrier_types=684703
> Not sure where the tag name for jersey barriers came from, probably from
> tagging ml discussion (it is not a word I have in my vocabulary)
>
> Cheers, Martin
>
> ___
> 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] Fwd: [OSM-talk] [Wiki] Proposed wiki policy - Voting - Deletion policy

2019-04-14 Thread bkil

Thanks for the link. One man's trash is another man's treasure.

On Sun, Apr 14, 2019 at 4:57 AM Joseph Eisenberg
 wrote:
>
> This was posted to OSM-talk but is relevant to tagging and the proposal 
> process
>
> --Forwarded message 
> From: Tigerfell 
>
> We would like to invite you to voting in the case of the proposed Deletion 
> policy for wiki pages and files [1].
>
> As you might have noticed, there were conflicts based on requests to delete 
> wiki pages and especially drafts of proposals. One of the arguments in favour 
> of deletion was avoiding confusion and clutter. The other side argued 
> basically that they wanted to keep everything as all of the fragments 
> ensemble OpenStreetMap's history. Based on the input of several contributors, 
> we drafted a deletion policy over the span of two and a half months.
>
> Among other things, the policy proposes a centralised discussion page for all 
> cases which are not mentioned explicitly.
>
> Kind regards,
> Tigerfell
>
> [1] https://wiki.openstreetmap.org/wiki/OpenStreetMap:Deletion_policy
> ___
> 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] Was barrier=jersey_barrier approved in a proposal?



sent from a phone

> On 14. Apr 2019, at 04:43, Joseph Eisenberg  
> wrote:
> 
> I want to know so that the wiki page can be edited to show the correct 
> status: approved vs in use.


I went back into the archives and it seems it was included and approved in my 
more barrier types proposal 2011: 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/New_barrier_types=684703
Not sure where the tag name for jersey barriers came from, probably from 
tagging ml discussion (it is not a word I have in my vocabulary)

Cheers, Martin 

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

Re: [Tagging] tags for a live stock sale yard

2019-04-14 Thread bkil

In Hungary, market auctions do not exist. Instead you go to the
livestock market, purchase some chicks, then go to the producers'
market to grab some grain for them. Many markets are open to a little
haggling, though.

We de have online auctions and also some official ones related to
liquidation or taxation for example, but vehicles and machinery are
much more common to pop up on these than livestock, and they are not a
permanent feature anyway.

What ratio of livestock purchases are executed through auctions in the
USA? If not a majority, I'd recommend we stay with amenity=marketplace
and introduce a new tag for auction=yes (or specify the kind of
auction here). This is also assuming that livestock markets commonly
have the word "market" in their name. Can you always take home the
livestock you have purchased, or are these organized at distant
auction houses, having the goods transported later on to the winner?
Maybe we need to come up with a tag for this as well (delivery=only?).

If livestock auctions are the norm there, we may introduce a new tag
for this, though shop=auction + auction=livestock isn't that far off
in this case. What else is commonly auctioned there? Is it common for
agricultural supplies as well, like pesticide, fertilizer, seed, tools
or machinery?

https://en.wikipedia.org/wiki/Auction#Common_uses

On Sun, Apr 14, 2019 at 5:35 AM Joseph Eisenberg
 wrote:
>
> I saw that proposal, but it seems to be discussing auction houses that
> sell goods from estates, or collectibles, rather than a commodity
> auction.
>
> For a livestock auction, I would suggest using amenity=auction or
> amenity=auction_house with auction=livestock.
>
> But there do seem to be some marketplaces where livestock is sold via
> general negotiation in Asia, eg. here in Indonesia we had a
> marketplace called "Pasar Sapi" or "Cattle Market" which mainly sold
> fruits and vegetables, but occasionally had cattle or goats for sale.
> And the marketplace in my town here in New Guinea always has pigs and
> chickens for sale (live), price negotiable but not auctioned.
>
> If there are cases like this, amenity=marketplace +
> marketplace=livestock could work (assuming it is primarily a livestock
> market).
>
> ___
> 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] What is the role of "role=guidepost"

2019-04-14 Thread Mateusz Konieczny

Apr 14, 2019, 12:37 AM by pelder...@gmail.com:

> But I would say, practically, guideposts do not need to be in the route 
> relation. If a guidepost is part of a route, it is also part of a way so the 
> point location is already in there.
>
AFAIK most (many?) guideposts are not tagged this wat, but rather at their real 
location (that is
usually not in the middle of path).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Requiring area=yes with barrier=wall, barrier=hedge and other usually linear features when mapped as an area`1

sent from a phone

> On 14. Apr 2019, at 08:37, Shawn K. Quinn  wrote:
> 
> This makes even less sense and is even clumsier, especially for those
> using iD if memory serves correctly.

I did not experience problems with id in such cases, but I also would not let 
the mapping concepts be lead by a single editing software. Editors can always 
be updated if they cannot cope with certain concepts, while there is no easy 
fix for ambiguous map data.

> Single-member multipolygons are
> also a clear misuse of the multipolygon relation; the prefix "multi"
> means more than one.

it is not a misuse, the minimum requirements for multipolygon members is one 
outer way, at most it is an unfortunate name for the kind of relation.

> If, for some reason, the fence or the park boundary
> differ, I can see making one or both a multipolygon, but if they are the
> same then they should be tagged on the same way (at least as I see it).

If you tag them “on the same way” you state that they are the same thing and 
that all tags apply to it contemporaneously. I would say they could be mapped 
with the same way delimiting them (but as distinct objects). The fence is the 
boundary of the park, there is some connection between the two, but they are 
not the same thing.

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

Re: [Tagging] Requiring area=yes with barrier=wall, barrier=hedge and other usually linear features when mapped as an area`1



sent from a phone

> On 14. Apr 2019, at 06:15, Phake Nick  wrote:
> 
> area=no would also applies to amenity=park or landcover=* if you are tagging 
> them in the same object.


you cannot map them on the same object. The name would also apply to the fence, 
the height would also apply to the park, etc.

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

Re: [Tagging] Requiring area=yes with barrier=wall, barrier=hedge and other usually linear features when mapped as an area`1

2019-04-14 Thread Shawn K. Quinn

On 4/13/19 15:43, Martin Koppenhoefer wrote:
> On 13. Apr 2019, at 19:58, Shawn K. Quinn  wrote:
>>
>> It makes no sense to have to add separate ways for barrier=fence and
>> leisure=park when the fence surrounds the entire park.
> 
> you could make the park a multipolygon.

This makes even less sense and is even clumsier, especially for those
using iD if memory serves correctly. Single-member multipolygons are
also a clear misuse of the multipolygon relation; the prefix "multi"
means more than one. If, for some reason, the fence or the park boundary
differ, I can see making one or both a multipolygon, but if they are the
same then they should be tagged on the same way (at least as I see it).

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] What is the role of "role=guidepost"