Re: [Tagging] Quarry lakes

2020-12-24 Thread Joseph Eisenberg
I would like to keep water=lake as being a natural or semi-natural lake.

Since most abandoned quarries are obviously artificial, it would be better
to use a different tag.

"Water-filled quarries can be very deep, often 50 ft (15 m) or more, and
surprisingly cold, so swimming in quarry lakes is generally not
recommended. Unexpectedly cold water can cause a swimmer's muscles to
suddenly weaken; it can also cause shock and even hypothermia.[2] Though
quarry water is often very clear, submerged quarry stones and abandoned
equipment make diving into these quarries extremely dangerous. Several
people drown in quarries each year."

See examples:
https://en.wikipedia.org/wiki/Quarry#/media/File:Stone_Quarry_Kerala.JPG
https://en.wikipedia.org/wiki/Quarry#/media/File:Stone_quarry_adelaide.JPG
https://en.wikipedia.org/wiki/Quarry#/media/File:Rummu_karjäär1.jpg

The first two are obviously old quarries and I would want to use a
different tag, not water=lake.

-- Joseph Eisenberg


On Thu, Dec 24, 2020 at 9:24 AM Brian M. Sperlongano 
wrote:
>
> A commenter on the reservoir proposal[1] pointed out the existence of
quarry lakes[2], which is a lake that is formed after a quarry has been dug
after a mining operation.  It was suggested that such bodies of water
should be tagged separately from other lakes with a tag such as
water=quarry.
>
> Should quarry lakes be tagged under a separate value from water=lake?
>
> Should quarry lakes be tagged as a subset of lake, something like
water=lake + lake=quarry?
>
> If there is consensus that quarry lakes should be excluded from
water=lake, obviously that impacts how water=lake is defined.
>
> Existing usages:
> water=quarry_lake: 37
> water=quarry: 27
> water=Quarry: 18
> lake=quarry: 1
>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
> [2] https://en.wikipedia.org/wiki/Quarry_lake
> ___
> 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] Definition of lake/pond as applied to stream/plunge pools

2020-12-22 Thread Joseph Eisenberg
Brian,

In current practice the areas of rivers (whether waterway=riverbank or
water=river) are not tagged with a name=* tag, that goes on the linear
waterway=river feature. The same is true for canals.

This makes sense because the name belongs to the linear watercourse, and
adding it to the area would duplicate the name.

— Joseph Eisenberg

On Tue, Dec 22, 2020 at 5:50 AM Brian M. Sperlongano 
wrote:

> Great discussion, here and in the 2017 thread.  Participation in the
> tagging list is certainly educational.
>
> water=stream_pool suffers from a few problems, and its use seems far from
> a settled question.  (None of this is meant as criticism, as I understand
> all too well the hard work involved in developing proposals and good wiki
> documentation).
>
> In the three years since that discussion, water=stream_pool has achieved
> just 425 usages.  I assume that the biggest reason for this is that it's
> only documented as an entry in the table for the wiki page for Key=water.
> Notably absent is any mention of stream pools (or for that matter, plunge
> pools) from either of the two main wiki pages for river documentation
> (water=river vs waterway=riverbank).  This begs the question of how
> water=stream_pool should interlace with river polygons for mapping.
>
> Stream/plunge pools are part of a river or stream (I assert this based on
> Wikipedia's definition).  Logically, one might think "chop up the river
> polygon, and tag the stream pool portion as a stream pool".  This approach
> has a few problems:
>
> 1. If the river area is tagged with the water=river scheme, the area of
> the stream pool is no longer tagged as a river (because water=stream_pool
> conflicts with water=river).  This is wrong because the stream/plunge pool
> is indeed part of the river.  You could use the waterway=riverbank scheme,
> but now you're blending the two types of river tagging.  Yuck.
> 2. If the stream pool has a name, that portion of the river loses the name
> of the river, as the polygon can only have one name= tag.  The
> waterway=river way of course would still carry the name, so you do still
> maintain continuity.  But you lose concepts like "the total surface area of
> the river".
>
> Alternately, you could overlap the pool area over the river polygon, but
> then you're double-tagging the water area which seems like poor practice,
> and certainly JOSM would give you a warning for overlapping water features.
>
> It seems to me that river=stream_pool would have been the more sensible
> tagging within the natural=water+water=river scheme, as it further
> describes that portion of the river.
>
> The low usage and structural problems associated with stream pool tagging
> suggest that this is not a ready-for-prime-time tagging scheme, and
> deserves a proposal - not just a mailing list discussion - to sort out
> fundamentally unanswered questions about how to tag a river with both named
> and unnamed stream pools, particularly with regard to how the polygons are
> divided and/or overlapped.  One might also argue that a stream pool should
> simply be mapped as a node, and if it's too big for a node, then perhaps
> it's more properly tagged as a pond or lake.  Unanswered questions.
>
> Stream and plunge pools are a part of rivers (per WP definition), and I
> don't intend to address river tagging as part of the reservoir/lake/pond
> proposal[1].  Therefore, what makes the most sense is to simply scrub
> mention of pools and rivers from the proposal and leave it squarely focused
> on reservoirs, lakes, and ponds.
>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
>
>
>
> On Tue, Dec 22, 2020 at 12:49 AM Andrew Harvey 
> wrote:
>
>> Back in 2017 this was discussed on the list
>> https://lists.openstreetmap.org/pipermail/tagging/2017-March/031595.html and
>> the outcome of that was I added water=stream_pool to the wiki at
>> https://wiki.openstreetmap.org/wiki/Key:water#Natural_features. Is there
>> any reason to change this now? I think continuing to tag these as
>> natural=water + water=stream_pool is best as currently documented and in
>> use.
>>
>> On Tue, 22 Dec 2020 at 05:13, Brian M. Sperlongano 
>> wrote:
>>
>>> Discussion on the current reservoir proposal[1] (which seeks to define
>>> the distinction between reservoirs, lakes, and ponds) has brought up the
>>> question of stream/plunge pools[2,3], and how they fit into the lake/pond
>>> definitions.
>>>
>>> I've come up with the following text:
>>>
>>> "Occasionally a river or stream will form a stream pool or plunge pool,
>>> which are bodies of water that naturally occur along the course o

Re: [Tagging] Feature proposal - Voting - guard stone

2020-12-21 Thread Joseph Eisenberg
 C) Freestanding guardstone-like objects are often found independently of
buildings.

Those look like barrier=bollard perhaps?

On Mon, Dec 21, 2020 at 9:33 AM Volker Schmidt  wrote:

> I forgot to follow up on two other aspects of this, sorry.
>
> A) how are they tagged when two of them are on both sides of a gate
> 
> ?
>
> B) There are occasionally also rows of them in historic towns
> 
> .
>
> C) Freestanding guardstone-like objects are often found independently of
> buildings.
> I am not sure what they are called, here are some examples.
> They come in three types of  arrangements:: pairs, or rows, or pairs of
> rows.
> The pairs are often on minor roads on embankments
>  (don't know
> what the purpose was)
> The rows are often on major roads on embankments
> , or older
> mountain pass roads.
> 
> (predecessors of guardrails I suppose)
>
> Volker
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-6450454857789031944_m_980705564951531214_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, 21 Dec 2020 at 11:50, Anne-Karoline Distel 
> wrote:
>
>> Hi,
>>
>> there haven't been any comments on it in a while, so I think it is safe
>> to start the voting process on
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/guard_stone
>>
>> Voting ends on January 4th.
>>
>> Thanks to everyone who contributed to the discussion and proposal page!
>>
>> Happy holidays,
>>
>> Anne (b-unicycling)
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-6450454857789031944_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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 - Emergency=Rescue Stations

2020-12-19 Thread Joseph Eisenberg
The text of the proposal is still confusing.

Is the tag emergency=rescue_stations being proposed?

What are the tags which are proposed and what will be the definition of
each tag?

— Joseph Eisenberg

On Sat, Dec 19, 2020 at 7:33 PM Graeme Fitzpatrick 
wrote:

>
>
>
> On Sun, 6 Dec 2020 at 12:18, Graeme Fitzpatrick 
> wrote:
>
>> https://wiki.openstreetmap.org/wiki/Rescue_Stations
>>
>
> Moved to voting.
>
> If you still have any comments or concerns, please raise them for
> discussion, rather than just voting "No, because ..."!
>
> 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 - Tag:healthcare=vaccination_centre

2020-12-17 Thread Joseph Eisenberg
Any more comments or concerns about the proposed tag healthcare
<https://wiki.openstreetmap.org/wiki/Key:healthcare>=vaccination_centre
<https://wiki.openstreetmap.org/wiki/Tag:healthcare%3Dvaccination_centre>?

I also considered amenity=vaccination_centre but I thought that
healthcare=* would be more likely to get approved. Either key seems fine.

-- Joseph Eisenberg

On Thu, Dec 10, 2020 at 5:39 AM Martin Koppenhoefer 
wrote:

> Thank you for taking the time to draft this! Looks generally ok and is
> needed.
>
> A small detail: maybe we would want to have a more explicit qualifier for
> the distinction between structures conceived for permant and temporary use,
> which could be added even if there is no official / precise end date, e.g.
> temporary=yes or interim=yes?
>
> Looking at used tags, it occurs to me, "temporary" is already in modest
> use and documented: https://wiki.openstreetmap.org/wiki/Key%3Atemporary
> "Use temporary=yes
> <https://wiki.openstreetmap.org/w/index.php?title=Tag:temporary%3Dyes=edit=1>
> to state that a feature is temporary.", consider adding a refernce to it in
> the proposal.
>
> 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] Proposed feature - RFC - Military Bases

2020-12-17 Thread Joseph Eisenberg
So far the proposal lacks a definition of the new tag military=base

The closest we get is "military=base for the area of each military
establishment" but that makes it sound like almost any kind of
landuse=military could have the military=base tag added.

How should military=base be defined?

-- Joseph Eisenberg

On Thu, Dec 17, 2020 at 2:44 PM Graeme Fitzpatrick 
wrote:
>
>
> On Tue, 8 Dec 2020 at 10:19, Graeme Fitzpatrick 
wrote:
>>
>> I have just posted a new proposal re Military Bases:
https://wiki.openstreetmap.org/wiki/Proposed_features/Military_bases
>
>
> This proposal is also getting close to voting.
>
> Precis:
>
> deprecate:
>
> military=naval_base
> protect_class=25
>
> modify:
>
> military=barracks
>
> add:
>
> military=base
> military_service=xxx
>
>
> There have been lot's of fantastic suggestions & comments made so far, so
if you have any more, please add them either here or on the talk page.
>
> 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] Tagging sewage treatment basins

2020-12-17 Thread Joseph Eisenberg
The tag water_works=* is great for use with man_made=water_works - but
that's for treating water before it is used, not for treatment of sewage,
normally: "water works is a place where drinking water is found and applied
to the local waterpipes network."

But there is also
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwastewater_plant -
man_made=wastewater_plant so perhaps the key wastewater_plant=* would be
appropriate, e.g.: landuse=basin + content=sewage
+ wastewater_plant=decanter for your example?

I note that the page suggest using "water=wastewater" in this case instead
of water=basin or water=reservoir:
https://wiki.openstreetmap.org/wiki/Tag:water%3Dwastewater - "A
clarifier/settling basin of a wastewater treatment plant" - used >32,000
times and pretty widespread globally:
https://taginfo.openstreetmap.org/tags/?key=water=wastewater#chronology
- https://taginfo.openstreetmap.org/tags/?key=water=wastewater#map

-- Joseph Eisenberg

On Thu, Dec 17, 2020 at 3:07 PM François Lacombe 
wrote:
>
>
> Hi Joseph,
>
> Le jeu. 17 déc. 2020 à 20:16, Joseph Eisenberg 
a écrit :
>>
>> I don't think mappers can know the maximum volume or capacity of a water
reservoir or water basin, unless it is written on a public sign somewhere?
We can map the surface area, but knowing the average depth or maximum depth
is quite difficult, especially when it is not uniform. However for
man_made=reservoir_covered and =storage_tank we have capacity=* (in cubic
meters?) and content=water/sewage/etc.
>
>
> volume, elevation would be optional and mostly got from local signage.
> You may have opendata, knowledge or sometimes measurements.
> Many tags are already available but not used at the proper extent.
> For example, if we add capactiy (in cubic meters) on a waste water basin,
we could do the same for man_made=covered_reservoir or even water=reservoir
(if information is available somewhere)
> Look at this water tower hunting website giving many details from ground
http://chateau.deau.free.fr/rdef/PagesHTML/Sommaires/GermanDossiers.html
>
>>
>> The usage is not often tagged yet, since this might be hard for a mapper
to know.
>
>
> Regarding waste water basins, it could be useful to distinguish
> - sand traps
> - oil separator
> - floccuation
> - decanter basins
> - aeration tanks
> and so on...
https://www.horiba.com/fileadmin/_migrated/pics/Wastewater_Processing_E_.jpg
> That looks complex but easilly guessable from aerial imagery or even
clearly explained during public visits of facilities.
> We could define simpler values if it helps
>
>>
>> Currently for landuse=reservoir and water=reservoir this is some use of
reservoir_type= - https://wiki.openstreetmap.org/wiki/Key:reservoir_type -
with values of water_storage, sewage, tailings, evaporator, tank, salt_pan,
wastewater, slurry, irrigation, aquicultura, cooling, etc - though only the
first 4 are at all common.
>>
>> basin=* is used with landuse=basin or water=basin to describe the form
and function of the basin:
>>
>> basin=infiltration - An infiltration basin catches storm water and
allows it to seep into an aquifer.
>> basin=detention - A detention basin catches storm water and allows it to
drain slowly into natural waterways.
>> basin=retention - A retention basin catches storm water and retains it,
forming an artificial pond.
>>
>>
>> And note that salt ponds (used to evaporate salt from sea-water) are
tagged as landuse=salt_pond
>> Pools for swimming are leisure=swimming_pool
>>
>> I don't see many combinations with usage=* or another tag that might
describe how the reservoir or basin is used, so perhaps this could be
proposed?
>
>
>
> That's right, usage=* corresponds to large familiy of activities and more
specific tagging would be more suitable to describe precise purpose of a
particular basin
> reservoir_type and basin looks like to refer to reservoir/basin purpose
but mixes may concepts that may collide (irrigation is a water_storage as
well)
> Only some values would match with usage=* ones: usage=irrigation is used
12k vs reservoir_type=irrigation 50
>
> Waste water processing could be described with less used water_works=*
> man_made=basin (An artifical structure designed to store some fluid, you
find basins for storm/rain/radioactive water, sewage, oil, ...)
> content=sewage (Let's put waste water inside)
> usage=industrial (It's part of an industrial process)
> water_works=decanter (It's an actual decanter)
> capacity=
>
> I'd find great to use water=* with content=water, substance=water or
natural=water only.
>
> That's my 2 cents, let's refine it
>
> All the best
> François
>
> ___
> 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] Tagging sewage treatment basins

2020-12-17 Thread Joseph Eisenberg
Re: "volume, elevation and sometimes particular usage"

I don't think mappers can know the maximum volume or capacity of a water
reservoir or water basin, unless it is written on a public sign somewhere?
We can map the surface area, but knowing the average depth or maximum depth
is quite difficult, especially when it is not uniform. However for
man_made=reservoir_covered and =storage_tank we have capacity=* (in cubic
meters?) and content=water/sewage/etc.

It is possible to use ele=* for the elevation of the surface of the water
if a mapper has a very good GPS or finds this info on a sign, but this
information is also widely available from digital elevation models.

The usage is not often tagged yet, since this might be hard for a mapper to
know.

Currently for landuse=reservoir and water=reservoir this is some use of
reservoir_type= - https://wiki.openstreetmap.org/wiki/Key:reservoir_type -
with values of water_storage, sewage, tailings, evaporator, tank, salt_pan,
wastewater, slurry, irrigation, aquicultura, cooling, etc - though only the
first 4 are at all common.

basin=* is used with landuse=basin or water=basin to describe the form and
function of the basin:

   - basin <https://wiki.openstreetmap.org/wiki/Key:basin>=infiltration
   <https://wiki.openstreetmap.org/wiki/Tag:basin%3Dinfiltration> - An
infiltration
   basin <https://en.wikipedia.org/wiki/en:Infiltration_basin> catches
   storm water and allows it to seep into an aquifer
   <https://en.wikipedia.org/wiki/en:aquifer>.
   - basin <https://wiki.openstreetmap.org/wiki/Key:basin>=detention
   <https://wiki.openstreetmap.org/wiki/Tag:basin%3Ddetention> - A detention
   basin <https://en.wikipedia.org/wiki/en:Detention_basin> catches storm
   water and allows it to drain slowly into natural waterways.
   - basin <https://wiki.openstreetmap.org/wiki/Key:basin>=retention
   <https://wiki.openstreetmap.org/wiki/Tag:basin%3Dretention> - A retention
   basin <https://en.wikipedia.org/wiki/en:Retention_basin> catches storm
   water and retains it, forming an artificial pond.


And note that salt ponds (used to evaporate salt from sea-water) are tagged
as landuse <https://wiki.openstreetmap.org/wiki/Key:landuse>=salt_pond
<https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dsalt_pond>
Pools for swimming are leisure
<https://wiki.openstreetmap.org/wiki/Key:leisure>=swimming_pool
<https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dswimming_pool>

I don't see many combinations with usage=* or another tag that might
describe how the reservoir or basin is used, so perhaps this could be
proposed?

-- Joseph Eisenberg


On Thu, Dec 17, 2020 at 10:36 AM François Lacombe 
wrote:

> Hi all
>
> I'm ashamed to not have enough time to be involved in all discussions
> regarding reservoir, ponds, basins and so on... and thank you to make such
> a capital topic on the table
> I'd be happy with a tagging that separates the structure, the water body
> and purpose of a given feature.
>
> Have a look to Storage chapter in this page (probably lacks many thing,
> it's just a start)
> https://wiki.openstreetmap.org/wiki/Water_management
>
> There are at least 5 ways to tag features involved in (potable) water
> storage
> What if I'm only interested to find "water storage places" with their
> volume, elevation and sometimes particular usage?
> Waste water retention basins are a supplementary situation like we could
> find dozens of them.
> Where will this end?
>
> All discussed features share the "water body" concept (or more generic
> fluid-body with substance=water) inside very different structures with even
> different purposes.
> Why don't we look to describe a generic water body, with a volume,
> elevation and usage prior to list every single feature that stores/retain
> water?
>
> This said, it's fine to have many different tags to describe very
> different structures (building=*, man_made=*, natural=*...)
> As such structures tagging should be separated from the water body they
> contain, an uniformed semantic for water bodies would make OSM a yet cooler
> place than it already is
>
> All the best
>
> François
>
>
> Le jeu. 17 déc. 2020 à 18:46, Brian M. Sperlongano 
> a écrit :
>
>> I knew them as sewage treatment ponds, but apparently there's a name for
>> them:
>>
>> https://en.m.wikipedia.org/wiki/Waste_stabilization_pond
>>
>> I feel like this a separate class of object that deserves its own tag,
>> either within or separate from natural=water, or perhaps even subclassed as
>> water=basin+basin=waste?
>>
>> On Thu, Dec 17, 2020, 12:24 PM Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> How should sewage treatment facilities be tagg

[Tagging] Tagging sewage treatment basins

2020-12-17 Thread Joseph Eisenberg
How should sewage treatment facilities be tagged, then?

Isn't sewage 99% water?

I think that most sewage treatment facilities in the USA include open
settling basins and I would use landuse=basin or water=basin +
natural=water for these: https://www.openstreetmap.org/way/420075503

-- Joseph Eisenberg

On Thu, Dec 17, 2020 at 1:55 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 17, 2020, 08:02 by dieterdre...@gmail.com:
>
>
>
> sent from a phone
>
> On 16. Dec 2020, at 17:52, Joseph Eisenberg 
> wrote:
>
> You still have to distinguish marine water (outside of the
> natural=coastline) from inland waters, and distinguishing rivers from lakes
> is very important for proper rendering of many maps.
>
>
>
> and it seems landuse=reservoir is used for sewage as well:
> https://taginfo.openstreetmap.org/tags/reservoir_type=sewage
>
> is this appropriate for natural=water?
>
> No.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-17 Thread Joseph Eisenberg
Using terms such as "on a rampage" and "gods know where else he is
buldozzing" is inappropriate and does not contribute to this discussion.
Such rhetoric will not convince other mappers to use a certain tagging
method. This language does not promote an open and welcoming community. It
does not demonstrate an attempt to assume goodwill.

In this cross-cultural environment where many are writing in a language
which is not their primary means of communication and where we all live in
different places with different cultural values, it is very important that
we attribute good intentions to others.

If there are any problems with the ideas or words of another person, please
criticize the misinformation, but do not personally attack anyone or
suggest that another mapper had bad intent. Ad hominem arguments are not
persuasive nor effective.

-- Joseph Eisenberg

On Thu, Dec 17, 2020 at 8:55 AM Tomas Straupis 
wrote:

> 2020-12-17, kt, 18:20 Joseph Eisenberg  rašė:
> > That's not accurate, Tomas.
>
>   Why? Mateusz without the end of discussion started, well continued
> editing the wiki (I had to correct some of his misinterpretations
> which have been discussed here), he also made some attempts in JOSM
> trac, these are the things I follow, but I do now follow Mateusz
> personally, so gods know where else he is buldozzing.
>
>   This is only pushing towards the splitting of tagging standards even
> further. We will introduce our approved tagging schemas/tools in
> Lithuania, somebody will follow (some probably have already done so)
> and what will we have then? I guess a wonderland for global data
> consumers. We probably need per country tagging lists ;-)
>
> ___
> 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] Rapids (whitewater) on rivers

2020-12-17 Thread Joseph Eisenberg
Another argument against use of hazard=* for rapids is that the hazard key
has been used almost always with highway=* features, not waterways.

Also, currently waterfalls (which can be considered very large and steep
rapids!) are tagged waterway=waterfall on a node. Other waterway barriers
are also tagged this way, e.g. waterway=dam and waterway=weir. Tagging
waterway=rapids on a node allows rapids to be tagged like other waterway
barriers to travel and similar to waterfalls.

-- Joseph Eisenberg

On Thu, Dec 17, 2020 at 2:36 AM Tomas Straupis 
wrote:

> 2020-12-17, kt, 00:02 ael via Tagging rašė:
> > This is slightly off-topic in that I am picking up on the
> > hazard tag rather than rapids. I see no objection to adding hazard=rapids
> > although that might be redundant unless there exist rapids that are
> > not hazardous. I suppose shallow rapids might qualify.
>
>   Note that rapid does not necessarily have to be interpreted as
> hazard. If prominent on the ground it can be one of orienting points
> (with bridges, settlements, intakes etc.) - to cover distance
> covered/remaining. We have a lot of "small rapids" which can be easily
> passed with no risk even with babies and they're still marked for
> orienting purposes.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-17 Thread Joseph Eisenberg
That's not accurate, Tomas.

The Tag:water=reservoir page has been edited by 4 people this week,
including ZeLonewolf, Warin61, Kjon and me (Jeisenbe):
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Awater%3Dreservoir=revision=2073583=1860772
-
Mateusz has not edited this page.

The page Tag:landuse=reservoir has been edited several times by Mateusz,
but also by Tstraupis, ZeLonewolf and me - each 2 times in the past week.
The wiki documentation is a team effort which evolves over time:
https://wiki.openstreetmap.org/w/index.php?title=Tag:landuse%3Dreservoir=history

Please feel welcome to edit it further if there is information that is
missing, incorrect or misleading in the current version of the page.

-- Joseph Eisenberg

On Wed, Dec 16, 2020 at 11:16 PM Tomas Straupis 
wrote:

> And while we're discussing here, Mateusz is already on a rampage to
> change wiki pages, write patches etc. Thus buldozzing his opinion,
> ignoring others. Showing "community building" behaviour.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Joseph Eisenberg
That example certainly looks like a landuse=basin or water=basin feature
with basin=retention

On Wed, Dec 16, 2020 at 6:23 PM Graeme Fitzpatrick 
wrote:

> In an Australian context, the most common are known as Turkey's Nest dams,
> because they're mounded up above the ground eg
>
> https://c8.alamy.com/comp/A6T7R0/turkey-nest-dam-on-outback-cattle-station-queensland-australia-A6T7R0.jpg
>
> For a full explanation:
> https://www.agric.wa.gov.au/water-management/excavated-tanks-farm-dams
>
> Thanks
>
> Graeme
>
>
> On Thu, 17 Dec 2020 at 11:53, Joseph Guillaume 
> wrote:
>
>> That Wikipedia page is right.
>> The artificial grading mostly involves creating an (earthen) dam wall
>> (which is often also mapped), and the purpose is generally retention of
>> water rather than infiltration or detention, which is why the distinction
>> between reservoir and basin isn't clear cut to me.
>>
>> I'm having trouble thinking of it as a basin, but it does seem like this
>> is the intended tag. Thanks!
>>
>>
>>
>> On Thu, 17 Dec 2020, 12:29 pm Joseph Eisenberg, <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> What is a farm dam in this context? We don't have that term in American
>>> English.
>>>
>>> Is this perhaps an example of landuse=basin (or if you prefer
>>> water=basin) with basin=detention or basin=infiltration?
>>>
>>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin
>>>
>>> https://en.wikipedia.org/wiki/Dam_(agricultural_reservoir)
>>>
>>> -- Joseph Eisenberg
>>>
>>> On Wed, Dec 16, 2020 at 1:29 PM Joseph Guillaume <
>>> josephguilla...@gmail.com> wrote:
>>>
>>>> This discussion has convinced me not to use landuse=reservoir.
>>>>
>>>> It sounds like the only benefit is its historical use, whereas I've
>>>> personally seen benefits of the natural=water approach.
>>>>
>>>> I've mapped quite a number of farm dams as natural=water without being
>>>> sure what subtag to use.
>>>> I now think that's because there isn't an appropriate subtag. I
>>>> definitely don't want to tag it as a pond. While a farm dam is structurally
>>>> and functionally a reservoir, there are clear differences with large
>>>> reservoirs.
>>>>
>>>> Already now, farm dams tend to be mapped more prominently than I'd
>>>> expect. The dominant feature of these grazing landscapes is fencing, and
>>>> I'd therefore expect farm dams to appear on a similar scale to fences.
>>>> water=reservoir and landuse=reservoir wouldn't do that.
>>>>
>>>> One of the things I love about OSM is the ability to map incrementally,
>>>> which by definition results in incomplete, lower quality maps that are
>>>> constantly improving. If the priority was a high quality map, we'd map
>>>> systematically (like Missing maps, but for everything that will appear on a
>>>> render) and not release an area until it was done. I wouldn't be mapping.
>>>>
>>>>
>>>> On Thu, 17 Dec 2020, 1:26 am Tomas Straupis, 
>>>> wrote:
>>>>
>>>>> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
>>>>> >
>>>>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
>>>>> > (just added)
>>>>>
>>>>>   Thank you. Maybe it is better to discuss here before adding to wiki?
>>>>>   My arguments on the points you've added:
>>>>>
>>>>>   1. Regarding benefit of having a combining level/tag natural=water.
>>>>> If today you would query all data with natural=water - you will get
>>>>> not only lakes and reservoirs grouped, but also riverbank polygons
>>>>> (totally different beast) and micro elements like water=pond. This
>>>>> could only be partly useful in the largest scale maps and only if you
>>>>> make very simple maps and for some reason use the same symbolisation
>>>>> for such different water classes. For example ponds usually have less
>>>>> complex and less prominent symbolisation because of their size and
>>>>> importance. Riverbanks would not need polygon labelling, but rather
>>>>> use river (central) line for label placement. Most of GIS/Cartography
>>>>> work goes in middle/small scales and it will be impossible to use only
>>>>> natural=water there, you 

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Joseph Eisenberg
What is a farm dam in this context? We don't have that term in American
English.

Is this perhaps an example of landuse=basin (or if you prefer water=basin)
with basin=detention or basin=infiltration?

https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin

https://en.wikipedia.org/wiki/Dam_(agricultural_reservoir)

-- Joseph Eisenberg

On Wed, Dec 16, 2020 at 1:29 PM Joseph Guillaume 
wrote:

> This discussion has convinced me not to use landuse=reservoir.
>
> It sounds like the only benefit is its historical use, whereas I've
> personally seen benefits of the natural=water approach.
>
> I've mapped quite a number of farm dams as natural=water without being
> sure what subtag to use.
> I now think that's because there isn't an appropriate subtag. I definitely
> don't want to tag it as a pond. While a farm dam is structurally and
> functionally a reservoir, there are clear differences with large reservoirs.
>
> Already now, farm dams tend to be mapped more prominently than I'd expect.
> The dominant feature of these grazing landscapes is fencing, and I'd
> therefore expect farm dams to appear on a similar scale to fences.
> water=reservoir and landuse=reservoir wouldn't do that.
>
> One of the things I love about OSM is the ability to map incrementally,
> which by definition results in incomplete, lower quality maps that are
> constantly improving. If the priority was a high quality map, we'd map
> systematically (like Missing maps, but for everything that will appear on a
> render) and not release an area until it was done. I wouldn't be mapping.
>
>
> On Thu, 17 Dec 2020, 1:26 am Tomas Straupis, 
> wrote:
>
>> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
>> >
>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
>> > (just added)
>>
>>   Thank you. Maybe it is better to discuss here before adding to wiki?
>>   My arguments on the points you've added:
>>
>>   1. Regarding benefit of having a combining level/tag natural=water.
>> If today you would query all data with natural=water - you will get
>> not only lakes and reservoirs grouped, but also riverbank polygons
>> (totally different beast) and micro elements like water=pond. This
>> could only be partly useful in the largest scale maps and only if you
>> make very simple maps and for some reason use the same symbolisation
>> for such different water classes. For example ponds usually have less
>> complex and less prominent symbolisation because of their size and
>> importance. Riverbanks would not need polygon labelling, but rather
>> use river (central) line for label placement. Most of GIS/Cartography
>> work goes in middle/small scales and it will be impossible to use only
>> natural=water there, you would have to add "and water not in
>> ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
>> makes it of the same complexity from coding perspective as original
>> water scheme.
>>
>>   2. Very important disadvantage of water=reservoir from
>> cartographic/gis perspective: it allows mappers to NOT differentiate
>> between natural lakes and man made reservoirs. If first point
>> describes how different classes are USED, this second point is about
>> how these classes are CAPTURED.
>>
>>   Did I miss anything?
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Rapids (whitewater) on rivers

2020-12-16 Thread Joseph Eisenberg
In the year 2020 waterway=rapids has been added a couple hundred times, and
the other two tags whitewater:section_grade and whitewater:rapid_grade have
been used about 100 times each:
https://taghistory.raifer.tech/#***/whitewater:rapid_grade/&***/whitewater:section_grade/&***/waterway/rapids
(zoom in to the most recent yet)

I think both tagging methods have their use. The tag waterway=rapids is
great to add to a node to specify that there are rapids here, and the
others are good for expert kayakers and rafters who are able to assess the
rapid grade.

I don't know enough about the subject to make a proposal to clear things
up, but the existing tags seem to be fine.

-- Joseph Eisenberg

On Wed, Dec 16, 2020 at 12:35 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 16, 2020, 19:27 by kevin.b.ke...@gmail.com:
>
> The last time I looked, there was no non-deprecated way to map the
> information that I had.
>
> That is sign of bad tagging scheme.
>
> I now see that @jeisenbe has restored the `waterway=rapids` tag to the
> Wiki.
>
> Is it enough?
>
> I asked here on the mailing list, and the only answers that I got were
> along the lines of "then don't map it."  So for several years I haven't
> attempted to map rapids. The ones I know of and want to render, I maintain
> separately from OSM, because the previous discussion had caused me to label
> this feature mentally as, "OSM doesn't want this mapped."
>
> :( Hopefully this can be fixed so this will not happen.
> ___
> 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] destination:ref with direction?

2020-12-16 Thread Joseph Eisenberg
Re: "If only we could be this nimble on long standing things like
sunsetting ref=* on ways in favor of routes"

Handling ref on routes and ways at the same time requires some more
complicated processing, and for a long time osm2pgsql did not provide a
standard way to do this in a consistent manner, until earlier this year. It
should soon be possible, see
https://github.com/openstreetmap/osm2pgsql/releases/tag/1.3.0 and
implementation issues at
https://github.com/gravitystorm/openstreetmap-carto/issues/596 and
https://github.com/gravitystorm/openstreetmap-carto/issues/4112 and

On Wed, Dec 16, 2020 at 8:02 AM Paul Johnson  wrote:

> On Wed, Dec 16, 2020 at 9:34 AM Tom Pfeifer 
> wrote:
>
>> Both tagging and wiki develop, hopefully forward. In this case,
>> Key:destination:ref redirects
>> onto an old 2012 proposal, I'm probably going to resolve that soon with
>> describing the current practice.
>>
>
> Thank you!  If only we could be this nimble on long standing things like
> sunsetting ref=* on ways in favor of routes (one of the things that
> relations were introduced to fix, as routes and their ways are usually
> distinct entities) and fixing lanes=* to actually mean what it says...
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Joseph Eisenberg
Re: "natural=water' wins.  I can see that there's water there"

You still have to distinguish marine water (outside of the
natural=coastline) from inland waters, and distinguishing rivers from lakes
is very important for proper rendering of many maps.

Also, many areas of natural=water actually don't have any water for much of
the year, if they are also intermittent=yes - such as seasonal lakes in
semi-arid areas.

I personally am not as concerned about water=reservoir for artificial
lakes, but I am concerned that water=river is often forgotten when mapping
areas of river water, where previously waterway=riverbank was clearly
distinguished from lakes.

Many map styles distinguish rivers and streams from lakes, since it is
often helpful to use a darker color for narrow linear features.

-- Joseph Eisenberg

On Wed, Dec 16, 2020 at 8:40 AM Kevin Kenny  wrote:

> My take on it:
>
> Wearing my data consumer's hat:
>
> For most purposes, I care about "this ground is covered with water".
> 'natural=water' is the main thing to look for, but I also have to look for
> 'landuse=reservoir' and several other things that I can't be bothered to
> look up at the moment. I have to look for all those things, so I don't
> really care all that much which one is in use.
>
> The chief problem with both of these tags is that even for the rough-level
> mapping, I have to examine 'water=*' or 'reservior_type=*' to find that the
> contained substance is, in fact, water and not sewage or mine tailings.
>
> In any case, both uses are widespread.  I'm going to need to interpret
> both for the foreseeable future.  I can cope with synonyms.  I'm not going
> to lobby strongly for one or the other.
>
> Wearing my mapper's hat:
>
> 'natural=water' wins.  I can see that there's water there. The big
> counterargument that I've heard, other than that 'landuse=reservoir' has
> been the predominant tagging, is that a reservoir isn't "natural" water.
> But in our complex, human- (and beaver-) sculpted environment, what is
> natural?  Many of the reservoirs that I've encountered have natural lakes
> and ponds underneath, and simply have had their water raised. It seems to
> me that by the thinking of those who think that 'natural' means "totally
> untouched by humans", that I'd actually be required to do the research
> about where the old shoreline lay before humans raised the water, and
> divide the reservoir into an inner 'natural=water' and an outer
> 'landuse=reservoir' - which is an example of the tagging position that I
> abhor.  I shouldn't have to do historical research in order to map
> something that I can directly observe with my own eyes. In fact, with some
> of the ponds I've mapped, I've not troubled (or been able to) access the
> outlet to find out what controls the water level. I don't know whether they
> are tarns, dolines, beaver ponds, or man-made ponds created for logging
> until I can find out where the water goes when it leaves.  (I hike in
> glaciated karst; the landforms are complex.) But I can see at a  glance,
> "there's water here," whether glaciers, limestone, beavers or humans put it
> there. That should be enough to map it.
>
> If someone else feels strongly enough about it to change something that
> I've mapped as 'natural=water' to 'landuse=reservoir', well, I know that I
> have to accept that as a synonym. so it's not going to harm me as a data
> consumer.  I'm not going to change it back.  But I'm not going to accept
> that the original tagging was "incorrect" or "deprecated".  I mapped what I
> saw. You can go there and see it too.
>
> To continue the classification of waterbodies, this argument to me is a
> tempest in a teapot.
> --
> 73 de ke9tv/2, Kevin
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-15 Thread Joseph Eisenberg
Re: the Great Lakes -

Very large archipelagos, like "Indonesia" or "The Phillipines" or "The
British Isles", shouldn't be mapped as multipolygons because they would be
ridiculously huge. Generally the tag place=archipelago is used for small to
mid-sized groups of islands. Now, it is possible to map place=island
features as nodes and then select each node to make a relation, but mapping
islands as multipolygons seems to be preferred by most mappers, and that
type of relation is much more common and established than any of the
options for groups of islands.

Similarly, the Great Lakes are too big for mapping as a single
multipolygon, and each has its own name which is the locally-verifiable
feature.

A superrelation [which added each individual lake (or island) relation as a
member rather than individual ways] might be possible even for large lakes
and large island chains, since it wouldn't break every time 2 mappers tried
to edit the coastline/lakeshore at the same time. But there is no
established relation type for this, and handling relations-of-relations is
a huge pain for editing the map as well as for database users.

I suppose if there were a well-defined type of relations which only allowed
one level of relations to be nested inside of it (that is, all members had
to be a valid multipolygon) it might be usable, but it would still get
confusing.

-- Joseph Eisenberg

On Tue, Dec 15, 2020 at 9:12 AM Brian M. Sperlongano 
wrote:

> Wouldn't it be more consistent to keep it in the same key, and call it
> place=lake_group?  Or even place=lakes?
>
> Would this be used for something like the Great Lakes in USA/Canada or is
> that too large of a feature?
>
> On Tue, Dec 15, 2020, 12:05 PM stevea  wrote:
>
>> +1.  Joseph's suggestion is a fine example of "OSM can and does coin new
>> tags on occasion."  Adding a nice boost, there is a suggestion that
>> "similar" tagging be used as an example of how to define / use / document
>> the new tag.  Great!
>>
>> On Dec 15, 2020, at 6:56 AM, Joseph Eisenberg 
>> wrote:
>> > Re: “ a couple of islets with a collective name”
>> >
>> > We have a tag for that: place=archipelago for a group of islands.
>> >
>> > There isn’t a common tag for a group of lakes with one name, probably
>> because this is only common in some countries, especially near the Arctic
>> region. We’ve talked about this issue before but did not find an existing
>> tag.
>> >
>> > I would suggest a tag like natural=lake_group to be added to a
>> multipolygon which includes each of the lakes, similar to how archipelagos
>> are mapped.
>>
>> ___
>> 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] How to put a name tag on an area with more than one type?

2020-12-15 Thread Joseph Eisenberg
Re: “ a couple of islets with a collective name”

We have a tag for that: place=archipelago for a group of islands.

There isn’t a common tag for a group of lakes with one name, probably
because this is only common in some countries, especially near the Arctic
region. We’ve talked about this issue before but did not find an existing
tag.

I would suggest a tag like natural=lake_group to be added to a multipolygon
which includes each of the lakes, similar to how archipelagos are mapped.

-Joseph Eisenberg

On Tue, Dec 15, 2020 at 5:07 AM Anders Torger  wrote:

> I'll make a small change to my naming strategy: use one multipolygon per
> natural tag set, and thus minimize the number of same-named polygons.
>
> Normally, when naming entities which has all the same natural tags but
> separate areas, such as a couple of ponds or islets with a collective name
> (common), it's made as a single multipolygon with several outers. I've
> heard that there are renderers that actually already today then render a
> single text label.
>
> As natural tags differ in this wetland a single multipolygon is not
> possible. However one can make one polygon per set of natural tags. For
> this Rimmjoáhpe wetlend I then get away with two multipolygons, thus
> greatly reducing the number of text labels rendered in some renderers,
> while still being compatible with the other method of keeping every
> adjacent polygon on their own.
>
> It also makes it easier to keep all parts together when editing as a
> multipolygon is also a relation.
>
> /Anders
>
> On 2020-12-15 09:52, Anders Torger wrote:
>
> Yes we actually have some of that up here too. I've chosen generally not
> to map it though as one cannot really verify it on the satellite photos,
> and here in the vast nature in north it's not really reasonable to visit
> all these places on foot so one have to rely on satellite photos for large
> parts of the nature.
>
> I'm quite sure that overlapping polygons is not how one is supposed to do
> it though. Soggy forests should have its own natural type, in Swedish we
> call it "sumpskog", and the best fitting OSM tag for that seems to be
> "natural=wetland; wetland=swamp".
>
> By the way, I've pushed an update of the Rimmjoáphe wetland now, removed
> the relation and made a multipolygon to span the river.
>
> On 2020-12-15 09:03, Ture Pålsson via Tagging wrote:
>
>
> 15 dec. 2020 kl. 08:26 skrev Anders Torger :
>
> And about wetlands, couldn't those be just rendered on top of forests so
> we didn't have to make these complex multipolygons?
>
>
> It does make sense to have overlapping wetland and forest, though. To take
> a swedish example: down here in 08-land (note to non-Swedes: Stockholm,
> telephone area code 08 :-) ), we get very little open bog, but a fair
> amount of soggy forest.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Joseph Eisenberg
Re; "Don't adjust your mapping to what you believe is most convenient for
data users"

I know this recommendation is unpopular with some mappers, because many of
us just want to see a good-looking map, and if it takes duplicating
relations and extra mapping work we will do it.

But remember that your time as a mapper, even though you give it to
OpenStreetMap freely, is actually valuable and should never be wasted on
doing things that can be solved by better software on the database user end
of things.

We should never ask 10,000 mappers to spend 10 hours a year each to add
something to the database which saves 10 hours of work for a database user.

Sometimes this means that the rendering on openstreetmap.org won't look
perfect, but we can expect better results in the future with more advanced
renderers. Consider for example how OpenTopoMap has really great
natural=peak and natural=saddle rendering, which uses elevation and
topography to adjust the rendering to look good with the contour lines and
different zoom levels. This is somewhat complex, but it was done by an
open-source, free map style.

Once upon a time I planned to add prominece=* tags to all the peaks in my
area so I could get good rendering results, but the solution which
OpenTopoMap uses is much better: it's fully automated and fast. Adding the
topographic prominence to every natural=peak to get better rendering is a
huge waste of mapper time, when you can instead calculate it (or better yet
the topographic isolation) at the time of rendering.

Similarly mappers shouldn't map a huge relation which includes all parts of
the water in a long river, since it is much easier to map and maintain
smaller closed ways for each short part of the river water. If database
users need one big area, they can pre-process the data to create the
polygons: don't make life harder for mappers to save the database users a
few CPU cycles.

Your time is priceless, fellow mappers. The time of database users is
usually a business expense.

-- Joseph Eisenberg

On Mon, Dec 14, 2020 at 10:44 AM Christoph Hormann  wrote:

>
>
> > Anders Torger  hat am 14.12.2020 15:49 geschrieben:
> >
> > Okay, but why does the OSM-Carto renderer, and all other renderers known
> > to man(?) make multiple text labels then, when it should be a single
> > one?
>
> OSM-Carto renders labels primarily based on the following constraints:
>
> * due to the requirement of real time updates more complex operations are
> severely restricted.  Clustering features, aggregating the clusters
> geometry-wise and labeling the aggregates are such operations.
> * we want the relationship between the data in the database and the
> rendering results to be intuitively understandable for the mapper so they
> can derive useful feedback from the map.  That also limits the complexity
> of data processing we can use.
> * like all zoomable interactive maps OSM-Carto has to deal with the
> problem that high quality labeling is zoom level dependent.  At the same
> time having different approaches to labeling at different zoom levels adds
> a lot of complexity to the style - and OSM-Carto is already one of the most
> complex map styles in existence.  Hence compromises are made that look
> better on some zoom levels than on others.
>
> As far as other map styles are concerned - i have said that before: high
> quality cartography is expensive and the bulk of the digital map market is
> low quality and low price - hence requires low costs.  And the willingness
> to engage in strategic investment in methods for high quality cartography
> in the wider OSM ecosystem as well as in the open source GIS sector is so
> far rather small.
>
> What can you do as a mapper:  Produce an accurate representation of the
> geography that is non-complex in structure, is easy for you to map and
> maintain and that is consistent with how others map things and don't adjust
> your mapping to what you believe is most convenient for data users.
>
> --
> Christoph Hormann
> https://www.imagico.de/
>
> ___
> 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] How to tag entire group of rentable holiday cottages?

2020-12-14 Thread Joseph Eisenberg
I suppose we also lack a way to distinguish extended-stay hotels which are
designed for 1 week to multi-month stays;

https://en.wikipedia.org/wiki/Apartment_hotel

" There are currently 27 extended stay chains in North America with at
least 7 hotels, representing over 2,000 properties.[*citation needed
<https://en.wikipedia.org/wiki/Wikipedia:Citation_needed>*] There is
substantial variation among extended stay hotels with respect to quality
and the amenities available. Some of the economy chains attract clientele
who use the hotels as semi-permanent lodging. Extended-stay hotels
typically have self-serve laundry facilities and offer discounts for
extended stays, beginning at 5 or 7 days. They also have guestrooms (or
"suites") with kitchens. The kitchens include at a minimum usually: a sink,
a refrigerator (usually full size), a microwave oven, and a stovetop. Some
kitchens also have dishwashers and conventional ovens. Extended stay hotels
are aimed at business travelers on extended assignments, families in the
midst of a relocation, and others in need of temporary housing."

-- Joseph Eisenberg

On Mon, Dec 14, 2020 at 12:14 PM Paul Allen  wrote:

> On Mon, 14 Dec 2020 at 19:41, Jmapb  wrote:
>
>>
>> At least In the rural USA, there's a continuum between motels that have
>> an array of rentable rooms in one or two buildings and those where each
>> room is an individual cabin, or sometimes half of a duplex cabin. It's
>> common to see motels offering both styles of accommodation.
>>
>
> I don't think tourism=chalet fits that distributed motel cabin model.
>
> I'd expect a motel to be set up to handle very short duration (one or two
> day) at very short notice (turn up and ask for a room) and to offer
> meals unless there are diners/restaurants nearby.  Groups of
> holiday cottages are generally longer duration (minimum one week
> except by special arrangement) and generally longer notice
> (usually months, although there may be last-minute deals
> if they have a cancellation).  Holiday cottages are self-catering.
> You can go to a restaurant or diner but you have fairly
> comprehensive cooking facilities (more than just a microwave).
>
> I know that there are blurry edges to everything, but I can't
> fit a group of holiday cottages into my mental model of a hotel.
> Take a look at https://www.canllefaes.com/ and note the
> requirement that occupancy start/end on a Saturday,
> that the cottages have kitchens, etc., and tell me if
> that fits into your model of a motel with distributed
> cabins.
>
> --
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Joseph Eisenberg
Re: "if a reservoir was fenced off, I would tag the fenced area as
landuse=reservoir but only the actual water surface as water."

There is also a more specific tag for this:
https://taginfo.openstreetmap.org/tags/?key=landuse=reservoir_watershed#overview
- though most uses were added by an import in 2011
-  landuse=reservoir_watershed:
https://wiki.openstreetmap.org/wiki/Tag%3Alanduse%3Dreservoir_watershed

-- Joseph Eisenberg

On Sun, Dec 13, 2020 at 10:56 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 13. Dec 2020, at 18:49, Tomas Straupis  wrote:
>
>  Introducing duplicate and unused schema (especially as the only
> option) is not a good IT decision, basic analysis should have shown
> that. But in case of id it was technology leading functionality and
> thus leading users when in IT it must be the other way round -
> usage/requirements must lead technical decisions. That is IT BASICS.
> Lack of such understanding is the reason why I claim iD developers
> lacked basic IT knowledge
>
>
>
> it is indeed well documented that there was a period in iD development
> where the developers occasionally  (initially without actively
> communicating it and later openly and deliberately) dismissed the existing
> tagging wiki docs and mailing list and tag stats, but I think it should be
> mentioned that it was the former developer. Brian, maybe this was before
> you started to follow the lists. You can browse through older closed iD
> tickets to see some discussion, there’s also a wiki page about the topic:
> https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions
>
> regarding water=reservoir or landuse=reservoir, there might be some subtle
> differences. water=reservoir is for surface water areas. if a reservoir was
> fenced off, I would tag the fenced area as landuse=reservoir but only the
> actual water surface as water.
>
> 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] How to put a name tag on an area with more than one type?

2020-12-13 Thread Joseph Eisenberg
Currently the features with the tag "name=Kebnekaise" are 2 ways which
extend north-south and to the west from these two peaks and are also tagged
natural=arete (an arete is a knife-edged ridge formed between 2 glaciers).

https://www.openstreetmap.org/way/123215393#map=13/67.8934/18.4509=C
https://www.openstreetmap.org/way/407174801#map=14/67.8999/18.5215=C

Is this correct based on your local knowledge of the area?

If in fact Kebnekaise is the name of the ridges or aretes, then this is a
good way to represent the name of the "mountain" which in this case appears
to be a thin ridge between glaciers.

Note that Opentopomap handles this fairly well:
https://www.opentopomap.org/#map=14/67.90026/18.50553 and
https://www.opentopomap.org/#map=13/67.90113/18.46716

I believe OpenTopoMap also renders natural=mountain_range ways:
https://www.opentopomap.org/#map=12/38.4613/-4.1566

OpenTopoMap uses a special script to assign an isolation value to each
peak: that is, how far is it away from another natural=peak (or
natural=volcano) with a larger elevation value? If it is a long way, the
peak will be rendered even at low zoom levels (large scales), for example:
https://www.opentopomap.org/#map=7/67.900/18.479

This hasn't been implemented in the OpenStreetMap-Carto style because it is
somewhat complicated and might have performance problems and there are
issues with using more pre-processing of the raw data when it comes to
mapper feedback, but the code used by OpenTopoMap is here:
https://github.com/der-stefan/OpenTopoMap/pull/129 and
https://github.com/der-stefan/OpenTopoMap/pull/130  if anyone else wants to
implement this for their own maps.

-- Joseph

On Sun, Dec 13, 2020 at 12:14 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 13, 2020, 19:58 by and...@torger.se:
>
> Do you have a suggestion of how to map Sweden's highest mountain,
> Kebnekaise?
>
> The mountain is called Kebnekaise, it has two peaks, one is called
> "Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north peak").
>
> I admit that I have no good idea, if I would run into such case and failed
> to find a better idea
> (hopefully one will come) I would invent a new way to tag that.
>
> natural=mountain? Main problem is where to put it - node at arbitrary
> position between peaks?
> Node at location of highest peak? Area? Relation? All of that is sadly
> problematic.
>
> (The mountain_range tag is a great tag, but I note that its status is just
> "in use", it's not an approved tag :-O.)
>
> It is perfectly fine to use tags that never went through tagging proposal,
> though
> I am not going to endorse this one. Tagging mountain ranges seems to
> poorly fit OSM
> with multiple different opinions where mountain range starts/ends and
> inability to
> verify it by survey.
>
> All tags were in some stage rarely used before becoming heavily used,
> only some cases went through a proposal process.
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Joseph Eisenberg
Re: "that schema was lying dead until iD decided to introduce it as the
only way to tag water"

That's not really correct when it comes to landuse=reservoir

In this case, landuse=reservoir growth slowed down in 2016 for reasons that
are unclear to me:

Compare the charts:
https://taghistory.raifer.tech/#***/landuse/reservoir&***/water/reservoir

Until mild 2016 landuse=reservoir was still increasing as fast or faster
than water=reservoir
But 5 years after the water proposal was approved, this changed:
water=reservoir continued increasing linearly, but landuse=reservoir slowed
down to half the prior rate.

It's fair to say that between mid 2016 and mid 2019, water=reservoir was
twice as popular as landuse=reservoir for adding new features

Then of course the change to the iD Editor in mid 2019 caused another
inflection and landuse=reservoir started decreasing, but the water=* schema
was not "lying dead" in this case, it was already more popular.

Perhaps you are instead remembering the situation with waterway=riverbank
vs water=river. In that case it appears that iD really did start the main
change, because waterway=riverbank continued to be equally popular or more
popular than water=river for new features until mild-2019 (except perhaps
during 2017 for some reason?):
https://taghistory.raifer.tech/#***/water/river&***/waterway/riverbank

I would be more irritated about an attempt to deprecate waterway=riverbank,
because in that case there is more risk of information loss: a reservoir
and natural=water are both historically defined as standing fresh water and
in most cases will be rendered the same (though having the information if a
lake is natural or artificial is still important). But a river is flowing
water and is often rendered differently, and tagging as natural=water risks
losing this information invisibly, if the water=river tag is accidentally
or intentionally deleted - this is partially the fault of
OpenStreetMap-Carto for not yet rendering any difference between rivers and
standing water.

-- Joseph Eisenberg

On Sun, Dec 13, 2020 at 9:49 AM Tomas Straupis 
wrote:

> 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> > New/duplicate schema with water=reservoir only launched because iD
> > coders decided to skip standard IT processes of product development
> > (or were not familiar with the basics of IT) and simply went for what
> > they personally liked, not what was better
> >
> > This is 100% untrue, and you insult people. Stop making such things.
> >
> > For start, iD authors (also ones that made decisions about tagging
> > presets that I consider to be mistakes and going against consensus)
> > had no problem with basics of IT and IT processes of product development.
> >
> > water=reservoir was launched (created) in 2011
> > see https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
> > iD started in 2012 ( https://wiki.openstreetmap.org/wiki/ID )
>
>   Mateusz, can you point out which of my claims is a lie?
>   I didn't say iD invented duplicate schema, I said that schema was
> lying dead until iD decided to introduce it as the only way to tag
> water, introduction "launched" new water schema adding any
> considerable usage (as it was the only option for iD mappers).
>
>   Introducing duplicate and unused schema (especially as the only
> option) is not a good IT decision, basic analysis should have shown
> that. But in case of id it was technology leading functionality and
> thus leading users when in IT it must be the other way round -
> usage/requirements must lead technical decisions. That is IT BASICS.
> Lack of such understanding is the reason why I claim iD developers
> lacked basic IT knowledge.
>
> > , and introduced
> > water=reservoir as the only way to tag, all this at the time when
> > water=reservoir usage was close to zero!
> >
> > See https://taginfo.openstreetmap.org/tags/water=reservoir#chronology
> >
> > Usage in January 2019 was about 200 000 already.
> >
> > "water=reservoir usage was close to zero" is untrue
>
>   Key word "introduced" so it is 2012, not 2019.
>   water=reservoir usage in 2012 is close to zero.
>
> > It is deprecated by 2011 proposal, see
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation
>
>   The author of this proposal agreed that standard water schema is NOT
> deprecated. And a few people voting in wiki cannot deprecate a tag.
> Only people actually mapping can do that.
>
> > BTW, you are AGAIN spreading false statements and claim that iD
> > invented water=reservoir. Please stop doing this.
>
>   Do not copy/paste my words in random order and you will not get such
> claims from me :-)
>

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Joseph Eisenberg
1) To tag a named "Torp" it sounds like there are several different correct
options, depending on what currently exists at the location.

If there is a single family home or a couple of homes used as residences,
it would be a place=isolated_dwelling mapped as a node at the centre.

If it is still used as a farm, then place=farm can be used on a node
instead. This is treated as similar to place=isolated_dwelling by many data
users. It is also possible to map the area of the farmyard (around the
buildings) as landuse=farmyard and add the name to this feature, if the
name is only for the actual farm buildings and not for all the surrounding
areas.

For a named settlement with more than 2 families (but smaller than a
village), place=hamlet on a node would be appropriate. I'm not sure if a
torp is every that large?

If the torp is no longer inhabited, you can use a lifecycle tag to show
this: e.g. abandoned:place=farm or abandoned:place=isolated_dwelling or
abandoned:place=hamlet show that a former farm or small settlement are now
abandoned and no longer inhabited.

2) For a mountain:
Most mountains share a name with their highest peak, so natural=peak is a
great way to tag these.

But it's true that some "mountain" names are not the name of a peak. In
this case there are a couple other tags in use: natural=ridge is used with
a linear way which is drawn along the ridgeline. This works for many named
single ridges. https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge -
example here: https://www.opentopomap.org/#map=15/41.76382/-123.18038 -
https://www.openstreetmap.org/way/631166206/#map=13/41.7664/-123.1567=C

Sometimes a named "mountain" is not a single ridge but a whole range of
connected ridges. In this case we usually call it a "mountain range" in
English, and there is a somewhat uncommon tag for this
natural=mountain_range which I've used to map some ranges in my area. This
tag is harder to use. In some cases the best option is to use it on a node
at the center of the mountain range, in others it is possible to use it on
a linear way along the highest line of ridges at the center of the mountain
range. https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dmountain_range -
example:
https://www.openstreetmap.org/way/686647385#map=12/42.0515/-122.7575=C

While we can all disagree on how far down into the valley the mountain
extends, everyone agrees that the highest peak is part of the mountain, so
mapping peaks of a mountain as a node is 100% verifiably to be correct. In
some cases a linear way is also verifiable for a ridge or a linear mountain
range.

-- Joseph Eisenberg


On Sun, Dec 13, 2020 at 7:04 AM Ture Pålsson via Tagging <
tagging@openstreetmap.org> wrote:

>
> 13 dec. 2020 kl. 15:21 skrev Paul Allen :
>
>  I'm probably misunderstanding this, but torp doesn't seem to be a type of
> building.  The tag building=torp says that this building IS a torp (as
> opposed to a house, or a shop, or a garage, or a shed, or a barn).
> If you feel a need to indicate that a building was once part of a torp,
> building=torp isn't the way to do it.
>
>
> You’re right; I was extremely sloppy with terminology there. A torp is (or
> rather was) a small farm, usually either part of a bigger farm and farmed
> by a tenant, paying rent to the bigger farm in the form of work, or farmed
> by a soldier (paying rent by, well, being a soldier). Today, most of them
> are either completely gone or used as summer houses, very probably not with
> the original building.
>
> I suppose what I wanted to say was:
>
> * place=locality is used about all sorts of things, both inhabited and
> uninhabited, and is pretty much useless.
>
> * There are many places around Sweden (and probably the rest of the world
> as well!) where there is just forest (or fields) today, that have a name
> because they were, at some time, a torp (or some other kind of settlement).
> To render these in ”swedish topo-map style” (i.e, italics), some sort of
> tagging is needed to say ”this place has a name because it used to be a
> farm/torp/whatever, but today there is nothing here”. (I suppose some would
> argue that these should not be in OSM at all, because they are very hard to
> verify on the ground).
>
> * There are also isolated dwellings, hamlets, villages, suburbs and
> airport car parks (comparing old and present-day maps around
> Stockholm-Arlanda airport is quite fun) whose names refer to long-gone
> torps, but those can be tagged according to their present-day usage.
>
> And I’d like to apologize to Anders for derailing this thread by bringing
> up the subject at all! It was intended as an illustration of the
> uselessness of locality, but I got a bit carried away. Trying to render
> consistent maps from inconsistent OSM data does tha

[Tagging] Is landuse=conservation actually deprecated?

2020-12-13 Thread Joseph Eisenberg
Recently another wiki user marked landuse=conservation as "deprecated" on
the Map Features page:
https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:landuse=11273=2071912=2068278

This same user had marked the page itself as deprecated back in 2017:
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Alanduse%3Dconservation=revision=1498145=387459

Previously the Tag:landuse=conservation page had been redirected to a
proposal since 2009:
https://wiki.openstreetmap.org/wiki/Proposed_features/conservation

*"Conservation land is land protected from development.*

*It is left in more or less a natural state.*

*It is often maintained to a very limited extent, such as annual mowing to
prevent forest growth, removal of invasive species, replanting, or dealing
with or preventing erosion.*

*The public typically, but not always, has access, as it is a valuable
recreational resource. (Sometimes the public has no physical way of getting
to it, or is not allowed for water protection reasons, safety, etc)."*
Now boundary=protected_area is probably the more common way to tag this
concept.

Comparison:
https://taginfo.openstreetmap.org/compare/boundary=protected_area/landuse=conservation

landuse=conservation is declining since 2015:
https://taginfo.openstreetmap.org/tags/landuse=conservation#chronology

While boundary=protected area mostly increases, though there are some jumps
up and down from imports I imagine:
https://taginfo.openstreetmap.org/tags/boundary=protected_area#chronology

Is it correct to say that landuse=conservation has been deprecated,
practically, by boundary=protected_area
<https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area>, even
though that tag has not been approved?

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


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-11 Thread Joseph Eisenberg
But a Russian naval base would presumably be tagged "operator=Военно-морской
флот" - if you do not read the Cyrrillic alphabet this is illegible. In
Japan it would be "operator=海上自衛隊"

All names are opaque to computers, so we use standardized tags which can be
translated one time, instead of needing to translate an operator=* tag for
every language and every country to make it usable.

While some militaries have unusual divisions, the presence of an army, air
force and navy is quite common for large countries, and it's fine if the
list of values is a little longer to fit in the silly ones like
"military_service=space_force".

-- Joseph Eisenberg

On Fri, Dec 11, 2020 at 2:06 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 10. Dec 2020, at 22:55, Graeme Fitzpatrick 
> wrote:
> >
> > military_service=army
>
>
> do we really need military_service=army given that these services will
> differ according to the country? We can tag operator =United States Army or
> “United States Marine Corps” and keep lists in the wiki for standardized
> names of these structures in all countries, without having to decide which
> “box” they have to be put in.
>
> 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] Proposed feature - RFC - Military Bases

2020-12-10 Thread Joseph Eisenberg
Wikipedia says: "The British Armed Forces, also known as Her Majesty's
Armed Forces, are the military services responsible for the defence of the
United Kingdom"... so perhaps the best British term is "military service"?

The Wikipedia pages on the Royal Navy, Royal Air Force and British Army use
"military service" sometimes too, and mention the overall "British Armed
Services", "Her Majesty's Naval Service", etc.

Disclaimer: I don't speak the British dialect of English (aka "Her
Majesty's English?" :-) )

-- Joseph Eisenberg


On Thu, Dec 10, 2020 at 3:55 AM Paul Allen  wrote:
>
> On Thu, 10 Dec 2020 at 07:28, Joseph Eisenberg 
wrote:
>>
>>
>> So I suggest military_branch=* or military_service=* for the key.
>>
>> Though this is based on my US English understanding of the military
terminology. Do they call them "military service branches" in British
English too?
>
>
> "British Armed Forces."  More formally, "Her Majesty's Armed Forces."  See
> https://en.wikipedia.org/wiki/British_Armed_Forces  Not a suitable term
for use
> outside of the UK.  "Armed Forces" would be applicable outside the UK but
> I'm not sure how well it would be understood by, say, the US.  The
Wikipedia
> article says that British Armed Forces are the military services in the
UK,
> so military_service might be the best option.  OTOH, the sidebar of
> that article refers to the Navy, Army and Air Force as service branches,
> so military_branch or military_service_branch would probably work.
>
> --
> 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] Proposed feature - RFC - Military Bases

2020-12-09 Thread Joseph Eisenberg
>From the talk page:

> "Base" can have different meanings in different contexts. At some future
point we might regret having defined base=* to mean military bases. Maybe
military_base=*. --Brian de Ford (talk) 12:12, 9 December 2020 (UTC)

I agree, and this can be easily fixed by changing the key to describe what
we are actually specifying: "What military service branch is using this
feature?"

So I suggest military_branch=* or military_service=* for the key.

Though this is based on my US English understanding of the military
terminology. Do they call them "military service branches" in British
English too?

This would also solve the issue of using base=army + military=office or
base=marines + military=danger_area, which would otherwise seem odd.

There are, in fact, military offices which are not within a
landuse=military area, and there are military=danger_area features which
are not in landuse=military

e.g: https://www.openstreetmap.org/way/315105891,
https://www.openstreetmap.org/way/26165183 (danger_area)
https://www.openstreetmap.org/way/151330951,
https://www.openstreetmap.org/way/485899442 (office)

-- Joseph Eisenberg

On Tue, Dec 8, 2020 at 3:36 PM Graeme Fitzpatrick 
wrote:
>
> I've now incorporated all (I think?) the comments from the talk page into
the proposal, if you'd like to check the wording?
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Military_bases
>
> Thanks
>
> Graeme
>
>
> On Wed, 9 Dec 2020 at 09:32, Graeme Fitzpatrick 
wrote:
>>
>>
>> On Wed, 9 Dec 2020 at 08:37, Martin Koppenhoefer 
wrote:
>>>
>>>
>>> military bases might house intelligence facilities which are known and
could be tagged.
>>
>>
>> They could, if you can identify them, but as mentioned above, should we
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


[Tagging] Feature Proposal - RFC - Tag:healthcare=vaccination_centre

2020-12-09 Thread Joseph Eisenberg
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:healthcare%3Dvaccination_centre

healthcare=vaccination_centre "A healthcare facility where people are
vaccinated"

The tag healthcare=vaccination_centre is proposed to map a vaccination
centre: a healthcare facility specifically dedicated to administering
vaccinations to individuals, to provide immunisation against infectious
diseases. This tag should be used for locations which are specifically
designed or designated for vaccination, and which are not a general clinic,
hospital or doctor's office (which already have tags). These centres may be
located in permanent structures and intended for long-term use for multiple
vaccination programs, or might be semi-permanent or short-term facilities
located in tents or other mobile structures which are designed for a single
vaccination campaign.

It may be used with the recently proposed tag vaccination=* (which looks
like it will be approved this week - voting is ongoing) which can specify
the specific vaccination or vaccinations which are available at the
location, e.g. vaccination=covid-19.

Other facilities also administer specific vaccinations in addition to their
primary healthcare purpose as a hospital, clinic, doctor's office,
midwife's office, nurse post, etc. These should be tagged with the tag
appropriate for the primary feature, such as amenity=hospital,
amenity=clinic, amenity=doctors, healthcare=midwife, healthcare=nurse, etc.
- in contrast, this new tag is for dedicated vaccination centres.

Please comment on the proposal discussion page (
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Tag:healthcare%3Dvaccination_centre)
or here.

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


Re: [Tagging] edit war related to tagging of a bus-only major road

2020-12-09 Thread Joseph Eisenberg
There is also a proposed tag, which is now being used, for highway=busway -

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:highway%3Dbusway

But that proposal mentions:

"The current tagging scheme for this type of roadway is highway
<https://wiki.openstreetmap.org/wiki/Key:highway>=service
<https://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice>, access
<https://wiki.openstreetmap.org/wiki/Key:access>=no
<https://wiki.openstreetmap.org/wiki/Tag:access%3Dno>, bus
<https://wiki.openstreetmap.org/wiki/Key:bus>=designated, sometimes using
also service <https://wiki.openstreetmap.org/wiki/Key:service>=busway
<https://wiki.openstreetmap.org/wiki/Tag:service%3Dbusway>."

I would support establishing this tag highway=busway for roadways which are
exclusively for the use of buses.

-- Joseph Eisenberg

On Wed, Dec 9, 2020 at 6:39 AM Michael Tsang  wrote:

> Dear all,
>
> I'm working with some roads in Central area in Hong Kong. Des Voeux Road
> Central is considered one of the most important roads in the area which I
> tagged it as highway=secondary, however another editor has repeatedly
> changed
> it to highway=service on the fact that that road is closed to motor
> vehicles
> except buses. An edit war has appeared.
>
> Here is the relevant changesets and ways:
> https://www.openstreetmap.org/changeset/94428780#map=17/22.28199/114.15872
> https://www.openstreetmap.org/way/242113655#map=17/22.28168/114.15911
> https://www.openstreetmap.org/changeset/95558773
>
> According to the wiki description of highway=secondary, such road "is not
> part
> of a major route, but nevertheless forming a link in the national route
> network." Des Voeux Road Central (between Queensway and Pottinger Street)
> is
> such a highway for buses only. Tens of bus routes are using this road to
> serve
> passengers between Wan Chai to Central, while other motor vehicles must
> use
> the other highways in the region (also tagged as highway=secondary).
>
> However, a highway=service is "generally for access", and also "for access
> for
> parking, driveways and alleys". Des Voeux Road Central is definitely not
> the
> case here. It is instead a major road in the road network usable by buses.
>
> What should I do here now?
>
> Michael
> --
> Sent from KMail___
> 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] Drawing/painting schools

2020-12-08 Thread Joseph Eisenberg
Yes, amenity=art_school appears to be the most common way to map places
that offer training in the visual arts.

— Joseph Eisenberg

On Tue, Dec 8, 2020 at 4:06 PM Shawn K. Quinn  wrote:

> On 12/8/20 16:12, Hauke Stieler wrote:
> > Hi,
> >
> > today I encountered a drawing/painting school [0] that offers workshops
> and
> > classes for children and adults. Is there a tag for these schools? I
> haven't
> > found any, so how about establishing amenity=painting_school (or
> > =drawing_school?) analogous to amenity=music_school. Any thoughts on
> that?
> >
> > Hauke
>
> How about amenity=art_school, with another tag to indicate the specific
> disciplines of art being taught?
>
> --
> Shawn K. Quinn 
> http://www.rantroulette.com
> http://www.skqrecordquest.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] Proposed feature - RFC - Military Bases

2020-12-07 Thread Joseph Eisenberg
This is an interesting idea.

But the current proposal only provides a way to tag the military service
branch of a military=base feature (which is usually also landuse=military).

It might be better if there were a way to tag the branch for any sort of
military feature, including military=office, military=danger_area
<https://wiki.openstreetmap.org/wiki/Tag%3Amilitary%3Ddanger_area>,
military=barracks, and so on.

-- Joseph Eisenberg

On Mon, Dec 7, 2020 at 4:22 PM Graeme Fitzpatrick 
wrote:

> Following on from comments made in regard to deprecating both emergency= &
> amenity=coast_guard & replacing them with military=coast_guard:
>
> On Mon, 7 Dec 2020 at 02:01, Brian M. Sperlongano 
> wrote:
>
>> This is probably a US-centric viewpoint, but I note that there is a
>> general lack of tagging under the military= key to indicate the military
>> branch associated with a military base.  For example, we have
>> military=naval_base, but no equivalent tagging for army, air force,
>> amphibious, (dare I say space force?) bases.  In places where the coast
>> guard IS part of the military, tagging it under landuse=military +
>> military=* is appropriate.  However, I also support the need to tag coast
>> guard areas in places where they are considered non-military and thus
>> landuse=military would not be appropriate.
>>
>
> On Mon, 7 Dec 2020 at 04:18, Martin Koppenhoefer 
> wrote:
>
>>
>> yes, a documented way to distinguish "finer" details are missing not only
>> for military branches, the same holds true for police branches and other
>> law enforcement and border / tax etc. control.
>>
>
> I have just posted a new proposal re Military Bases:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Military_bases
>
> Please have a read & comment either here or on the discussion page.
>
> 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 - Military=Coast-Guard & Rescue=Marine_Rescue

2020-12-06 Thread Joseph Eisenberg
Please be aware of a couple of other existing tags:

emergency=water_rescure_station - used 300 times and documented -
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dwater_rescue_station

emergency=lifeguard_base - used over 300 times -
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dlifeguard_base

Also emergence=lifeguard_tower, emergency=lifeguard_platform,
emergency=lifeguard are all documented -
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dlifeguard

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


Re: [Tagging] Feature Proposal - RFC - Hazards

2020-12-05 Thread Joseph Eisenberg
The solution to the lack of official signs is to petition your local
government to add the signs or pavement markings or some other visible
warning of the hazard. This will have much more real-world impact than
adding a tag to OpenStreetMap. And it will make it possible to verifiably
add the tag of the hazard.

In my part of the world, cyclists sometimes spray-paint the pavement with
warnings to mark the location of hazards like tree roots or pot-holes or
dangerous crossings. While these are not official markings, they exist and
are verifiable, so they could also be mapped.

(Before considering heading out with a can of spray-paint, please check
your local vandalism legislation... :-) )

-- Joseph Eisenberg

On Sat, Dec 5, 2020 at 9:43 AM Volker Schmidt  wrote:

> Hi,
> I have been following this proposal with interest. I often have tried to
> tag hazards, and not found a good ways of doing it.
> We are now compiling a long list of hazards, including golf players
> crossing the road, but I see some basic aspects which are not being
> addressed (unless I missed something):
>
> I would like to see signposted hazards completely separately tagged from
> hazards that the mapper perceives in a place, but which are not signed.
>
> Signed hazards should be mapped.
>
>- on nodes, if the extension of the hazard is point-like (example:
>dangerous railway crossing)
>- on ways, if the hazard exists along a highway (example: animals
>crossing zones)
>- (possibly) on areas, if the hazard is present in an area (example:
>landslides)
>
> In the case of signed hazards, I see two alternative ways of tagging the
> signing:
>
>- (only for nodes and ways highway segments) by adding source:xxx=sign
>like we do with speed limits
>- by mapping the relative signs as nodes
>
> Insertion of signposted hazards do not require any assessment of the
> presence of the hazard by the mapper.
>
> Signposted hazards are most often signalling dangers for vehicle drivers.
> Let's take the sign for hazard=cyclists (crossing), which warns clearly the
> vehicle drivers on the carriageway, that there could be cyclists crossing.
> There is normally no such warning on the crossing cyclists' path.
> There are exceptions of hazard warnings for both parties like a "cyclists
> sharing the road" sign, but that's the only one that comes to mind.
>
> Another aspect that should be defined: Are writings or pictograms on the
> road surface equivalent to vertical traffic signs?
>
>
> A completely different story are unsigned hazards with no signs on the
> ground, i.e. situations perceived as a hazard by the mapper.
> These are the tricky ones. I map cycling infrastructure, hence my examples
> come from that perspective.
> Examples:
>
>- foot-cycle crosswalks where there is a sign-posted speed limit of
>30km/h, but where 90% of the cars pass with speeds far exceeding that value
>and making the place really dangerous
>- a two-way cycle path that is parallel to a main road and crosses  a
>side road with a foot.bicycle crosswalk - car drivers entering the side
>road regularly overlook cyclists which ride in the same direction as they
>drive (to my knowledge the major cause of cyclists being killed in many
>countries. These in most cases in my part of the world have no danger
>signs.
>- And now consider the same situation with a row of trees between the
>cycle path and the main carriage way.
>- In my part of the world authorities put all kinds of bollards,
>arches, chicanes on cycleways (supposedly for the safety of cyclists, but
>in reality to keep car drivers from parking there). Many of these are grey
>metal objects that become invisible at night even if you have a good cycle
>light, as they have no reflective markers on them.
>
> The problem here is that the tagging will be based on my perceived version
> of ground truth. If I am a cyclist, I may be good at spotting hazards for
> cyclists. If I am a horse rider I will be good at mapping hazards for horse
> riders.
>
> Then we have also the asymmetric situations: e.g. car drivers are warned
> by a sign that there will be cyclists crossing, but the (bigger) hazard of
> cars hitting the cyclists on the same crossing is not signposted for
> cyclists.
>
> Volker
>
>
> On Sat, 5 Dec 2020 at 17:05, ael via Tagging 
> wrote:
>
>> On Fri, Dec 04, 2020 at 09:48:27PM +, Paul Allen wrote:
>> > On Fri, 4 Dec 2020 at 19:56, Martin Koppenhoefer <
>> dieterdre...@gmail.com>
>> > wrote:
>> >
>> > Up until around ten years ago, a minor road went past the end of the
>> > runway at what passes for an airport.  The plane

Re: [Tagging] Inclined elevators

2020-12-04 Thread Joseph Eisenberg
I agree that the indoor or semi-indoor inclined elevators, which are fully
enclosed and look completely similar to a vertical elevator, should be
tagged as highway=elevator.

Once they are outdoors and there are visible tracks it gets ambiguous.

Since the Montmarte "funicular" is tagged as railway=funicular even though
the pairs cars are now no longer connected to one cable, I think we can
edit the Tag:railway=funicular page to mention that the tag is also used
for similar cable-driven inclined railways which are not technically
funiculars, but looks the same to the non-expert.

-- Joseph Eisenberg

On Fri, Dec 4, 2020 at 3:30 PM Guillaume Chauvat 
wrote:

> Sorry for spamming.
>
> I also think it's fine if the Montmarte funicular is tagged as a
> funicular. But I'm asking because of things that are clearly elevators,
> like this one:
> https://www.alamy.com/stock-photo-tekniska-hgskolan-metro-station-stermalm-district-stockholm-sweden-41948022.html
> . It goes on a path parallel to the escalators, not vertically (I have been
> inside). To me it looks very wrong to call this a funicular. But maybe
> others disagree...
>
> Guillaume
>
> On 2020-12-05 00:07, Clay Smalley wrote:
>
> On Fri, Dec 4, 2020, 5:00 PM Joseph Eisenberg 
> wrote:
>
>> The wiki page text says that a railway=funicular is "A funicular, also
>> known as an inclined plane or cliff railway, is a cable railway in which a
>> cable attached to a pair of tram-like vehicles on rails moves them up and
>> down a steep slope, the ascending and descending vehicles counterbalancing
>> each other.”
>>
>> However, the description in the infobox (which is much more commonly seen
>> in places like taginfo and iD) is only “Cable driven inclined railway” -
>> and this could include many types of "inclined elevators” which mostly run
>> on rails too. So mappers might be using railway=funicular for inclined
>> elevators already.
>>
>
> Indeed they are. For example, here's the Montmartre Funicular in Paris,
> which was historically a true funicular but is now technically a pair of
> inclined elevators: https://www.openstreetmap.org/way/29403578
>
> The distinction between a funicular and an inclined elevator is to me a
> technical one. Many inclined elevators, like the previous example, are
> named as funiculars, and passengers may not even notice that they are on
> one or the other - for all they know, they're just on a vehicle going up
> and down steeply sloped rails.
>
> I'm in favor of tagging inclined elevators as funiculars whenever they may
> resemble one. Perhaps an additional tag like
> railway:funicular=inclined_elevator could be invented for those interested
> in the technical details on how the steep-slope-railway-thing works.
>
> -Clay
>
>>
> ___
> 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] Inclined elevators

2020-12-04 Thread Joseph Eisenberg
I've looked into these.

Most inclined elevators seem to also operate with cables, with the
difference being that in a funicular there are 2 cars attached to 1 cable,
so one ascends while the other descends, but in an inclined elevator each
car (or there might only be 1 car) is attached to a counterweight or a
winch.

Unfortunately it looks like most uses of the tag highway=elevator on a way
are actually areas (closed ways):
https://overpass-turbo.eu/s/10S8 - 3080 highway=elevator ways are closed. A
review of a few of these suggests they are mostly 4 node rectangular ways
which represent the area of a verticle elevator. About half are tagged
indoor=room - https://overpass-turbo.eu/s/10Se
vs
https://overpass-turbo.eu/s/10S9 - 190 ways which are not closed. These
look to be inclined elevators, though in some cases it’s not possible to
tell if they might actually be a funicular instead.

While railway=funicular is 10 times as common, this might or might not
represent the actual relative frequency of these features in the real
world, I don’t know.

The wiki page text says that a railway=funicular is "A funicular, also
known as an inclined plane or cliff railway, is a cable railway in which a
cable attached to a pair of tram-like vehicles on rails moves them up and
down a steep slope, the ascending and descending vehicles counterbalancing
each other.”

However, the description in the infobox (which is much more commonly seen
in places like taginfo and iD) is only “Cable driven inclined railway” -
and this could include many types of "inclined elevators” which mostly run
on rails too. So mappers might be using railway=funicular for inclined
elevators already.


-- Joseph Eisenberg

On Thu, Dec 3, 2020 at 2:55 PM Graeme Fitzpatrick 
wrote:

>
>
> On Fri, 4 Dec 2020 at 08:33, Guillaume Chauvat 
> wrote:
>
>> Yes, but this is a node, not a way. Inclined elevators require a way and
>> those are not displayed properly.
>>
>
> Sorry, didn't get what you were getting at!
>
> 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 - Hazards

2020-12-04 Thread Joseph Eisenberg
While hazard=yes is certainly in use (like barrier=yes and even
amenity=yes), it shouldn't be included in the proposal.

In every case it will be more helpful if users make up a new tag. If there
is a sign warning of monkeys which are prone to steal tourist's purses,
then hazard=purse_pilfering_primates is better than hazard=yes, since it
immediately make it possible for other mappers and database users to get
some idea about the kind of hazard.

The current mention of hazard=yes in addition to another main tag, like
man_made=adit + hazard=yes, is not terrible, though man_made=adit +
hazard=collapse or hazard=toxic_air would be clearer - it's not always
obvious which kind of hazard to expect.

-- Joseph Eisenberg

On Fri, Dec 4, 2020 at 12:38 PM Brian M. Sperlongano 
wrote:

> There's a few usages of hazard=golf_balls, which is more like what you're
> describing and actually a hazard.  It seems a bit nebulous, but perhaps the
> sign could be mapped.  That's different from a golf crossing, which is a
> place where golfers and golf carts would cross a road.
>
> I've already added hazard=low_flying_aircraft as was previously suggested.
>
> And with regard to the generic hazard sign, there is always the generic
> catch-all of hazard=yes!
>
> Thanks for the link to the directory of German signs.  I think most of
> them are covered, though there's a few outliers.  I'm trying to err on the
> side of defining fewer values to make sure that we don't end up duplicating
> something that exists elsewhere (for example, in the cases of
> highway=crossing and traffic_calming=* which are both often signed as
> hazards).  Essentially my net is "values that have high existing usage plus
> values that people feel strongly about including".
>
>
>
> On Fri, Dec 4, 2020 at 2:56 PM Martin Koppenhoefer 
> wrote:
>
>> sent from a phone
>>
>> > On 4. Dec 2020, at 17:42, Brian M. Sperlongano 
>> wrote:
>> >
>> > I am thinking this case (crossing golfers) is more of a
>> highway=crossing rather than a hazard?
>>
>>
>> I think it is a warning that a golf ball might eventually hit your
>> vehicle, and if you’re prepared you won’t be startled
>>
>> There is also the crossing airplane hazard, even 2 variants, airplanes
>> from the right:
>>
>> https://commons.wikimedia.org/wiki/File:Zeichen_101-10_-_Flugbetrieb,_Aufstellung_rechts,_StVO_2017.svg
>> and from the left:
>>
>> https://commons.wikimedia.org/wiki/File:Zeichen_101-20_-_Flugbetrieb,_Aufstellung_links,_StVO_2017.svg
>>
>> They do not imply that you have to fear airplanes on the street, they
>> are meant to prepare you for low flying aircraft.
>>
>> A picture list of all German "standard hazards" can be found here:
>>
>> https://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_der_Bundesrepublik_Deutschland_seit_2017#Gefahrzeichen_nach_Anlage_1_(zu_%C2%A7_40_Absatz_6_und_7_StVO)
>> but with this  sign
>>
>> https://commons.wikimedia.org/wiki/File:Zeichen_101_-_Gefahrstelle,_StVO_1970.svg
>> in combination with a text sign, any hazard can be signposted.
>>
>> These are only the official road signs, on footways and private
>> properties, information signs etc., you might find all kind of other
>> hazard warnings. Is the tag only thought for roads and official road
>> signs, or is its scope extended to other official signs (e.g. in some
>> forests, there are "Rabies prone area" official signs, military areas
>> might warn with "restricted area, armed guards", and a property owner
>> might allude their dog is snappish.
>>
>> 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] Feature Proposal - RFC - Hazards (verifiability - frost heave?)

2020-12-04 Thread Joseph Eisenberg
Re: "However, in some cases, notably in the developing world, these types
of hazards may be tagged even if unsigned."

While this is certainly a true statement which represents the actual
situation in OpenStreetMap, I think it isn't needed in the proposal.
Mappers will always feel free to add features which are generally
recognized to exist by local people. I would prefer that the proposal focus
on mapping verifiable evidence of hazards, such as the signs, barriers, and
official announcements.

This will make it easier to fix problems with mappers who want to add
hazard=curve to every single curve on a long curvy road, or add very
subjective hazard features which  cannot be confirmed or denied even when
visiting the location in person.

-- Joseph Eisenberg

On Fri, Dec 4, 2020 at 12:43 PM Brian M. Sperlongano 
wrote:

>
> This was a concern of mine as well.  I did not want someone micromapping
> every bend in a road with hazard=curve for example.  The intent is for
> officially declared hazards rather than vague interpretations.  However, I
> also recognize that, particularly in the developing world, formal signage
> or declaration may not exist and that unsigned hazards should be allowed.
> I specifically wrote the paragraph below (from the proposal) to address
> this issue.
>
> Does that satisfy your concern?
>
> === Proposal text below ===
>
> Hazards are verifiable via the following means:
>
> * Hazards to drivers indicated by roadside traffic signs.
> * Hazards to health and safety indicated by fences or other barriers with
> posted signs
> * Government-declared hazardous areas as marked on government maps and/or
> GIS systems
> * For countries which routinely sign traffic hazards (such as "dangerous
> curve" or "school zone"), mappers should only tag these hazards when they
> are actually signed. However, in some cases, notably in the developing
> world, these types of hazards may be tagged even if unsigned.
>
> On Fri, Dec 4, 2020 at 3:56 AM Jez Nicholson 
> wrote:
>
>> As long as your frost heave conforms to verifiability guidelines by being
>> either:
>> a) signposted (possibly)
>> b) fenced off, with a sign (no, because it's in the road)
>> c) a government-declared hazardous area (no)
>>
>> I'm concerned that this hazard tagging proposal will encourage subjective
>> tagging over what constitutes a 'hazard'.
>>
>>
>> On Thu, Dec 3, 2020 at 7:49 PM Brian M. Sperlongano 
>> wrote:
>>
>>> I'd think that frost heaves (which are seasonal and conditions-based)
>>> versus permanent bumps are different.  If there aren't objections, I'd
>>> propose both a hazard=bump (which has a few trace uses) and a new value
>>> hazard=frost_heave to cover frost heaves specifically.
>>>
>>> On Thu, Dec 3, 2020 at 2:37 PM Adam Franco  wrote:
>>>
>>>> *hazard=frost_heave, hazard=bump?*
>>>>
>>>> One of the common road hazards I encounter and would like to tag are
>>>> large frost heaves that occur at consistent locations every year. A few
>>>> roads in my region like VT-17 and NY-8 have poor roadbeds and get damaged
>>>> by frost heaves the first winter after repaving. These roads often have
>>>> several hundred yards of nice smooth and fresh pavement, then 2"-8" frost
>>>> heaves with cracks that reappear in the same places year after year.
>>>>
>>>> Some examples:
>>>>
>>>>- VT-17: section A
>>>><https://www.mapillary.com/map/im/Nisd3iuj_bCdnuSwVBh5zA>, section B
>>>><https://www.mapillary.com/map/im/O-kqJL5OPJI-_RVor2rv4A> (with
>>>>"BUMP" sign), section C
>>>><https://www.mapillary.com/map/im/MzW49dK2S78l2ewhhpg5PQ>
>>>>- NY-8: section A
>>>>
>>>> <https://www.google.com/maps/@43.5567706,-74.120767,3a,75y,60.66h,62.7t/data=!3m6!1e1!3m4!1s8wGqO4YlGLPO2JfLpTG7ug!2e0!7i13312!8i6656>,
>>>>section B
>>>>
>>>> <https://www.google.com/maps/@43.5548342,-74.1233648,3a,75y,41.82h,60.46t/data=!3m6!1e1!3m4!1sWntAQT_Hwb2BVYwM5shNRg!2e0!7i13312!8i6656>
>>>>
>>>> This has been previously mentioned in an OSMUS Slack thread
>>>> <https://osmus.slack.com/archives/C2VJAJCS0/p1584560161247300> in
>>>> regard to smoothness=*, but tagging particularly bad (and often
>>>> permanent) heaves may be preferable as other sections of the roadway may be
>>>> smooth and freshly paved.
>>>>
>>>> Signage on these tends to be inconsistent, often using phr

Re: [Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

2020-12-03 Thread Joseph Eisenberg
Not all land slides are rock slides. Some are mostly silt or loamy soil, so
are often “mudslides”, e.g. in the Northwest Pacific coast of Canada and
the US:
https://en.m.wikipedia.org/wiki/2014_Oso_mudslide

So I would prefer “landslide” as a more general term.

- Joseph Eisenberg

On Thu, Dec 3, 2020 at 2:19 PM Brian M. Sperlongano 
wrote:

>
> On Thu, Dec 3, 2020 at 12:54 PM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> I am not exactly happy about "rock slide" as it seems weird to use it
>> where
>> danger is primarily about individual rocks dropping, not about full scale
>> rock slide.
>>
>> Personally I would prefer "failing rocks" for warning used by a standard
>> road
>> sign.
>>
>> (difference is minor, but if we have luxury of selecting any value...)
>>
>
> Since we do have that luxury, and there is a valid reason for preferring
> terminology as actually signed, then we can adopt "hazard=falling_rocks"
> (53 usages) and deprecate "hazard=rockfall" (182 usages).  These are small
> enough numbers that there shouldn't be any harm in choosing the smaller one.
>
> Can we treat landslide and rock_slide as the same thing?  If so,
> "hazard=rock_slide" has 394 usages and "hazard=landslide" has 35 usages.
> In that case, I would propose to adopt the more popular "rock_slide" and
> deprecate "landslide" as duplicate.
>
> Would this address the concerns?
>
> ___
> 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] RFC: vaccination / COVID-19 vaccination centres

2020-11-25 Thread Joseph Eisenberg
The proposed new tag, vaccination=, seems like a reasonable idea.

However, it might be necessary to discuss a main feature tag to use in the
case when these are not administered by a clinic or doctor's office or
hospital.

There does not seem to be a widely used, suitable tag under healthcare=* or
amenity=* for a place that specializes in administering immunizations only.

healthcare:speciality=vaccination is not a primary feature tag, but a
secondary tag which needs to be added to something under the key amenity=*
or healthcare=*.

Perhaps amenity=vaccination_centre would work?

-- Joseph Eisenberg

On Tue, Nov 24, 2020 at 9:30 AM Tom Pfeifer  wrote:
>
> Following the discussion on how to tag COVID-19 vaccination centres
previously on this list,
> I have created a proposal for the vaccination key:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/vaccination
>
> tom
>
> ___
> 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] Elevated housing estate

2020-11-24 Thread Joseph Eisenberg
Is the whole ground level a parking lot or parking structure, perhaps?

On Tue, Nov 24, 2020 at 4:03 PM Graeme Fitzpatrick 
wrote:

> How do you tag an area, in this case an entire housing estate!, that is
> raised up above ground level?
>
>
> https://www.google.com.au/maps/@-28.065772,153.3799853,3a,15y,117.51h,89.21t/data=!3m6!1e1!3m4!1sN_TJvFHJyLff1E4GmiCSjQ!2e0!7i13312!8i6656?hl=en
> (with the usual not mapping from Google ...)
>
> Just draw the outline of the area & tag it as level=1?
>
> The main entry is via a bridge:
> https://www.google.com.au/maps/@-28.0673717,153.3800556,3a,23.4y,28.84h,87.1t/data=!3m6!1e1!3m4!1sBF_8z5ekricuuEFZnUJioQ!2e0!7i13312!8i6656?hl=en
> ,
> which is ok, but should all the internal roads also be marked as bridges?
>
> 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] surface=rock

2020-11-21 Thread Joseph Eisenberg
My understanding about this is that there is a difference between British
English usage and American usage - especially in the western USA.

The English seem to have an idea that "rock" is for mostly solid, immobile
"bedrock", while a "stone" is a mobile, separate piece of mineral which you
might pick up if you are strong enough, or at least move with a piece of
heavy machinery. Hence the distinction between natural=stone and
natural=bare_rock in the wiki, and the different definitions in the OED
(lexico):

Rock: The solid mineral material forming part of the surface of the earth
and other similar planets, exposed on the surface or underlying the soil or
oceans - https://www.lexico.com/en/definition/rock - example "‘the beds of
rock are slightly tilted’"

Rock: "the dry solid part of earth's surface, or any large piece of this
that sticks up out of the ground or the sea"
https://dictionary.cambridge.org/us/dictionary/english/rock

Stone: https://www.lexico.com/definition/stone - "Hard solid non-metallic
mineral matter ... especially as a building material. ‘the houses are built
of stone’" and especially the next definition: 1.2 count noun "A small
piece of rock found on the ground."

Stone: "the hard, solid substance found in the ground that is often used
for building, or a piece of this" -
https://dictionary.cambridge.org/us/dictionary/english/stone

But American English and perhaps other dialects do not always maintain this
distinction, in my experience.

So in theory surface=stones would be best when there are large separate
stones, similar to surface=cobblestone or surface=scree(?), while
surface=bare_rock or surface=rock would suggest mostly solid bedrock, if
these tags are actually going to be used in different ways based on British
English. But it is unlikely that most mappers will understand the
difference.

-- Joseph Eisenberg

On Sat, Nov 21, 2020 at 11:25 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Nov 21, 2020, 17:43 by o...@westnordost.de:
>
> rock „pieces“ would be tagged as „stone“ I guess?
>
>
> Not so sure about that, then it would be surface=stones, (note the plural)
> wouldn't it?
>
> I am completely fine with both versions.
> I created today https://wiki.openstreetmap.org/wiki/Tag:surface%3Drock
> where I described surface=rock as fitting for them - but feel free to
> change this
>
> - Rock implies a rough naturalness
>
> +1
>
> - Steps made of large (single-piece) hewn stone columns would be called
> 'stone steps'
>
> so surface=stone (surface=stones) would be more fitting for them?
>
> - Bare [rock] implies the lack of rubble on top
>
> Small amount: yes
> Complete lack of it: no.
>
> See for example
> https://commons.wikimedia.org/wiki/File:Krywan_podejscie.jpg
>
> Especially for easily eroding rock that is breaking piece by piece some
> rubble will be always
> present.
>
> - Scree is specially loose
>
> +1
>
> - Personally I think bare_rock and stone are synonyms here, unless someone
> thinks there's a difference.
>
> Yes, even if we would invent some differences none would be present in de
> facto usage
> (different areas with different differences and subtle distinctions)
>
> rock = rough natural stone, could be loose stones too
> stone = smooth stone / bare rock, could be hewn
> bare_rock = probably similar to stone, definitely no loose stones
> scree = surface like (large) gravel, natural
> rocky = scree is rocky, piles of differently sized rocks are rocky
>
> Overall I think that I am fine with surface=rock, but I am not opposed to
> also other
> values (though I am not going to make proposals or wiki pages for them)
> ___
> 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] coastline v. water

2020-11-21 Thread Joseph Eisenberg
Eric,
I don't think the previous discussion is quite as inconclusive as your
evaluation.

While it is true that there is not widespread agreement on where the
natural=coatline ways should transect a river mouth or river estuary, there
is nearly universal agreement that marginal seas, including bays, are
mapped with the natural=coastline.

Using the rendering at https://www.openstreetmap.de/karte.html - which
differentiates the marine water polygons outside of the coastline from
lakes and rivers, by using slightly different colors, we can see how bays
are mapped in other parts of North America and the world.

For example, check out Delaware Bay, just up the coast from your area:
https://www.openstreetmap.de/karte.html?zoom=10=39.14649=-75.07302=B000
-
it is mapped as a natural=bay with natural=coastline around it, not
natural=water

Upper and Lower New York Bay are mapped as bays outside of the
natural=coastline - you can see the line where the waterway=riverbank area
starts just at the north end of Manhattan island (though this placement is
somewhat controversial) -
https://www.openstreetmap.de/karte.html?zoom=10=40.63628=-73.93525=B000

Tampa Bay:
https://www.openstreetmap.de/karte.html?zoom=10=27.80801=-82.63368=B000
- outside of the natural=coastline

Galveston Bay:
https://www.openstreetmap.de/karte.html?zoom=10=29.49869=-94.94249=B000TT
- outside of the natural=coastline

San Francisco Bay and connected bays:
https://www.openstreetmap.de/karte.html?zoom=10=37.79939=-122.06911=B000TT
- outside of the coastline

Puget Sound - while Lake Washington on the east side of Seattle is
natural=water, also most of the ship canal connecting them:
https://www.openstreetmap.de/karte.html?zoom=11=47.59544=-122.39252=B000

I would like to request that the tidal channels and estuaries around
Chesapeake Bay be re-mapped with natural=coastline. If you wish to keep the
natural-water polygons for the estuaries that is not a problem.

But it would be contrary to normal practice to map the main body of
Chesapeake Bay as natural=water because it is clearly part of the sea -
there is no barrier between it and the open ocean, since there is an open
channel through US 13 where the tunnel is. While it is an estuary by
hydrological definitions, so are the Baltic Sea and all fjords and Puget
Sound and San Francisco Bay - all of which are mapped as outside of the
natural=coastline.

Also please consider that the community here approved the proposal for
waterway=tidal_channel which said that the area of tidal channels (aka
tidal creeks) should be mapped with natural=coastline at their edges - see
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dtidal_channel#How_to_Map
and
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel
- most of the "creek" features along the Bay are tidal channels.

-- Joseph Eisenberg

On Thu, Nov 19, 2020 at 6:46 AM Eric H. Christensen via Tagging <
tagging@openstreetmap.org> wrote:

> ‐‐‐ Original Message ‐‐‐
>
> On Wednesday, November 18th, 2020 at 11:34 PM, Brian M. Sperlongano <
> zelonew...@gmail.com> wrote:
>
> > This was fascinating reading.  I do agree that we ought to have a
> definition for what gets tagged natural=coastline, and I think it's fine if
> that definition has some subjectivity.
> >
> > I would offer something as simple as:
> >
> > "The coastline should follow the mean high tide line.  In some cases
> this rule would result in the coastline extending an unreasonable distance
> along the banks of tidal rivers.  In those cases, mappers should identify a
> reasonable choke point at which to terminate the inland extent of coastline
> tagging."
>
> I would just classify it as "where the ocean meets the land".  Any other
> water that isn't ocean should be mapped as water and tagged appropriately.
> That makes the map more accurate and detailed.
>
> R,
> Eric
>
> ___
> 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 - Voting - Pumping proposal

2020-11-20 Thread Joseph Eisenberg
The current tagging of man_made=water_well + pump=no/manual/powered is
currently used by the HDM style, featured as the "Humanitarian" map layer
on Openstreetmap.org, to determine what sort of icon should be shown for a
water well. Examples:

https://www.openstreetmap.org/node/5768737664#map=17/-8.54734/122.04898=H
- well with powered pump (and you can see 3 more nearby, one for each
"dusun" or small "neighborhood" in this village)

https://www.openstreetmap.org/node/5768453092#map=18/-8.74465/122.07912=H
- lots of wells with no pump, represented by a bucket, also one powered
well in this village.

https://www.openstreetmap.org/node/6449466014#map=18/14.52455/121.05865=H
- water well with a manual pump in a school yard - also another one in the
school to the east.

-- Joseph Eisenberg



On Fri, Nov 20, 2020 at 9:19 PM Joseph Eisenberg 
wrote:

> On the Talk page, the proposal author has now ignored two different
> requests to change the new pump=values to a different key like
> pump_mechanism, which would allow the continued use of pump=manual and
> pump=powered.
>
> The author claims: "I find current tagging meaningless (with all due
> respect to people who created it in the past)"
>
> This is absolutely disrespectful to the current mappers using this tag to
> specify the type of water well found in lower-income countries.
>
> Perhaps you have never lived in a place where people get their drinking
> and washing water from public or semi-public wells. In these places it is
> quite important to know if a well is just a hole in the ground where you
> need to use a bucket and rope to draw out water (pump=no), or if there is a
> mechanical pump handle which you can physically operate, with some amount
> of force, to pump out bursts of water (pump=manual).
>
> And the other type of well is "a well that is attached to pipes and a
> motorized pump", which is usually powered by electricity but sometimes by a
> diesel motor. In this type of well you don't have to use any physical
> effort at all, you just flip a switch or open a faucet and water comes out
> - as most Westerners are accustomed to enjoy in their own homes.
>
> But you will need electricity or fuel to operate it. So usually a
> man_made=water_well + pump=powered is much more convenient, but when the
> power goes out or there is no fuel, it can be nearly useless, while a
> pump=manual is now much more helpful.
>
> I am quite frustrated that this proposal has gone forward even though
> these concerns were brought up months ago on the Talk page.
>
> -- Joseph Eisenberg
>
>
> On Fri, Nov 20, 2020 at 4:23 AM François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> Dear Mateusz,
>>
>> Proposal goes through different stages and I was proposing simpler
>> driver=* instead of mechanical_driver. Comments have been made about the
>> possible confusion with human drivers driving cars.
>>
>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pumping_proposal#Consider_drivers_as_pump_specific_devices
>> However, drivers aren't specific to pumps at all.
>>
>> Current pump=* doesn't deal with pumps but with water wells and possible
>> motors/engines installed to get water. I was confused by this in the very
>> beginning.
>> pump=powered mixes electric motors and gasoline engines which are way
>> different. Situations may occur with emergency services coming with
>> gasoline to run an electric motor for instance.
>> The opportunity (not an obligation) to replace this particular value with
>> more detailed and useful information is the goal of the proposal.
>>
>> One possible way to state the isn't manually operable is to use handle=no
>> without any mechanical_driver (waiting to be defined by knowledgeable
>> people)
>>
>> All the best
>>
>> François
>>
>> Le ven. 20 nov. 2020 à 12:22, Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> a écrit :
>>
>>> I am not a fan of deprecating
>>> pump=manual and replacing it with nearly impossible to remember and less
>>> clear
>>> mechanical_driver=manual
>>>
>>> Also, this proposal deprecates pump=powered without providing replacement
>>>
>>> Now to tag this info one is supposed to select value from
>>> reciprocating_solenoid
>>> combustion_engine
>>> electric_motor
>>> cylinder
>>> turbine
>>>
>>> and no way to tag equivalent of pump=powered is provided.
>>>
>>> Mapper may be uninterested in or unable to get info about technical
>>> detail,
>>> but they should be still able to tag info 

Re: [Tagging] Feature Proposal - Voting - Pumping proposal

2020-11-20 Thread Joseph Eisenberg
On the Talk page, the proposal author has now ignored two different
requests to change the new pump=values to a different key like
pump_mechanism, which would allow the continued use of pump=manual and
pump=powered.

The author claims: "I find current tagging meaningless (with all due
respect to people who created it in the past)"

This is absolutely disrespectful to the current mappers using this tag to
specify the type of water well found in lower-income countries.

Perhaps you have never lived in a place where people get their drinking and
washing water from public or semi-public wells. In these places it is quite
important to know if a well is just a hole in the ground where you need to
use a bucket and rope to draw out water (pump=no), or if there is a
mechanical pump handle which you can physically operate, with some amount
of force, to pump out bursts of water (pump=manual).

And the other type of well is "a well that is attached to pipes and a
motorized pump", which is usually powered by electricity but sometimes by a
diesel motor. In this type of well you don't have to use any physical
effort at all, you just flip a switch or open a faucet and water comes out
- as most Westerners are accustomed to enjoy in their own homes.

But you will need electricity or fuel to operate it. So usually a
man_made=water_well + pump=powered is much more convenient, but when the
power goes out or there is no fuel, it can be nearly useless, while a
pump=manual is now much more helpful.

I am quite frustrated that this proposal has gone forward even though these
concerns were brought up months ago on the Talk page.

-- Joseph Eisenberg


On Fri, Nov 20, 2020 at 4:23 AM François Lacombe 
wrote:

> Dear Mateusz,
>
> Proposal goes through different stages and I was proposing simpler
> driver=* instead of mechanical_driver. Comments have been made about the
> possible confusion with human drivers driving cars.
>
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pumping_proposal#Consider_drivers_as_pump_specific_devices
> However, drivers aren't specific to pumps at all.
>
> Current pump=* doesn't deal with pumps but with water wells and possible
> motors/engines installed to get water. I was confused by this in the very
> beginning.
> pump=powered mixes electric motors and gasoline engines which are way
> different. Situations may occur with emergency services coming with
> gasoline to run an electric motor for instance.
> The opportunity (not an obligation) to replace this particular value with
> more detailed and useful information is the goal of the proposal.
>
> One possible way to state the isn't manually operable is to use handle=no
> without any mechanical_driver (waiting to be defined by knowledgeable
> people)
>
> All the best
>
> François
>
> Le ven. 20 nov. 2020 à 12:22, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> a écrit :
>
>> I am not a fan of deprecating
>> pump=manual and replacing it with nearly impossible to remember and less
>> clear
>> mechanical_driver=manual
>>
>> Also, this proposal deprecates pump=powered without providing replacement
>>
>> Now to tag this info one is supposed to select value from
>> reciprocating_solenoid
>> combustion_engine
>> electric_motor
>> cylinder
>> turbine
>>
>> and no way to tag equivalent of pump=powered is provided.
>>
>> Mapper may be uninterested in or unable to get info about technical
>> detail,
>> but they should be still able to tag info that pump is not manually
>> operated.
>>
>> Nov 19, 2020, 20:05 by fl.infosrese...@gmail.com:
>>
>> Hi all
>>
>> Tonight I'm pleased to announce the start of voting for the tagging
>> proposal about pumps
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>>
>> A lot of comments lead us to an interesting tagging for pumps devices,
>> water wells and wind pumps. Thank you to anyone involved in this review.
>> Some values are proposed to be deprecated as to classify pumps according
>> to their technologies and capabilities.
>>
>> Several contributors tested the proposed tags in real conditions and no
>> problem seems to remain.
>>
>> Feel free to give your opinion until December 3
>>
>> All the best
>>
>> François
>>
>>
>> ___
>> 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] coastline v. water

2020-11-18 Thread Joseph Eisenberg
Chesapeake Bay, as the name “Bay” suggests, is a bay at the edge of the
Atlantic Ocean. It is a shallow estuary, similar to many othe partially
enclosed margins seas, e.g. the Salish Sea (including Puget Sound) in
Washington/British Columbia, San Francisco Bay in California, the Tampa Bay
in Florida, etc.

It has always been the standard to map these bays as part of the marine
environment by using the natural=coastline to include them as part of the
marginal sea.

Consider that the natural=coastline is defined as representing the mean
high water springs line, that is, the line of the highest tides. If the
line on an open ocean beach is at the high tide line, it makes sense that
all tidal bays and estuaries should also be included in the area outside of
the coastline.

While there is some debate about where on the Potomac River we should put
the line (I would suggest around DC, where the river widens out), there is
no doubt that Chesapeake Bay is part of the marine environment.

— Joseph Eisenberg

On Wed, Nov 18, 2020 at 12:24 PM Eric H. Christensen via Tagging <
tagging@openstreetmap.org> wrote:

> After a few days of much work, a recent collaborative project to turn the
> Chesapeake Bay from a nothing space outlined by natural=coastline to what
> we considered to be a more accurate relation of natural=water, we've
> received some negative feedback.
>
> The difference of opinion seems to lie in the definition of what we're
> mapping.  The use of coastline is for "seas"[0] while the use of water is
> for "inland areas of water"[1].  Even though the Chesapeake Bay is tidal,
> there is no question that it is an inland waterway (it is completely
> surrounded by land except for the mouth at its southeast side).  The idea
> of using coastlines for basically creating an edge between the land and the
> nothingness of the ocean makes sense when, as far as the eye can see it's
> only water.
>
> Now, some of the feedback that has been presented[2] is that because it is
> tidal it is part of the sea.  I have pointed out that many rivers and
> streams (and ditches!) are tidal; does that make them part of the sea?  I
> would not think so.  In fact, there are named seas on this planet that are
> not even connected to other water formations (the tiniest, according to the
> National Geographic, is the Sea of Marmara which has an area just less than
> 12,950 sq km, larger than the Chesapeake Bay).
>
> But, tagging the Chesapeake Bay, and its tributaries, as "water" brings
> several benefits to the map and the users.  First, it helps identify the
> sections of water that exist in these areas (this can't really be done with
> node points as there is no way to define start and end points of an area).
> There are many defined bays, rivers, and streams that make up the greater
> Chesapeake Bay area.  What one may see as one large mass of water is
> actually many smaller defined segments each with their own history.
> Second, we can speed up any updates (fixes) to outlines of the polygons
> that happen in these water areas without having to wait for the entire
> Earth's coastlines to be re-rendered.  I suspect having less coastline to
> render would also speed up the rendering of coastlines as well?
>
> I would like for the tagging community to clarify the different between
> "water" and "coastline" and when to use each.  The definition on water
> seems to say to use it on inland water but there seems to be, at least, and
> open interpretation of the word "sea" for coastline that is dragging many
> inland waters into that category.
>
> Thanks,
> Eric "Sparks" Christensen
>
> [0] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline
> [1] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater
> [2]
> https://www.openstreetmap.org/changeset/94093155#map=10/37.1620/-76.1581
>
> ___
> 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] Deprecate water=pond?

2020-11-14 Thread Joseph Eisenberg
If anyone wants to map beaver dams, I would suggest natural=beaver_dam
since this would use a common key ("natural") rather than inventing a new
one.

-- Joseph Eisenberg

On Sat, Nov 14, 2020 at 11:10 AM Tom Pfeifer  wrote:

> beaver_made = dam ?
>
> On 14.11.2020 04:02, Kevin Kenny wrote:
> > On Thu, Nov 12, 2020 at 6:22 PM Adam Franco  <mailto:adamfra...@gmail.com>> wrote:
> >
> >   * origination:natural=beavers
> >
> > Thanks for remembering this one. Around here, beavers are a significant
> sculpting force on the
> > landscape.
> >
> > (And `man_made=dam` is the best tagging that we have for their water
> control structures, which are
> > also often adjusted seasonally)
>
> ___
> 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] Deprecate water=pond?

2020-11-13 Thread Joseph Eisenberg
Re: "I can hardly think of any waterbody, intermediate on the large..small
and natural..artificial scales between the Great Lakes and a farmer's stock
pond, where the `water=*` value would be uncontroversial."

water=canal is the consensus tag for the area of a canal. There was never a
standard way to tag this before, so I would strongly recommend adding this
tag for all canals when mapped as an area with natural=water. Similarly,
water=lock is uncontroversial and widely used.

While there is still some controversy about using water=river +
natural=water instead of waterway=riverbank for the area of a river, it is
uncontroversial that you should certainly add  water=river if you are using
natural=water in this case.

The same thing goes for reservoirs and basins: you can also use
landuse=basin or landuse=reservoir, but if you map them with natural=water
it is very helpful to use water=basin or water=reservoir

Those values account for most of the uses of water=*... except for
water=pond, which is where we started.

On Fri, Nov 13, 2020 at 7:05 PM Kevin Kenny  wrote:

> On Thu, Nov 12, 2020 at 6:22 PM Adam Franco  wrote:
>
>>
>>- origination:natural=beavers
>>
>> Thanks for remembering this one. Around here, beavers are a significant
> sculpting force on the landscape.
>
> (And `man_made=dam` is the best tagging that we have for their water
> control structures, which are also often adjusted seasonally)
>
> Very long story short, I think we might be able to worry a little less
>> about what the body of still water *is* and more about its other
>> properties that might be of interest. In programming languages this is
>> referred to as "duck typing <https://en.wikipedia.org/wiki/Duck_typing>".
>>
>
> If ducks could type, I could easily imagine that a pond might be mapped
> and the tags entered by a duck typing. I think that the duck in question
> might be Atwood's Duck.
> https://en.wikipedia.org/wiki/Law_of_triviality#Related_principles_and_formulations
>
> And ... having seen this argument several times before, I basically avoid
> `water=*` when mapping. I can hardly think of any waterbody, intermediate
> on the large..small and natural..artificial scales between the Great Lakes
> and a farmer's stock pond, where the `water=*` value would be
> uncontroversial. `natural=water` renders, and I'll try to avoid taking a
> census of the angels dancing on that particular pinhead.
>
> This whole discussion reminds me of one time that someone who wasn't from
> around here (nor a native speaker) was insisting that anything that was
> called a 'creek' in English *must* be a tiny watercourse.  Not around here!
> The creek in question was, if memory serves, either the Schoharie Creek,
> shown in this picture:
> http://minerva.union.edu/garverj/mohawk/images/schoharie_falls.jpg or
> else the West Canada Creek
> https://en.wikipedia.org/wiki/West_Canada_Creek#/media/File:Aug_2011_Ft_Noble_Mtn.JPG
> I'm comfortable with `waterway=river` on any waterway where I map the
> riverbank.
>
> On Thu, Nov 12, 2020 at 2:52 PM Paul Allen  wrote:
>>
>>> On Thu, 12 Nov 2020 at 19:30, Joseph Eisenberg <
>>> joseph.eisenb...@gmail.com> wrote:
>>>
>>>> Re: is water=* tag needed?
>>>>
>>>
>>>
>>>> But since water=pond is not clearly defined as natura/semi-natural vs
>>>> man-made, we have a large number of features where the water=* tag is not
>>>> providing this information. Since the previous tagging system clearly
>>>> distinguished natural from man-made water bodies, this would be a loss for
>>>> database quality.
>>>>
>>>
>>> We often do not know if it is natural or artificial.  Maybe it's a
>>> natural
>>> depression in the ground that fills with water.  Maybe it was created
>>> by man as a water feature.  Maybe it's an old quarry that has flooded.
>>> Even if it was originally a result of something like quarrying it may
>>> have
>>> happened so long ago that there are no records.
>>>
>>> What we can determine (at least in principle) is if it meets criteria
>>> for a lake (large size or large waves or has aphotic zones) or a
>>> pond.  In principle, a suitably-qualified mapper could investigate
>>> those things on site.  We can accept using guesswork based on
>>> size pending fuller investigation. A lake/pond distinction is
>>> useful irrespective of whether it is entirely natural or entirely
>>> artificial.
>>>
>>> Determining if it's entirely natural, or deliberately man-made, or
>>> an unintended consequence of past human activit

Re: [Tagging] Feature proposal - RFC - Place of mourning (replacing "Chapel of rest")

2020-11-12 Thread Joseph Eisenberg
See comments on the last proposal:

"*It is redundant. I really don't understand why we need another tag for a
room or building where families and friends can come and view someone who
has died before their funeral. The tag shop=funeral_directors fits
perfectly the definition of this new tag proposal (please read it) I quote
the definition for funeral_directors: "An event (a place) to honor the
deceased for mourners are held here in conjunction with religious services
which are held elsewhere". And the tag amenity=funeral_hall can be used
instead, in the case that religious ceremonies (any creed) are allowed in
the building. Funeral Halls in many countries (as mine [México]) help
mourners with all the administrative documentation as Funeral Directors do.
If we want to have a tag for every possible difference in all countries we
will have a myriad of tags and a complete confussion on which tag to use.*"

*"I note that the English Wikipedia page Funeral_home directs to Funérarium
in French, which is the term described in the lede. Similarly, I am also
having trouble understanding where the distinction is between the two."*

*"my Oxford defines "chapel of rest" as "an undertaker's mortuary, where
bodies are kept before a funeral" and does not reflect on the visitation
aspect at all"*

You need to explain this on the new proposal page. Note that on
Tag:shop=funeral_directors
 it says *"an
event (sometimes with the deceased's body present) to honor the deceased
for mourners are held here in conjunction with religious services which are
held elsewhere."* Also Tag:amenity=mortuary
 says "A morgue
or funeral home" which might include a place for a viewing. --Jeisenbe
(talk
) 20:05, 12
November 2020 (UTC)

On Wed, Nov 11, 2020 at 11:08 AM  wrote:

> Dear all,
>
> As already discussed, "place of mourning" seems to be a less bad label
> than "chapel of rest".
>
> Therefore please comment on the following new proposal:
>
> Place of mourning: a room or building where families and friends can
> come and view someone who has died, before their funeral
>
> Proposal page:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Place_of_mourning
> Discussion page:
>
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Place_of_mourning
>
> Thanks!
>
> Vollis
>
> ___
> 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] How to tag a threshing floor

2020-11-12 Thread Joseph Eisenberg
Since the tag man_made=threshing_floor has already been used 7 times (
https://taginfo.openstreetmap.org/search?q=threshing_floor#values) you can
create a page to document this, however, you would also need to mention
that historic=threshing_floor is much more common (actually
landuse=threshing_floor is also equally common), and it would probably be
fair to create a historic=threshing_floor wiki page too, in that case.

If you want to suggest deprecating historic=threshing_floor and replacing
it with man_made=threshing_floor, or otherwise changing existing common
usage, you should make a proposal so that the community can discuss this.

-- Joseph Eisenberg

On Wed, Nov 11, 2020 at 2:53 PM António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

> So, given that most of those who commented this thread agreed that
> threshing_floor should be in the man_made scheme, should I add it to the
> wiki or create a Feature Proposal?
>
>
> Às 19:27 de 06/11/2020, Paul Allen escreveu:
>
> On Fri, 6 Nov 2020 at 21:53, Martin Koppenhoefer 
> wrote:
>
>> Am Fr., 6. Nov. 2020 um 13:56 Uhr schrieb Paul Allen > >:
>>
>>> On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer 
>>> wrote:
>>>
>>> ...
>>>
>>> To me it doesn't make sense to draw a line, dividing the same objects
>>>> having more or less historic value. If there is something to distinguish at
>>>> all, my suggestion would be to add a qualifier to those objects of
>>>> exceptional historical value (if this is verifiable).
>>>>
>>>
>>> We have a way of tagging objects of exceptional historical value, it's
>>> historic=*.  Objects of unexceptional historical value, or of no
>>> historical
>>> value do not get tagged with historic=*.  That's because historic is
>>> not a synonym (in the real world or in tagging) for old, disused or
>>> repurposed.
>>>
>>
>> just that it is not what we are currently doing.
>>
>> That is not what some of us are currently doing.  Others read the wiki
> page
> and tag accordingly.
>
> It occurs to me that some of the mis-tagging (as I see it) and some of the
> discussions here may revolve around semantics as interpreted by
> those who do not have English as a first language.  There is a
> difference between "historical" and "historic."
>
> Historians are concerned with historical data.  Old data (about
> populations, diseases or whatever) is historical data.  The
> assassination of a minor archduke, which seemed unimportant
> at the time, quickly turned into a historic event.
>
> When somebody says that "historic" applies to everything that
> historians do, that is incorrect.  What historians mostly do is
> look at historical data, some small fraction of which is
> also historic.
>
> See https://www.grammarly.com/blog/historic-historical/
> for a better explanation.
>
> So historic=* really should only apply (as the wiki page states) to the
> important
> things of the past, not everything some random historian might happen
> to be looking into.
>
> So the question is, do we accept that because some mappers have misused
> the tag we should encourage that misuse or do we discourage it?
>
> --
> Paul
>
>
> ___
> 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] Deprecate water=pond?

2020-11-12 Thread Joseph Eisenberg
Re: is water=* tag needed?

On Thu, Nov 12, 2020 at 9:36 AM Brian M. Sperlongano 
wrote:
> "Is a water= tag even needed at all in these cases then? natural=water +
name="Foobar Pond" seems to cover it.  I'm not sure what specific added
information is conveyed by "lake", "pond", or even "lake_pond".  It's a
natural body of water with a name.  If we need tagging to indicate
freshwater vs brackish vs saltwater, or depth, or murkiness, those seem
like separate tags.

>
> > "I think the question here isn't if pond makes sense for data consumers.
Mappers are what matters in this case. If there is a little 4 meter pond,
mappers will not tag it as a lake because it sounds wrong. So they will
probably tag it just natural=water. But then we lose information about if
it is a little lake, a reservoir, a fountain or a wastewater dump. That's
why we need the pond."

So originally all lakes and semi-natural ponds were tagged just
natural=water, while reservoirs were landuse=reservoir,
retention/detention/infiltration basins were landuse=basin, the area of
 rivers was mapped with waterway=riverbank. And then, as now
leisure=swimming_pool was used for swimming pools, while seas and coastal
waters were delimited with natural=coastline ways (as they still are). Salt
ponds could be mapped with landuse=salt_pond.

This meant that there were separate tags for seas and marine water (all
areas outside of the coastline), for natural inland still water
(natural=water), man-made still water features (landuse=reservoir / =basin
/ =salt_pond), and for rivers (waterway=riverbank) - which are natural
flowing watercourses.

But there wasn't a clear way to map the area of a canal or ditch: an
artificial area of flowing water, so the tagging system was missing one
ingredient.

Some mappers used waterway=riverbank since canals are similar to rivers,
while others used natural=water even though this was for lakes.

Instead of making a new tag for canals or ditches or drains, its was
proposed to just use natural=water for all inland water areas, including
rivers, canals, reservoirs, and basins, with the addition of the tag
water=* to describe the type of water area. This was somewhat
controversial, since it meant mapping man-made watercourses and waterbodies
under natural=* but it was approved:
https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details (Apparently
this was already in use in Russia before it was adopted by the global
community?)

Now the proposal had a couple problems: it suggested water=cove and
water=lagoon for areas which are clearly outside of the coastline and part
of the marine water system, but in practice this has not happened,
natural=bay has been used for these areas instead of natural=water, so the
distinction between marine and inland water has remained mostly clear
(except in the difficult situation of estuaries).

But since water=pond is not clearly defined as natura/semi-natural vs
man-made, we have a large number of features where the water=* tag is not
providing this information. Since the previous tagging system clearly
distinguished natural from man-made water bodies, this would be a loss for
database quality.

I wish it was possible to just redefine water=pond as "a man-made pond",
but since this is not likely to succeed, we should provide clear
alternatives.

Of course it will remain possible to just use natural=water with no
additional tag, if it's not known whether an inland body of still water is
man-made or natural.

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


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread Joseph Eisenberg
Yes, it matters if it's flowing water, because rivers/streams (and
artificial waterways like canals, ditches and drains) are clearly distinct
from standing water bodies like lakes, reservoirs and basins. This is a
clearly observable difference which local mappers can survey.

Currently a number of map styles render flowing water (rivers, streams and
canals) differently than standing inland water or sea water.

Database users might want to calculate the total area of streams and rivers
in a country, and compare it to the total area of standing inland waters.
They also might want to compare the number or size of natural water bodies
to the number or size of artificial water bodies.

Since the difference between these is usually observable and verifiable, we
should have tags available that mappers can use.

Of course there will always be edge cases where it can be hard to decide if
a certain water body is a small natural lake or a semi-artificial pond, but
in that case mappers can just use natural=water without a water=* tag.

There are also edge-cases between rivers and estuaries at the junction with
the sea, and we should probably decide on a way to map this, but that's for
another time. Suffice to say that 99% of the time it's obvious if an area
of water is a flowing river vs a still-water lake. And similarly, canals
can usually be clearly distinguished from rivers based on their appearance,
and local knowledge of residents of the area.

So we should make sure our tagging distinguishes sea water from inland
still waters and flowing rivers, and also distinguish artificial from
natural water bodies and watercourses

-- Joseph Eisenberg

On Thu, Nov 12, 2020 at 3:50 AM OSM  wrote:

>
>
> Am 11.11.2020 um 18:25 schrieb Peter Elderson:
> > I am getting a foot vs hiking feeling. Everybody knows a difference,
> > nobody has the same difference. In the end, it does not matter.
>
> Hmm - does it matter, if it is a river or a stream or a lake or a pond?
> Especially a lake with a river flowing through?
> Or is it not all and everything only water - and a name somewhere ...
> Why does the water=* tag exist anyway? To distinguish between flowing
> and standing waters? Don't say so - see above.
>
> --
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.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] Deprecate water=pond?

2020-11-12 Thread Joseph Eisenberg
Re: "what about artificial lakes that are not for storing water?"

Most of those are landuse=basin (or water=basin + natural=water if you
prefer the newer tagging scheme), and while they are not exactly for
"storing water", they might be for "preventing flooding", or "temporarily
holding excess water" or "permanently holding waste water."

I believe a landuse=reservoir or water=reservoid feature is going to
presumed to have a dam at one end which was built to keep in the water.

Flooded quarries and old mines are an interesting exception. I suppose a
old pit mine is not exactly a reservoir in the common understanding,
because the hole in the ground was built to remove minerals, and usually it
only fills up with water after the mining activity is finished and pumps to
extract water are turned off; there is usually no dam (though sometimes a
dam might be built later to prevent flooding).

It's also not exactly a landuse=basin because  the hole in the ground was
not made to hold water.

Perhaps water=quarry or something like that would be helpful, when it's
obvious that the water feature is an abandoned open pit mine or quarry.

On Thu, Nov 12, 2020 at 4:41 AM Martin Koppenhoefer 
wrote:

> Am Do., 12. Nov. 2020 um 02:33 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> Ok, it looks like enough people feel that a very small artificial water
>> body, like a decorative pond in a residential garden, shouldn't be tagged
>> as water=reservoir or water=basin, so we need a replacement.
>>
>> The current problem with water=pond is that many are completely natural
>> features, but almost all other values of water=* are clearly natural (or
>> semi-natural), or clearly artificial, so water=pond is losing this
>> information which otherwise should be conveyed by the key water=*.
>>
>
>
> water=lake does not tell you about it being "natural" or not either. I am
> not sure what the term "natural" means. If a woman makes a depression in
> the terrain, and it automatically fills up with (surface or ground) water
> because of the geological conditions, is this "natural" or not? What about
> a woman sealing the terrain and conducting water to a place where there
> wasn't a water body before?
>
> This is a flooded open pit mine, is it "natural" or not, and if not, what
> would be the osm tag for it? water=lake, natural=no?
> https://www.lmbv.de/files/LMBV/Fotos/Nachrichten/Archivierte%20Nachrichtenfotos/LMBV_1616.jpg
>
> What about a lake without water (drained)? Is "lake" a term that can only
> be used for water bodies, or are dry lakes ok? Example:
> https://www.openstreetmap.org/#map=13/41.9975/13.5625 (everything
> "yellow" is a lake / former lake (actually third largest lake in Italy):
> https://en.wikipedia.org/wiki/Fucine_Lake
>
>
>> - water=fountain
>> - water=fishpond
>>
>
>
> -1 to "fishpond". It is not defined in the wiki, and is discouraged as
> likely a mistake: https://wiki.openstreetmap.org/wiki/Key:water (and I
> agree it is not good). You can have fish in many kinds of water bodies, I
> just recently started to add fish=yes to fountains when there are fish
> inside.
>
>
>>
>> And as mentioned before, there are water=reservoir (A reservoir
>> <https://en.wikipedia.org/wiki/Reservoir> or an artificial lake is used
>> to store water. )
>>
>
>
> what about artificial lakes that are not for storing water?
>
> 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] Deprecate water=pond?

2020-11-11 Thread Joseph Eisenberg
Ok, it looks like enough people feel that a very small artificial water
body, like a decorative pond in a residential garden, shouldn't be tagged
as water=reservoir or water=basin, so we need a replacement.

I can see the logic behind that, if a reservoir is thought to be larger and
must have a dam on one side, and a basin is artificially graded. A small
koi pond or decorative pool isn't exactly the same.

The current problem with water=pond is that many are completely natural
features, but almost all other values of water=* are clearly natural (or
semi-natural), or clearly artificial, so water=pond is losing this
information which otherwise should be conveyed by the key water=*. Since it
is unlikely that we could check 1 million water=pond features quickly, it's
not reasonable to redefine the meaning of this tag, but we can create a new
tag or several replacement tags which are more specific, and encourage use
of those instead.

But we need to have a clear description which will translate into other
languages and cultures. For example, in Papua Indonesia, most Trans-New
Guinea languages use 1 word for all types of "water", including rivers,
streams, lakes, and the sea, so they won't see a difference between a
"lake" and a "pond" unless you clearly describe it.

There are already several other more specific tags for small artificial
water bodies, in use:
(https://taginfo.openstreetmap.org/keys/?key=water#values)
- water=reflecting_pool - "A reflecting pool: a water feature found in
gardens, parks, and at memorial sites. It usually consists of a shallow
pool of water, undisturbed by fountain jets, for a calm reflective surface."
- water=moat - A deep, wide defensive ditch, normally filled with water,
surrounding a fortified habitation.
- water=wastewater - A clarifier/settling basin of a wastewater treatment
plant.
- water=fountain
- water=fishpond

And as mentioned before, there are water=reservoir (A reservoir
<https://en.wikipedia.org/wiki/Reservoir> or an artificial lake is used to
store water. ) and water=basin (An area of land artificially graded to hold
water.)

So perhaps we could create a new tag water=natural_pond for small, natural
or semi-natural lakes which are currently tagged as water=pond, and
water=artificial_pond or water=man_made_pond for the majority of water=pond
features which are clearly not natural, such as ponds in gardens.

-- Joseph Eisenberg


On Tue, Nov 10, 2020 at 1:59 AM Andy Mabbett 
wrote:
>
> On Tue, 10 Nov 2020 at 05:26, Joseph Eisenberg
>  wrote:
>
> > I think the best option is to deprecate water=pond and suggest using
water=lake for
> > natural lakes, even small ones, and use water=reservoir or water=basin
(or
> > landuse=reservoir or =basin if you prefer) for the artificial ones.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Deprecate water=pond?

2020-11-09 Thread Joseph Eisenberg
The tag water=pond was added with a large number of other types of
"water=*" in 2011, but it has a poorly defined description.

"A pond <https://en.wikipedia.org/wiki/Pond>: a body of standing water,
man-made in most cases, that is usually smaller than a lake. Salt
evaporation ponds should be tagged with landuse
<https://wiki.openstreetmap.org/wiki/Key:landuse>=salt_pond
<https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dsalt_pond>, open-air
swimming pools — with leisure
<https://wiki.openstreetmap.org/wiki/Key:leisure>=swimming_pool
<https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dswimming_pool>."

So it might be artificial, like a landuse=reservoir or water=reservoir, but
smallish. Or it might be natural like a water=lake, but smallish. However,
nothing on the water=lake page defines a lower limit for the size of a lake.

This is a shame, because all the other values of water=* are clearly
defined as only natural, or only artificial, and waterway=* features are
also clearly divided. Furthermore, the original lags landuse=reservoir and
landuse=basin were also clearly artificial, while lakes were natural.

But the biggest problem is that there is no way to define a lower size for
a lake or reservoir, or an upper size for a pond. And the size of the area
is easier available from the geometry of the feature, so it doesn't need to
be mentioned in the tag.

I think the best option is to deprecate water=pond and suggest using
water=lake for natural lakes, even small ones, and use water=reservoir or
water=basin (or landuse=reservoir or =basin if you prefer) for the
artificial ones.

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


Re: [Tagging] Mapping terraced, irrigated farmland (e.g. rice paddies)?

2020-11-08 Thread Joseph Eisenberg
These are much taller than a step. There are earth banks at the edge of
each terrace, to keep the water in.

Here are some examples:

https://commons.wikimedia.org/wiki/File:Rice_terraces_on_Bali_-_Tegalalang_Rice_Terrace_-_Indonesia_06.jpg

https://commons.wikimedia.org/wiki/File:Fukuoka-Tsuzura_Rice_Terrace_in_an_Early_Summer-xl.jpg

There are also flood irrigated rice fields ("paddies") in flatter areas,
where there are just small earth berms between each field section. Usually
there is a slight difference in height, which varies based on the slope.
This can be hard to see from a distance:

https://pixabay.com/it/photos/uomo-riso-paddy-lavoro-panorama-5524518/

-- Joseph Eisenberg

On Sun, Nov 8, 2020 at 2:26 PM Graeme Fitzpatrick 
wrote:

> A while back, we had a discussion / proposal about mapping steps as an
> area, so that each step was mapped.
>
> Would that concept work here?
>
> 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] Basic cartography features missing, why?

2020-11-08 Thread Joseph Eisenberg
https://www.freemap.sk/?map=14/48.930467/19.094570=X

This is a nice topographical map, but it isn't serving client-side vector
tiles.

The tiles are jpegs, you can see jpg compression artifacts when zooming in.

Perhaps vector tiles are used on the server side, I haven't looked into all
of the code.

-- Joseph Eisenberg

On Sat, Nov 7, 2020 at 8:36 PM Martin Machyna  wrote:

> I absolutely agree with Seth, OSM should switch to vector tiles ASAP. And
> there should be several specialized layers: general car navigation map,
> sport map for hiking/cycling/skiing, transportation. All of that would be
> possible with vector tiles which are less computationally demanding to
> create.
>
> As an example, a small community in Slovakia used to render low zoom tiles
> on their server and high zoom tiles on volunteers' home computers and the
> update time was quite long. After they switched to vector tiles, all is
> rendered on the server only and instead of 1 country now they render 16+
> countries with fast refresh and on-demand rendering.
>
> And I personally think the result looks pretty good:
> https://www.freemap.sk/?map=14/48.930467/19.094570=X
>
> Their code is all on github so no need to reinvent the wheel and I think
> this could be easily modified for OSM purposes.
> https://github.com/FreemapSlovakia
>
> If there is nobody who can or is willing to do it then let's hire someone
> who can. Or let a company like Mapbox do it. I would be willing to do
> regular monthly donations for someone's salary if that makes OSM better and
> more attractive.
>
> I also fully agree with Anders. OSM needs change. There should be some
> sort of committee with a clear vision that would enforce a unified style of
> mapping. It is absolutely ridiculous that we have features that are mapped
> in 2 or more different ways simultaneously e.g. riverbanks or sidewalks...
> Who is supposed to use and rely on such data?
>
> Martin
>
>
>
>> Date: Sat, 7 Nov 2020 08:36:52 -0600 From: Seth Deegan
>>
>> I actually just found that article about OSM’s problems.
>> One of the major topics mentioned, the fact that OSM acts as a database
>> and
>> not a map, and that this acts as a hinderance to the expansion and
>> development of the project, is very true.
>> As a result, I’ve came to think that implementing Vector tiles should be
>> OSM’s #1 development priority right now. If people who find OSM realize
>> that there’s a lot more data than just the raster images displayed by the
>> standard tile layer, than they will be more likely to contribute and grow
>> the OSM community.
>> We’re all here complaining about computational needs required by rendering
>> servers, but there are some great vector tile implementations that require
>> way less computational needs.
>> Moral of the story: We need Vector tiles.
>> El El sáb, nov. 7, 2020 a la(s) 05:24, Anders Torger 
>> escribió:
>> > This is great information, I didn't know about your project, very very
>> > interesting. I have recently come to understand the OSM-Carto technical
>> > challenges recently. I haven't given it much of a thought as a casual
>> > mapper for the past two years, just been a bit disappointed with how it
>> > looks.
>> >
>> > I am a programmer in profession though so when taking a deeper look and
>> > though about it I see these challenges.
>> >
>> > However, and this is a big however, I think that the face of
>> > openstreetmap really need to be a cartographic sound map. It's not right
>> > that a style seemingly designed mainly for speedy diagnosis should be
>> > the face of OSM. How many of our mappers are so technical that they
>> > understand this? And howcome did I not even know about this cartographic
>> > project of yours? If there are great styles out there but noone knows
>> > about them that's a problem.
>> >
>> > And even if we let the not-so-good-cartography be the first map we see
>> > on openstreetmap.org (which makes no sense), some of the other layers
>> > presented there should be one which focus on good cartography, and all
>> > that are there now have many of the same issues as the main style.
>> >
>> > I assume that many, perhaps most, casual mappers use the web editor. I'm
>> > really impressed with the web editor, it's great and is mostly
>> > user-friendly, you don't need to be a technical person to map, and that
>> > is how I think it should be. One thing with the web editor though is
>> > that unless you are technical enough to turn off caching (which
>> > essentially means putting the browser

Re: [Tagging] Basic cartography features missing, why?

2020-11-08 Thread Joseph Eisenberg
Re: "Vector tiles could allow for instant client-side switching of map
styles, the ability to customize the base layer, and allow users to make
custom maps themselves"

This is often claimed as a benefit of client-side vector tiles, but in
practice it is not possible.

The reason is that at mid zoom levels there is far too much data in the
database for it all to be made available in a vector tile format so that
the map is fully customizable.

If we were to include all features on the vector tile data, the rendering
would be too slow or would crash for many users, especially those who have
mobile phones, or lower-powered tablets, or even current low-end laptops.

Practical client-side vector tiles have to significantly simplify the data
and remove a number of nodes and features to make the rendering practical.
While some customization is possible (like hiding some icons and labels, or
changing the script or language of the text labels), you are not going to
get a custom rendering from one set of vector tiles.

User pnorman and several others had been working on a demonstration which
re-implements the current OpenStreetMap Carto style in server-side vector
tiles (the first step), but it is quite difficult to achieve a good result
with currently available open source tools, and there will have to be some
compromises which worsen the cartography in some cases.

I have not heard an update on this project in the past few months, so it
may be stalled.

-- Joseph Eisenberg

On Sun, Nov 8, 2020 at 8:48 AM Seth Deegan  wrote:

> And there should be several specialized layers: general car navigation
>> map, sport map for hiking/cycling/skiing, transportation. All of that would
>> be possible with vector tiles which are less computationally demanding to
>> create.
>
> We already have multiple map styles.
>
>
> What they mean is that the current map styles run by other providers will
> not be necessary if we switch to vector tiles.
>
> Vector tiles could allow for instant client-side switching of map styles,
> the ability to customize the base layer, and allow users to make custom
> maps themselves (this is extremely powerful).
>
> This is pretty self explanatory, but I wanted to note earlier that vector
> tiles allow for the clickability/interactivity of every element on the map.
> Most new users who come to osm.org don't even know what the Query Tool
> does or that it exists. It's also pretty inconvenient and slow.
> Making everything clickable allows features to be explored with a possible
> beautiful UI like Google Maps.
>
> On Sun, Nov 8, 2020 at 1:46 AM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> Nov 8, 2020, 05:31 by mach...@gmail.com:
>>
>> I absolutely agree with Seth, OSM should switch to vector tiles ASAP.
>>
>> Note that OSM would not switch to vector tiles. At most one more
>> rendering would switch
>> to vector tiles.
>>
>> For OSM Carto see
>> https://github.com/gravitystorm/openstreetmap-carto/issues/3201
>> (not sure what is the state and what is the current blocker)
>>
>> (sorry if that is overly pedantic)
>>
>> And there should be several specialized layers: general car navigation
>> map, sport map for hiking/cycling/skiing, transportation. All of that would
>> be possible with vector tiles which are less computationally demanding to
>> create.
>>
>> We already have multiple map styles.
>>
>> Their code is all on github so no need to reinvent the wheel and I think
>> this could be easily modified for OSM purposes.
>> https://github.com/FreemapSlovakia
>>
>> Is there somewhere description/summary of their software stack?
>>
>> If there is nobody who can or is willing to do it then let's hire someone
>> who can.
>>
>> Or let a company like Mapbox do it.
>>
>> If someone, anyone is willing to sponsor hosting they can propose to add
>> their tiles to OSM main site (see
>>
>> https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers
>> )
>>
>> Though as business of Mapbox is to offer paid hosting of OSM data it is
>> dubious that they
>> would put special effort into competing with themself. Even free tier of
>> their products
>> requires giving credit card details.
>>
>> I would be willing to do regular monthly donations for someone's salary
>> if that makes OSM better and more attractive.
>>
>> I am not sure how one may donate for specific target of vector tiles
>> (it is also not mentioned at
>> https://wiki.openstreetmap.org/wiki/Donations ).
>>
>> donati...@openstreetmap.org is appearing on the page, maybe

Re: [Tagging] Mapping terraced, irrigated farmland (e.g. rice paddies)?

2020-11-08 Thread Joseph Eisenberg
In Indonesia, the rice paddy terraces are separated by earth or clay
embankments, usually about 1 meter to 2 meters high, made with local soil.

I wouldn't call those "retaining walls", since they are not made out of
stone, brick or concrete.

- Joseph

On Sat, Nov 7, 2020 at 10:46 PM Cascafico Giovanni 
wrote:

> Hi Joseph,
>
> retaining wall [1] is applicable to whatever area
>
>
> Il dom 8 nov 2020, 06:50 Joseph Eisenberg  ha
> scritto:
>
>> Is there a specific tag or method for mapping terraced farmland?
>>
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dretaining_wall
>
>> ___
> 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] Mapping terraced, irrigated farmland (e.g. rice paddies)?

2020-11-07 Thread Joseph Eisenberg
Is there a specific tag or method for mapping terraced farmland?

In areas with any amount of slope, terraces are built so that areas of
cropland can be flood irrigated. This is very common in rice-growing
regions, and also used for some other crops which grow best in flooded
land.

The presence of irrigation might be tagged with "irrigation=yes" - this has
been used about 1600 times in combination with landuse=farmland (See
https://taginfo.openstreetmap.org/tags/irrigated=yes and
https://overpass-turbo.eu/s/ZQq).

And "crop=rice" is widely used for areas where rice is routinely grown each
year.

But what about the fact that the farmland is built in terraces? Is there an
existing way to map this? There is a key "farmland" with about 100 uses of
"farmland=terraced" and a few of "farmland=paddy" (for rice paddies).
Apparently I used this tag myself a half-dozen times:
https://www.openstreetmap.org/way/587624037#map=17/-4.05357/138.92747

Example from Nepal, with aerial imagery in iD:
https://www.openstreetmap.org/edit?way=343286016#map=17/28.01034/84.61103

If a mapper wanted to show every terrace in detail, what would be the best
option? Perhaps man_made=embankment between each layer?

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


Re: [Tagging] How to tag a threshing floor

2020-11-05 Thread Joseph Eisenberg
historic=wayside_shrine and some other values of historic=* are examples
which show that the key "historic=" can be used for features which are
still functional.

A threshing floor is probably still usable for beating grain to remove the
chaff and straw, as intended, but with modern machinery available, these
features will no longer be used in countries with access to capital. They
are still used in remote areas where farmers have very few resources (e.g
Afghanistan, according to some photos available online). But most of those
in use in richer countries will be as historic sites or for special
festivals, as shown in the photos in the wikipedia article:
https://en.wikipedia.org/wiki/Threshing_floor

My preference would be for man_made=threshing_floor however.

-- Joseph Eisenberg

On Thu, Nov 5, 2020 at 10:57 AM António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

> I didn't get it, Mateusz.
> What does historic=wayside_shrine have to do with threshing floor?
>
>
> On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>
> We also have historic=wayside_shrine that is used for ones that are not
> historic at all.
>
>
>
> ___
> 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 - electricity=*

2020-11-05 Thread Joseph Eisenberg
> Re: "Perhaps it would also be possible to then tag electricity:grid=yes
and electricity=no in the case of grid connected houses experiencing a
long-term power outage during a natural disaster?"

Generally OpenStreetMap data is not updated frequently enough by mappers
and database users for us to map temporary states (e.g. anything which
lasts less than 6 months). Many database users will download a data extract
for offline use and only update this every 3 months or so - see Maps.me for
example, and perhaps facebook's  use of OpenStreetMap data.

And most objects in OpenStreetMap are currently only checked and updated
once every few years.

Perhaps someday the community of mappers will be vibrant enough that we
could imagine updating tags every month or every week, but at this point
such a situation is very far away. So for now we should encourage mappers
to focus on permanent or semi-permanent characteristics which are unlikely
to change in the next few months.

-- Joseph Eisenberg

On Thu, Nov 5, 2020 at 6:36 AM Lukas Richert  wrote:

> I have now switched over the tagging and examples to the namespace based
> tagging of grid and generator. Overall, this makes it easier and clearer to
> tag backup generators and grid-connected houses with solar panels etc IMO.
> Perhaps it would also be possible to then tag electricity:grid=yes and
> electricity=no in the case of grid connected houses experiencing a
> long-term power outage during a natural disaster?
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/electricity
>
> Regards, Lukas
> On 03/11/2020 22:07, Lukas Richert wrote:
>
> I also think the *electricity:grid=yes/no/backup* and
> *electricity:generator=yes/no/backup* tags are clearer and would allow
> for off-grid buildings to be tagged more distinctly.
>
> The electricity tag isn't used a lot yet. I have no experience with
> automated or semi-automated edits, but perhaps changing electricity=none
> and electricity=grid to electricity:grid=yes would be relatively
> straightforward? (This is unfortunately the problem with people adding
> major undiscussed/proposed tags to the main wiki. Especially power_supply
> is frustrating. )
>
> What do others think about the tag options
>
> electricity:grid=yes/no/backup
> electricity:generator=yes/no/backup
> electricity=yes
> electricity=no
>
> [electricity=yes would be used when grid or generator is unknown] instead
> of
>
> electricity=grid
> electricity=generator
> electricity=yes
> electricity=no
>
> Cheers Lukas
>
>
> On 03/11/2020 21:20, Andrew Harvey wrote:
>
>
>
> On Wed, 4 Nov 2020 at 00:13, Lukas Richert  wrote:
>
>> Hi,
>>
>> While the original proposal did specify that generators are usually
>> diesel, broadening the definition would only lead to a loss of detail, but
>> the tagging would still be correct. I'm hesitant to use *offgrid* as a
>> building that has, for example, a grid connection with solar panels on the
>> roof would then be tagged as *electricity=grid;offgrid* instead of
>> *electricity=grid;generator*. The former is illogical.
>>
>> However, I don't have any experience in developing countries: is it
>> easier to verify if something is off-grid compared to if it is connected to
>> a generator? And, would it be necessary to differentiate between local
>> grids (i.e. 2-3 generators, no substations, transfromers, etc.) and
>> national grids? Perhaps then a network tag would be useful, i.e.
>> network=national, local, regional similar to the way cycle networks are
>> mapped?
>>
>> A further suggestion was to change the tagging to
>> *electricity:grid=yes/no/backup* and/or
>> *electricity:generator=yes/no/backup*. This might be less ambiguous for
>> tagging amenities or buildings that get electricity from both sources and
>> would then be more consistent with tagging such as
>> *electricity:generator:origin=diesel* when, e.g. a building has a backup
>> diesel generator but is connected to the grid. Unfortunately, it would then
>> not be consistent with the use by the Healthsites Mapping Project, although
>> this already has the inconsistent *electricity=none* tag which should
>> probably be changed directly to *electricity=no.*
>>
> Here is the link to that suggestion I made
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#multiple_values
>  and
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#origin_of_different_sources
>
> The whole point of the proposal process is to identify these potential
> issues, resolve them, and get community agreement. If the goal is just to
> implement someone else's standard then we can't use the wisdom of

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

2020-11-05 Thread Joseph Eisenberg
I'm not able to find any website which clearly talks about a specific
"mourning room", though it is certainly documented that the front room of a
house, often known as a "parlour" at the time, would be used to view the
corpse of a deceased family member. This practice is still common in
Southeast Asia, BTW. This room might also have been called a "sitting
room", and now is likely the "living room".

Do you have a link? Do you think that anyone in the 2000s is likely to be
confused by the term amenity=mourning_room?

-- Joseph Eisenberg

On Thu, Nov 5, 2020 at 10:36 AM Paul Allen  wrote:

> On Thu, 5 Nov 2020 at 18:19, Steve Doerr  wrote:
>
>> On Thu, Nov 5, 2020 at 1:14 PM Paul Allen  wrote:
>>
>>> On Thu, 5 Nov 2020 at 08:46,  wrote:
>>>
>>>>
>>
>>> amenity=mourning_room
>>>>
>>>
>>> Unacceptable.  "Mourning room" was the old name for what is now
>>> known as a "living room" (and was also known as a "parlour"),  A
>>> room in somebody's house which was pressed into use for the
>>> display of a corpse when needed.
>>>
>>>
>> I think you'll find that's a 'morning room', defined by the OED as 'a
>> room used as a sitting room during the morning or early part of the day'.
>>
>
> Those existed too, if you were rich enough to have a very large house
> and could move from room to room to follow the sun.  For most
> people, there was only one sitting room which also served as a place
> to put a corpse.  I thought I gave a link explaining this.
>
> --
> 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 - Rideshare Access

2020-10-31 Thread Joseph Eisenberg
It's almost never standard to use access=bus or access=taxi, it's
bus=yes/no/designated + taxi=yes/no/designated added to another feature
like a highway=* or amenity=parking

I agree with the idea of using private_hire=* instead of rideshare=* because
this appears to be a proper British English term for any non-taxi,
privately arranged transport vehicle, and it's not as misleading as
"rideshare" when used on services like Uber and Lyft. Though I would like
to see more British folks weigh in on the correct terminology.

See
https://en.wikipedia.org/wiki/Taxicabs_of_the_United_Kingdom#Private_hire_(minicabs)

-- Joseph EIsenberg

On Sat, Oct 31, 2020 at 10:51 AM Brian M. Sperlongano 
wrote:

> Actually I quite like "private_hire" as an access value.
>
>
> Are you suggesting access=private_hire as a tag?  That would not be
> consistent with how taxi services are tagged.  We don't use access=taxi, we
> use amenity=taxi + taxi=*.  By that logic, the access tagging should use
> private_hire=*, and probably with some value of amenity=.
> ___
> 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] Defining the meaning of capacity tag for tourism=camp_site

2020-10-31 Thread Joseph Eisenberg
Re: "That would be a camp site you can enter with a motorhome, but not with
a trailer."

I don't think that exists in the real world. Motorhomes (aka RVs) are quite
large and long, usually bigger than the combination of a small caravan (aka
trailer) + motorcar.

-- Joseph Eisenberg

On Sat, Oct 31, 2020 at 9:50 AM Jan Michel  wrote:

> On 31.10.20 14:40, Sven Geggus wrote:
>
> > We are already using plural when tagging caravans=yes/no and
> tents=yes/no.
> >
> > Thus I would not suggents to tag this singular in case of capacity.
> >
> > Looking at the current state of tagging in taginfo we have:
> >
> > capacity:caravans 65
> > capacity:caravan 4
> > capacity:tents 241
> > capacity:tent 0
>
> > Thus I do not see a real argument for using singular here.
>
> To complete this list:
> capacity:motorhome  32
> capacity:motorhomes 0
>
> The thing about caravan and caravans is a mess. Both keys actually exist...
> - 'caravan' refers to the vehicle in form of a trailer and whether it is
> allowed to access some highway / area
> - 'caravans' refers to either trailers or full motorhomes and only
> applies to camp_sites.
>
> So, capacity:caravan should be used on parking lots that have spaces for
> cars with trailers, while capacity:caravans should be used on camp_sites
> that accomodate either caravan trailers or motorhomes, but there is no
> distinction possible between both kinds of vehicles.
>
> As a result this is a fully valid tagging:
>
> amenity = camp_site
> caravan = no
> capacity:caravans = 10
>
> That would be a camp site you can enter with a motorhome, but not with a
> trailer.
>
>
> ___
> 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] How are busways mapped, which are not guideways?

2020-10-19 Thread Joseph Eisenberg
I agree that highway=bus_guideway deserved it's own tag, since it is
halfway to a rubber-tyred light metro, and quite similar to the "people
mover" systems often found at airports, which often use concrete guidways
and rubber-tired vehicles.

But since other busways serve the same public transit function and are
exclusively for public transportation use, they are functionally similar
from the perspective of a rider or a mapper.

And there are already some examples of highway=bus_guideway getting misused
for other busways, so it would be helpful to settle on the best way to tag
these:
https://github.com/gravitystorm/openstreetmap-carto/issues/4226#issue-724131173

-- Joseph Eisenberg

On Mon, Oct 19, 2020 at 4:02 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> 18 paź 2020, 20:22 od joseph.eisenb...@gmail.com:
>
> While the current tagging is ok, it seems inconsistent that
> highway=bus_guideway gets its own tag, while other busways which are
> similar in function are tagged as highway=service.
>
> Given that rail-like bus guideway is
> drastically different in its structure from
> roads I see no problem with it getting a
> separate highway value.
> ___
> 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] How are busways mapped, which are not guideways?

2020-10-18 Thread Joseph Eisenberg
Here's an example of an exclusive busway, which is only used by the Orange
Line / G Line bus service in suburban Los Angeles:

https://media.metro.net/riding/images/LinePage_orange_line_header.jpg

The busway is a 2-lane paved surface which is exclusively for public
transit buses. There is a parallel cycleway and footway, but no sidewalks.
Private buses and other vehicles are not permitted on the busway. It used
to be an abandoned railway line which was converted to a busway.

Currently it is mapped as highway=service + service=busway + access=no +
bus=designated - https://www.openstreetmap.org/way/443134693

While the current tagging is ok, it seems inconsistent that
highway=bus_guideway gets its own tag, while other busways which are
similar in function are tagged as highway=service.

- Joseph Eisenberg

On Sun, Oct 18, 2020 at 1:38 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Oct 18, 2020, 10:20 by dieterdre...@gmail.com:
>
>
>
> sent from a phone
>
> On 18. Oct 2020, at 10:14, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> One more note: in some cases only specific buses are allowed (for example,
> only public transport
> buses operated by a municipal company, with private buses not allowed).
>
> In such case bus=private would be a correct tagging, right?
>
>
>
> no, the tag “bus” is for a bus acting as public transport vehicle, not for
> the vehicle class of busses.
>
> There are cases where buses acting as public transport vehicle (travel
> between cities) are
> still not allowed and only city-operated public transport is allowed.
>
> (or is it case of regional difference of not treating privately owned
> buses running scheduled
> open access journeys as a public transport?)
> ___
> 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] How are busways mapped, which are not guideways?

2020-10-18 Thread Joseph Eisenberg
There is an approved tag for bus guideways, where specially-designed buses
are guided by a rail:

But how should ordinary busways be mapped? Right now the suggestion on
highway=bus_guideway is that other busways might be mapped highway=service
+ bus=designated + access=no. (See
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_guideway)

There is also a somewhat common tag service=busway which has been used 2500
times, and can be added to highway=service

Alternatively, the tag highway=busway has been used a couple of dozen
times, and there is a new draft proposal to use this tag instead of
highway=service, for standard busways:
https://wiki.openstreetmap.org/wiki/Tag:highway=busway

A new tag would require database users to adapt, but since guided busways
already have a specific tag, it seems odd that other exclusive busways are
mapped only as service roads.

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


Re: [Tagging] Feature Proposal - RFC - Rideshare Access

2020-10-14 Thread Joseph Eisenberg
Clare,

The "proposal" section currently fails to include the actual proposal: that
is, what new key and tags are you proposing to use?

It looks like the proposal is: "approve the use of the new key "rideshare="
with values "yes" and "no" to specify legal access for rideshare vehicles."

But you will also need to add a definition of a "rideshare vehicle", since
this will need to be translated for places where Lyft and Uber do not
operate, and where English is not used (e.g. Indonesia). Unfortunately I
don't see a good online source for a definition.

Is a Gojek motorcycle a rideshare vehicle? See
https://en.wikipedia.org/wiki/Gojek
What about pedicabs (tricycles) which are hailed with a smartphone app?
Or should only passenger cars be included?
What about taxis which also get fares via an app?

- Joseph Eisenberg

On Wed, Oct 14, 2020 at 1:44 PM Clare Corthell via Tagging <
tagging@openstreetmap.org> wrote:

> Hi Tagging List,
>
> Here is the RFC for the proposal for rideshare vehicle access:
>
> Proposal:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Rideshare_Access
>
> Discussion:
> https://wiki.openstreetmap.org/w/index.php?title=Talk:Proposed_features/Rideshare_Access
>
>
> This proposes the addition of rideshare as a use-based access mode for
> land-based transportation. This would enable mapping restriction or
> permission of rideshare vehicles to nodes and ways. As mentioned in the
> proposal example cases
> <https://wiki.openstreetmap.org/wiki/Proposed_features/Rideshare_Access#Case_.231:_Denver_Airport>,
> this typically arises in dense traffic patterns such as airport pickup
> zones.
>
> This proposal originated from the experience of the Lyft mapping team
> seeking to improve the accuracy of routes we build from an OSM-based map.
> Because our rideshare operations are North America based, we bring a
> perspective that centers the policy for right-of-way in this context. We
> would especially appreciate feedback on the applicability of this tagging
> to other parts of the world.
>
> Looking forward to your commentary and feedback.
>
> Clare
>
> --
> Clare Corthell
> Product Manager, Lyft Mapping
> *How Lyft Creates Hyper-Accurate Maps from Open-Source Maps and Real-Time
> Data
> <https://eng.lyft.com/how-lyft-creates-hyper-accurate-maps-from-open-source-maps-and-real-time-data-8dcf9abdd46a>*
>
>
> ___
> 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] How do you map traffic signals where right or left turns are allowed or not allowed on a red light?

2020-10-11 Thread Joseph Eisenberg
In North America (since we hate pedestrians) usually it is legal to turn
right at a red light (we drive on the right side of the road, so a right
turn only involves crossing into one lane).

At some intersections where there are many pedestrians, there are signs
that say "no turn on red", or sometimes "no turn on red except bicycles".

Should this be mapped as a Relation:restriction? For example, a relation
with "restriction=no_turn_on_red" + "except=bicycle"?

Alternatively, I see there is a tag used in Europe in the form
"red_turn:right:bicycle=yes" + "red_turn:right=no" - this would mean that
bicycles may turn red at a traffic signal but other vehicles may not turn.
This is documented at https://wiki.openstreetmap.org/wiki/Red_turn

That tag is also used when right turns are allowed, e.g.
"red_turn:left=yes", when this would not always be expected. It's most
often used in Dresden.

Oddly, it is proposed on the page that you could also use
"red_turn:straight:bicycle=yes" to say that "bicycles are allowed to go
straight at this traffic light when it is red", but this sounds very
strange to me.

I wonder if "red turn" is a translation from German or another language?

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


[Tagging] Mapping floating booms?

2020-10-08 Thread Joseph Eisenberg
A boom is a floating visual or physical barrier used across canals, rivers
and around harbours to delineate places where boats, canoes or swimmers
should not cross.

The wikipedia page isn't very good (it mostly focuses on historic chain
barriers rather than current floating booms), but has some description.: "
*boom* ... is an obstacle strung across a navigable stretch of water to
control or block navigation.
https://en.wikipedia.org/wiki/Boom_(navigational_barrier)
Also see https://en.wikipedia.org/wiki/Log_boom and
https://en.wikipedia.org/wiki/Boom_(containment) - two specialized type of
booms which stop floating logs, trash or oil.

Here are a few examples:

https://commons.wikimedia.org/wiki/File:Hydro_Tasmania_floating_safety_barrier.jpg

https://commons.wikimedia.org/wiki/File:Floating_boom_at_the_beach_in_Pattaya.jpg

https://commons.wikimedia.org/wiki/File:Floating_barrier_on_Ballona_Creek.jpg

Recently a user suggested mapping these as barrier=boom, and this has been
used about 30 times, however that tag has also been used a dozen times for
lift gates (also called a "boom" in some languages, eg:
https://commons.wikimedia.org/wiki/File:Bourke-Docker_Street_level_crossing_boom_gate.jpg
)

The tag man_made=boom is equally (un)common:
https://taginfo.openstreetmap.org/tags/man_made=boom

A somewhat more common option is waterway=floating_barrier which has been
used 104 times, mostly in England:
https://taginfo.openstreetmap.org/tags/waterway=floating_barrier - and
there are some uses of similar tags like waterway=barrier and
waterway=surface_barrier.

The most common current tag is the complicated
seamark:obstruction:category=boom
https://taginfo.openstreetmap.org/tags/seamark%3Aobstruction%3Acategory=boom
- there are 265 ways with it, mostly in the the Netherlands. I wouldn't
really recommend this tag since it is excessively complicated.

So, what's the best option? man_made=boom, barrier=boom,
waterway=floating_barrier?

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


Re: [Tagging] Battery swapping spot in a charging station or being an individual tag?

2020-10-05 Thread Joseph Eisenberg
It's better to create a new tag like "amenity=battery_swapping" or
something like that, because this is not a place where you can plug in your
own electric vehicle to charge it.

-- Joseph Eisenberg

On Mon, Oct 5, 2020 at 10:00 AM 德泉 談 via Tagging 
wrote:

> Hi All,
>
> I want to write a new proposal about the battery swapping system for the
> automotive vehicle. I'm not sure if modifying amenity=charging_station is
> better or creating a new tag amenity=battery_swapping. I prefer to use
> amenity=charging_station but found that is not a easy thing to do that.
>
> The background of the proposal is that I have a scooter that I can swap
> the battery in the convenience stores and the fuel stations. In my country
> there are two network of battery swapping system: Gogoro Network and iOnex,
> people can find the battery swapping stations in many place around the city.
>
> This is what a basic battery swapping station look like:
>
> https://c8.alamy.com/comp/PK9WN2/a-battery-swapping-station-for-gogoro-electric-scooters-in-taipei-PK9WN2.jpg
>
> I also read some news that shows that some car producers in China are
> preparing the battery swapping system for the car, even though I'm not sure
> whether they will success or not.
>
> There are some possible way to make the amenity=charging_station to
> involve them:
> * Use socket: like socket:gogoro_network and add a
> battery_swapping=yes
> * Use a new tag charging=battery_swapping and keep the
> newtork=gogoro_network
>
> The later can let it being rendered as individual icon easily maybe a
> dispenser with a swap arrow but not a dispenser with a charging socket, but
> the old stations that use the sockets should add a new tag charging=socket
> to reduce the confusion. Another problem is that if a charging station have
> both battery swapping and socket ability, then we should make two separated
> element to do that.
>
> It is hard to consider which is the better way to tag the battery swapping
> stations. Please leave some comment of your opinion, thanks.
>
> - Tan
>
> ___
> 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 - Voting - Takeaway drink shops

2020-10-05 Thread Joseph Eisenberg
The page was edited by the author to clarify that the new proposed tag is
amenity=drinks

"A place [which] sells bubble tea, milk tea, milk, juice and other similar
beverages."

I don't think that we should have coffee shops, bubble tea (boba/tapioca),
juice bars and shops that sell smoothies all under the same tag. A smoothie
is hardly similar to a hot coffee, no?

 Also, based on the current definition it's not clear whether or not this
tag could be used for shops which sell alcoholic drinks: this is an
important distinction.

- Joseph Eisenberg

On Mon, Oct 5, 2020 at 12:20 AM Graeme Fitzpatrick 
wrote:

>
>
> On Mon, 5 Oct 2020 at 16:46, 德泉 談 via Tagging 
> wrote:
>
>> Dear All,
>>
>> The voting of the takeaway drink shops is on, please vote the proposal
>> here:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Takeaway_drink_shops
>
>
> What's the actual name of the proposal?
>
> Is it amenity=drinks?
>
> The page is titled takeaway_drink_shops but the proposal is still marked
> as shop=bubble_tea.
>
> 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 - (shop=direct marketing)

2020-10-01 Thread Joseph Eisenberg
Wieland,

The proposed definition of this tag shop=direct_marketing is "a place where
products from own, private production can be purchased".

This is too broad. Please consider that in most countries there are no
regulations that prevent anyone from opening a small shop in front of their
home (Western Europe and North America are exceptions), and a shop can be a
stall or booth next to the street, or the front room of a residence.

If someone knits clothing by hand and sells it from a small shop in the
front room of their house, this should be a shop=clothes, not a
shop=direct_marketing. If they bake bread to sell it the public, it should
be a shop=bakery. If someone keeps bees and sells the honey, that is a
shop=honey if it is publicly available. If not, they might be a
craft=beekeeper.

If on the other hand they only sell the products via the internet or mail
order and there is no shop, there might not be anything to map, or perhaps
the key craft=* would be more appropriate in some cases.

For the state example of e.g. game meat, if the animal has been butchered
(the game meat has been dressed and prepared in smaller portions), then
shop=butcher is appropriate, or if there is no public shop then perhaps a
new value craft=butcher would work. If the hunter is selling whole animal
carcassas without any preparation, perhaps a different value is better.

I'm having trouble imagining a situation where "direct_marketing" is the
best description.

-- Joseph Eisenberg

On Thu, Oct 1, 2020 at 12:48 PM Wieland Kestler 
wrote:
>
> Hi everyone!
>
>
>
> Due to the discussion in the german OSM-Telegram-group I made a proposal
for tagging points where people can buy e.g. game (meat) directly from the
forester.
>
>
>
> For more details see the proposal page:
https://wiki.openstreetmap.org/wiki/Proposed_features/shop%3Ddirect_marketing
>
> For comments use the discussion page:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Ddirect_marketing
>
>
>
> Tanks!
>
>
>
> Wieland
>
>
>
>
>
> ___
> 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] Large fire perimeter tagging?

2020-09-24 Thread Joseph Eisenberg
Most large wildfires do not burn the canopy (the tallest trees) in forests
with trees over 10 meters in height.

The perimeter of the wildfire, shown commonly on public maps, does not
determine which areas have been burned. Often there are large areas of
vegetation along canyon bottoms and streambeds which are unburned, within
the perimeter.

You will need new aerial imagery or detailed on-the-ground survey to
determine the surviving areas of vegetation.

I would not recommend attempting to map the current official perimeter of
the fire, since this changes on a daily or hourly basis: it is a temporary
event which is not really verifiable from the standpoint of an
OpenStreetMap volunteer mapper.

Database users who need these perimeters should download the latest version
from the official sources.

- Joseph Eisenberg

On Thu, Sep 24, 2020 at 2:32 PM stevea  wrote:

> I didn't get a single reply on this (see below), which I find surprising,
> especially as there are currently even larger fires that are more
> widespread all across the Western United States.
>
> I now ask if there are additional, appropriate polygons with tags I'm not
> familiar with regarding landcover that might be added to the map (as
> "landuse=forest" might be strictly true now only in a 'zoning' sense, as
> many of the actual trees that MAKE these forests have sadly burned down, or
> substantially so).
>
> Considering that there are literally millions and millions of acres of
> (newly) burned areas (forest, scrub, grassland, residential, commercial,
> industrial, public, private...), I'm surprised that OSM doesn't have some
> well-pondered and actual tags that reflect this situation.  My initial
> tagging of this (simply tagged, but enormous) polygon as "fire=perimeter"
> was coined on my part, but as I search wiki, taginfo and Overpass Turbo
> queries for similar data in the map, I come up empty.
>
> First, do others think it is important that we map these?  I say yes, as
> this fire has absolutely enormous impact to what we do and might map here,
> both present and future.  The aftermath of this fire (>85,000 acres this
> fire alone) will last for decades, and for OSM to not reflect this in the
> map (somehow, better bolstered than a simple, though huge, polygon tagged
> with fire=perimeter, start_date and end_date) seems OSM "cartographically
> misses something."  I know that HOT mappers map the "present- and
> aftermath-" of humanitarian disasters, I've HOT-participated myself.  So,
> considering the thousands of structures that burned (most of them homes),
> tens of thousands of acres which are burn-scarred and distinctly different
> than their landcover, millions of trees (yes, really) and even landuse is
> now currently tagged, I look for guidance — beyond the simple tag of
> fire=perimeter on a large polygon.
>
> Second, if we do choose to "better" map these incidents and results (they
> are life- and planet-altering on a grand scale) how might we choose to do
> that?  Do we have landcover tags which could replace landuse=forest or
> natural=wood with something like natural=fire_scarred?  (I'm making that
> up, but it or something like it could work).  How and when might we replace
> these with something less severe?  On the other hand, if it isn't
> appropriate that we map any of this, please say so.
>
> Thank you, especially any guidance offered from HOT contributors who have
> worked on post-fire humanitarian disasters,
>
> SteveA
> California (who has returned home after evacuation, relatively safe now
> that this fire is 100% contained)
>
>
> On Aug 29, 2020, at 7:20 PM, stevea  wrote:
> > Not sure if crossposting to talk-us is correct, but it is a "home list"
> for me.
> >
> > I've created a large fire perimeter in OSM from public sources,
> http://www.osm.org/way/842280873 .  This is a huge fire (sadly, there are
> larger ones right now, too), over 130 square miles, and caused the
> evacuation of every third person in my county (yes).  There are hundreds,
> perhaps thousands of structures, mostly residential homes, which have
> burned down and the event has "completely changed" giant redwoods in and
> the character of California's oldest state park (Big Basin).
> >
> > This perimeter significantly affects landuse, landcover and human
> patterns of movement and activity in this part of the world for a
> significant time to come.  It is a "major disaster."  I'm curious how HOT
> teams might delineate such a thing (and I've participated in a HOT fire
> team, mapping barns, water sources for helicopter dips and other human
> structures during a large fire near me), I've simply made a polygon tagged
> fire=perimeter, a name=

Re: [Tagging] Best practices regarding implied tags

2020-09-20 Thread Joseph Eisenberg
The previous responses are focusing on the benefit of adding explicit tags
in situations where the current tagging is ambiguous.

Certainly there is a benefit of adding "oneway=no" on all two-way roads and
"oneway=yes" on motorways to make the situation explicit.

But the original question was about whether or not we should add
"man_made=utility_pole" + "utility=power" to current power poles.

These are currently tagged "power=pole" which is clearly defined as a power
utility pole, so adding the two other tags does not provide any information.

Does anyone think that it is a good idea to add those two new tags in this
particular situation?

-Joseph Eisenberg

On Sun, Sep 20, 2020 at 9:46 AM François Lacombe 
wrote:

> Thank you all for replies
>
> Then the current proposal sounds to be ok regarding what is said upside.
> I admit to automatically adding implied tags when importing data covered
> by the proposal, so no apparent problem is mappers add them explicitly.
>
> All the best
>
> François
>
> Le jeu. 17 sept. 2020 à 15:11, Kevin Broderick  a
> écrit :
>
>> +1.
>>
>> Explicit tagging indicates a level of confidence not generally associated
>> with implicit tagging. While there's certainly an 'ad nauseum' level of
>> doing so (e.g. adding surface=paved, motor_vehicle=yes to highway=motorway
>> in the U.S. would be kinda silly, IMO), there are plenty of cases where a
>> primary tag generally implies something about the tagged object but doesn't
>> guarantee it. I'd point to the recent discussion of access= on driveways as
>> an example; while most driveways allow for certain types of access by
>> default, it's far from guaranteed—there may be a no-trespassing sign or a
>> locked gate, and explicitly indicating the lack of such in the access
>> tagging is helpful. (Adding the implied value without survey or other
>> definitive knowledge is not, as then you express a higher degree of
>> confidence than actually exists in the data).
>>
>> On Wed, Sep 16, 2020 at 6:34 PM Paul Johnson  wrote:
>>
>>> On Wed, Sep 16, 2020 at 5:20 PM François Lacombe <
>>> fl.infosrese...@gmail.com> wrote:
>>>
>>>> Is that completely wrong or mappers could eventually add implied tags
>>>> if they want to?
>>>> The proposal currently states they are optional and it won't raise an
>>>> error if mappers add them beside mandatory tags.
>>>>
>>>
>>> No, it's not wrong to add implied tags explicitly.  It's actually
>>> encouraged in some cases where the implicit tag is not consumable by
>>> automated system (such as the "none" default for turn:lanes tends to be
>>> ambiguous between "you can't turn from this lane" and "you can't use this
>>> lane" and "there's an implicit but unspecified implication that isn't
>>> painted on the ground"), or access defaults (such as in the US where
>>> bicycle=* and foot=* varies a lot on highway=motorway)
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> --
>> Kevin Broderick
>> k...@kevinbroderick.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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Addition of highway=emergency_bay and priority_road=yes to Map Features?

2020-09-15 Thread Joseph Eisenberg
Two tags were just added to the list of approved and de-facto highway
<https://wiki.openstreetmap.org/wiki/Key:highway>=* tags on Map features:
highway <https://wiki.openstreetmap.org/wiki/Key:highway>=emergency_bay
<https://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_bay> and
priority_road <https://wiki.openstreetmap.org/wiki/Key:priority_road>=yes
<https://wiki.openstreetmap.org/w/index.php?title=Tag:priority_road%3Dyes=edit=1>.
Both have mainly been used in Germany and nearby areas of central Europe.

https://wiki.openstreetmap.org/wiki/Key:priority_road
https://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_bay

I question whether these tags are established enough to merit inclusion on
the Highway map features page and the main Map Features list. Thoughts?

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


Re: [Tagging] Tagging of individual terraced houses?

2020-09-07 Thread Joseph Eisenberg
I am confused. Do you want to map the whole thing as a single
building=terrace, or each part separately as it’s own building=* area?

Where would you use the tag terraced=yes or terraced=apartments?

On a building:part=* or on individually drawn building=house areas?

-Joseph

On Mon, Sep 7, 2020 at 7:33 AM Oliver Simmons  wrote:

> For terraced houses `building=terrace` is used for the whole block,
> but there is no tag for each individual building when they are separate,
> the reason for this is because the terraced building could be any of the
> `building=*` values, a shop, a house e.t.c, it could even be a weird small
> church; they are not always houses.
>
> `terraced=yes/apartments` has 227 uses on tag*info*
> , but no wiki page or
> discussion as far as I know.
> Should I make a page for it?
> Or should a proposal be made (I have no idea how these work)?
>
> Please note `terrace=*` (tag*info*
> ) is for used something
> else (not sure what, but it doesn't matter anyways)
>
>
> ___
>
> 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] Biker’s rests

2020-09-04 Thread Joseph Eisenberg
In US English we seem to call these “leaning rails”, but they are fairly
new. I’m not sure what term is correct in British English.

Since they are distinctive features, they can be mapped, perhaps using the
man_made= key.

-Joseph Eisenberg

On Fri, Sep 4, 2020 at 10:46 AM Grzegorz Szymaszek 
wrote:

> Hi,
>
>
>
> At some bicycle crossings in some cities there are “biker’s rests”
>
> installed that cyclists can support on while waiting for the green
>
> light. They look like [1], [2], or [3].
>
>
>
> I could not find any existing tag for this furniture. Do you know of any
>
> way of tagging them? Do you consider them worth adding to OSM?
>
>
>
> Links:
>
> [1]: https://farm5.static.flickr.com/4041/4271442334_95e966f057.jpg
>
> [2]:
> https://www.rybnik.eu/fileadmin/_processed_/a/2/csm_skrzyzowania_rowery_dagmara_kubik_2_7046439b78.jpg
>
> [3]: https://nola.se/wp-content/uploads/BIKERS_REST_slussen_web.jpg
>
>
>
> Thanks
>
>
>
> --
>
> Grzegorz
>
> ___
>
> 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] Village swings, for adults, in Eastern Europe and elsewhere?

2020-08-24 Thread Joseph Eisenberg
There is a newly documented tag:
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dvillage_swing

"A village swing (Estonian: külakiik, Finnish: kyläkeinu) is a large swing
that is designed to be ridden by multiple adults. They are typically made
out of wood and are common on village recreational grounds in Estonia and
Finland."

The other, common tag for swings intended for children is playground=swing
- https://wiki.openstreetmap.org/wiki/Key:playground#Motion_devices

The key "playground=" suggests that these are usually intended for
children, since they are usually inside of a leisure=playground feature
which is defined as for children: "a children's playground, playpark, or
play area. These are outdoor (sometimes indoor) areas specifically designed
for children to play. " -
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dplayground

Traditional village swings in Estonia are different than the modern ones
for children, but they are clearly the same sort of thing, though with a
different audience.

Should we suggest using playground=swing even for these traditional devices
for adults, or is it better to have a totally new tag?

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


Re: [Tagging] Network-tag needs extension

2020-08-24 Thread Joseph Eisenberg
Since the tag has already been used 20k times, it is ok to make a page
which documents how the tag is currently being used by most mappers.

But if you want to change the definition Or other wiki pa a, or recommended
use of any tags, then you should use the proposal process.

- Joseph Eisenbweg

On Mon, Aug 24, 2020 at 11:58 AM Michael Schmidt via Tagging <
tagging@openstreetmap.org> wrote:

> So, how to go on from here? My proposal stands.
>
> To substantiate this, I found on taginfo, that network:short is actually
> in usage: 21k (btw. network:long: 34)
>
> I saw, that there are votes, but I'm totally New to the tagging mailing
> list..
>
> Regards
> Michael___
>
> 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] Benches and hostile architecture

2020-08-24 Thread Joseph Eisenberg
RE: "Would something like hindrance:target = lying_down or hindrance:target
= sitting be more clear?"

While this is somewhat less ambiguous, it looks and sounds quite strange in
English, and it's quite long.

How about "lying_down=obstructed", "sitting=obstructed",
"skating=obstructed" or something like that?

I also think it would be a good idea to tag the physical obstructions, like
width=, length=, slope=, arm_rests=, spikes=, skatestoppers=, etc, as
others have mentioned.

– Joseph Eisenberg

On Mon, Aug 24, 2020 at 6:46 AM Vucod via Tagging 
wrote:
>
> Just to clarify an important point. The hostile_architecture key was
suggested as a main/category tag to go along with specific keys
(lying_hindrance, sitting_hindrance).
> Used alone, I agree that it would be very vague and could be difficult to
verify. I would say to only use it in combination with specific keys but I
don't know how this would be followed by mappers...
>
> On the specific tags:
>
> @Josepth Eisenberg(mail below):
>
> As others have said, no_* and *=prohibited loose the notion of hindrance
that is crucial if we want to map physical and visible things. Would
something like hindrance:target = lying_down or hindrance:target = sitting
be more clear? And yes, the goal is to make clear that {lying|sitting|...}
is physically obstructed (no relation to legal usage).
>
> @Martin Koppenhoefer :
>
> "what about benches being completely removed (or never installed), it’s
equally hostile but not mappable. Or shops who are right away not built in
a way that you could sit down on their facade."
>
> With tags like lying_hindrance and sitting_hindrance, we don't look for
the intentions of the builders but we just look for these hindrances. So,
we would not map your examples.
>
> "quite common in Rome are inside corners of buildings filled with masonry
(typically up to 1,5m) so people do not urinate (not a recent feature, most
look as if they were hundreds of years old). And in this case, it’s also
probably more beneficial than hostile in the general perception. At least I
guess many of us would deny a right of public urination in the city?"
>
> Yes with the term "hostile", an opinion could be seen behind it but the
term "hostile architecture" refers to the enforcement/prevention of some
> behaviors whether it is good or not. In German and French, they use
defensive architecture/ defensive urban design where it is less opinionated.
>
> @Mateusz Konieczny : ""length was refused as an official key for bench"
Why? Is there some valid reason, or maybe it was part of proposal that
failed for other reasons."
>
> length and width keys on benches were refused because they judged that it
was going too much into details (
https://wiki.openstreetmap.org/wiki/Proposed_features/Attributes)
>
>
> On the generic tag:
>
> As info:
>
> - "Hostile architecture", a Wikipédia article, a subreddit and 150 000
google results
> - "Hostile design", 20 000 google results
>
> Vucod
>
> August 23, 2020 10:22:38 PM CEST Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:
>
> The term "hostile architecture" is too vague. As an alternative
"anti-homeless" is also not precise enough. We are getting closer with the
initial suggestion that the feature is to prevent lying down, sleeping or
sitting.
>
> However, I think the tags "sitting_hindrance=" and "lying_hindrance" are
not clear enough in English. The term "lying" is ambiguous, since it can
refer to "telling lies" (falsehoods) as well. Also, in English syntax it
sounds strange to say something is a "lying hindrance", because this would
normally be an obstacle which is lying down, rather than a hindrance to a
person lying down.
>
> So it would be better to change the order of words in the tags, e.g.
"no_lying=" and "no_sitting=" , or just simplify to "sitting=prohibited"
and "lying_down=prohibited" or similar. But I admit that none of those
options are perfectly clear. Perhaps someone else has a better phrase?
>
>
> We want to make it clear that lying down or sitting down is not allowed
or physical obstructed, right?
>
> -- Joseph Eisenberg
>
> On Sun, Aug 23, 2020 at 10:38 AM Paul Allen  wrote:
> >
> > On Sun, 23 Aug 2020 at 18:22, Oliver Simmons 
wrote:
> >
> >> Someone else can probably think of a better suggestion
> >
> >
> > https://en.wikipedia.org/wiki/Hostile_architecture
> >
> > --
> > 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
>
> ___
> 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] bridge:name and tunnel:name

2020-08-23 Thread Joseph Eisenberg
That's correct. It's still important to mark the highway features with
bridge=yes so that database users will know that the road or path is on a
bridge. Drawing the man_made=bridge outline is a way to map the area and
shape of the bridge itself, but it doesn't affect the rivers and roads
around it.

Sometimes a layer tag is needed. For simple bridges this is not really
necessary, though most editors prompt you to add it for consistency.

- Joseph Eisenberg

On Sun, Aug 23, 2020 at 10:24 PM Graeme Fitzpatrick 
wrote:

>
>
>
> On Mon, 24 Aug 2020 at 10:30, Martin Koppenhoefer 
> wrote:
>
>> Draw the bridge outline and tag it with man_made=bridge name=* and you’ll
>> see what I mean.
>>
>
> Thanks Martin - yep, it works!
>
> https://www.openstreetmap.org/#map=19/-28.13129/153.48123
>
> Have just fixed a few of them in the general area & found one slight issue.
>
> Even if you draw in a bridge area, & mark it as layer=1, any roads /
> footways running across that bridge also have to be marked themselves as
> bridge=yes + layer=1, otherwise they will clash with the river / road
> underneath, so the map will show a bridge running across the area of a
> bridge.
>
> Does that sound right, or is it a hiccup of some sort?
>
> 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] Benches and hostile architecture

2020-08-23 Thread Joseph Eisenberg
I understand that it's the normal term for the general concept, but it
includes a large number of things:

"measures include sloped window sills to stop people sitting; benches with
armrests positioned to stop people lying on them, and water sprinklers that
"intermittently come on but aren't really watering anything."[4][5] Hostile
architecture is also employed to deter skateboarding, littering, loitering,
and public urination."

There is an example of a 1800s church with a sloped wall, designed to
deflect urine. That's quite different than spikes on a threshold, armrests
on a bench, or metal brackets on the edge of a curb (meant to deter
skateboarding).

It's a big category, so it would be best to use precise tags for each
thing.

For example, if you want to tag a kerb which has guard to prevent easy
skateboarding, then add something like "anti-skate_devices=yes" or
"skate_prevention=yes", don't use "hostile_architecture=yes" because that
is non-specific: it's not clear if what is prevented is sitting, lying
down, or skating.

-- Joseph Eisenberg

On Sun, Aug 23, 2020 at 2:20 PM Peter Elderson  wrote:
>
> The British really call bench construction "architecture"? Amazing. I can
see this going the same way as village green.
>
> Mvg Peter Elderson
>
> > Op 23 aug. 2020 om 22:59 heeft Andy Townsend  het
volgende geschreven:
> >
> > On 23/08/2020 21:22, Joseph Eisenberg wrote:
> >> The term "hostile architecture" is too vague.
> >
> > It is the normal British English (at least) description of this stuff.
> >
> > 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Benches and hostile architecture

2020-08-23 Thread Joseph Eisenberg
The term "hostile architecture" is too vague. As an alternative
"anti-homeless" is also not precise enough. We are getting closer with the
initial suggestion that the feature is to prevent lying down, sleeping or
sitting.

However, I think the tags "sitting_hindrance=" and "lying_hindrance" are
not clear enough in English. The term "lying" is ambiguous, since it can
refer to "telling lies" (falsehoods) as well. Also, in English syntax it
sounds strange to say something is a "lying hindrance", because this would
normally be an obstacle which is lying down, rather than a hindrance to a
person lying down.

So it would be better to change the order of words in the tags, e.g.
"no_lying=" and "no_sitting=" , or just simplify to "sitting=prohibited"
and "lying_down=prohibited" or similar. But I admit that none of those
options are perfectly clear. Perhaps someone else has a better phrase?

We want to make it clear that lying down or sitting down is not allowed or
physical obstructed, right?

-- Joseph Eisenberg

On Sun, Aug 23, 2020 at 10:38 AM Paul Allen  wrote:
>
> On Sun, 23 Aug 2020 at 18:22, Oliver Simmons 
wrote:
>
>> Someone else can probably think of a better suggestion
>
>
> https://en.wikipedia.org/wiki/Hostile_architecture
>
> --
> 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 -Funeral hall

2020-08-19 Thread Joseph Eisenberg
In the US, there are privately owned cemeteries, often with a private
funeral home / mortuary building on the site. You can buy a plot and also
pay for the funeral services, including the use of a hall for a viewing,
reception or funeral service (religious or otherwise).

 E.g.:
https://www.dignitymemorial.com/funeral-homes/glendale-az/west-resthaven-funeral-home/4707
- a funeral home and private cemetery.

In many American cities most of the cemeteries, crematoriums and mausoleums
are privately owned and operated.

So my question is if we should add this new tag to the reception / service
halls which are found at at private funeral homes / mortuaries as well?
Often these are in the same building as the crematorium and the morgue
(where bodies are prepared and stored prior to burial or cremation), and
the offices and reception for the funeral home are also there.

Or are we only thinking to use this new tag for stand-alone halls?

It would also be good to clarify how these are different than a
place_of_worship. For example, consider the many non-sectarian chapels and
prayer rooms found in airports, shopping centres, hospitals, and similar
public facilities. Aren't those tagged as amenity=place_of_worship - or is
that also a mistake?

- Joseph Eisenberg

On Wed, Aug 19, 2020 at 7:13 AM  wrote:

> Not important at all. I just think that if it is ancillary to the
> business of selling coffins, transporting corpses, preparing them for
> burial, doing paperwork in relation to that etc. (what the French call a
> "funérarium"), then it doesn't deserve a tag distinct from the funeral
> directors tag (but if a majority think otherwise, I don't have strong
> feelings about it either).
>
> Am 19.08.2020 15:47 schrieb Martin Koppenhoefer:
> > sent from a phone
> >
> >>> On 19. Aug 2020, at 15:33, woll...@posteo.de wrote:
> >> I could imagine rare cases of a privately run cemetery not linked to
> >> any religion or belief/life stance and where there is such a building.
> >> But typically, they would be public.
> >
> >
> > let me rephrase my question: how important is it that the facility is
> > “public”?
> > IMHO this feature should have a functional definition only, everything
> > else depends on the context and is not really relevant.
> >
> > 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] Feature Proposal - RFC -Funeral hall

2020-08-18 Thread Joseph Eisenberg
There is already an existing tag with similar meaning for funeral homes /
funeral halls / funeral directors:  shop=funeral_directors.
The use of the key "shop=" is odd, but it's been used over 20,000 times so
it seems to be well established:

https://wiki.openstreetmap.org/wiki/Tag:shop%3Dfuneral_directors -
documented since 2009:

"Also known as a "funeral parlour","undertaker", "funeral home", or
"memorial home".

A funeral directors  shop
is a place where arrangements to permanently store the physical body after
death are made. An event (sometimes with the deceased's body present) to
honor the deceased for mourners are held here in conjunction with religious
services which are held elsewhere."
There is also a related tag amenity=mortuary -
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dmortuary

On Tue, Aug 18, 2020 at 1:03 PM  wrote:

> Dear list,
>
> Please comment on the following proposal:
>
> Funeral hall: a building for funeral ceremonies which may be religious
> or secular
>
> Proposal page:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Funeral_hall
> Discussion page:
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Funeral_hall
>
> Thanks!
>
> Vollis
>
>
>
>
> ___
> 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 equivalent of noexit=yes?

2020-08-14 Thread Joseph Eisenberg
The “rise” where the stream comes back to the surface would usually be
mapped as natural=spring

If there is also a cave entrance at the same spot where the watercourse
exits a cave, then the tag natural=cave_entrance can be used

- Joseph

On Fri, Aug 14, 2020 at 6:21 AM Kevin Kenny  wrote:

> On Fri, Aug 14, 2020 at 7:08 AM Paul Allen  wrote:
>
>> On Thu, 13 Aug 2020 at 06:42, Mark Wagner  wrote:
>>
>>>
>>> For a larger and far more dramatic example of this sort of situation,
>>> look at the area to the west of Death Valley Playa.  It looks like
>>> someone stacked hundreds of river deltas on top of one another, but
>>> forgot to add the water.
>>>
>>
>> As I understand it (possibly not all that well) a sinkhole as the wiki
>> defines it
>> is a large hole in the ground which water enters and vanishes without
>> pooling.
>> What Ordnance Survey calls "sinks" appears to be more akin to a hole in a
>> golf
>> course that water enters and vanishes.  What Ordnance Survey calls
>> "spreads"
>> is a sand or soil or gravel surface that water vanishes into without
>> pooling and without there being any noticeable hole.
>>
>
> The WIki picture of a sinkhole happens to be large, but in karst terrain
> they come in all sizes. https://www.openstreetmap.org/node/5599524737 is
> a sinkhole of quite a small stream. I couldn't find a good way to tag the
> rise a short distance to the west.
> https://www.openstreetmap.org/way/226924460 is a much larger sinkhole. In
> a wet season there's significant outflow to the east, but in a dry season
> all of the outflow from the lake runs through the caves, exiting through
> cracks in the limestone below the cliffs to the east. Many of the small
> streams thus formed haven't been mapped because there are significant
> technical challenges to mapping them. GPS coverage at the cliff bases is so
> poor that one would probably have to resort to alidade and plane table, and
> the evergreen cover is dense enough that you can't see much that's useful
> on satellite imagery.
>
> I'm not sure if any of those fit what you have and maybe what you have is
>> more of a network of intermittent streams.
>>
>
> What Mark is showing is usually called an alluvial fan.
> https://en.wikipedia.org/wiki/Alluvial_fan
> Some fans have well-defined (perennial or intermittent) distributary
> streams flowing through them. Often, though, most of the stream channels
> are ephemeral in nature. Sometimes an individual channel was cut in a
> matter of hours by a debris flow coming from upriver.
>
> In arid climates, it's entirely possible for the entire flow of the
> stream, except during flash flooding events, to vanish by percolation and
> evaporation, so that there is no river downstream. There's no well-defined
> sinkhole, and no well-defined specific point at which it transitions from
> perennial to intermittent, intermittent to ephemeral, ephemeral to a dry
> wadi that has seen water only in geologic time, eventually disappearing
> entirely into a salt flat.
>
> It's relatively rare to find a fan that's still actively depositing
> sediment. One example is that Mòlèqiē Hé (莫勒切河) in Xinjiang forms an
> enormous and nearly unique one near 37.4°  north, 84.3° east.
> --
> 73 de ke9tv/2, Kevin
> ___
> 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 equivalent of noexit=yes?

2020-08-12 Thread Joseph Eisenberg
Would waterway=spreads only be used for intermittent streams/rivers where
the waterway spreads out and evaporates on the surface?

If the water appears to sink into sand, gravel or fractured karst rock,
would we want a different tag instead, e.g. waterway=sink?

I understand that natural=cave_entrance can also be used when a waterway
drops into a sinkhole or other open cave entrance, often found in limestone
(karst) geology areas.

-- Joseph Eisenberg

On Wed, Aug 12, 2020 at 9:52 AM Paul Allen  wrote:

> On Wed, 12 Aug 2020 at 17:07, Tod Fitch  wrote:
>
>>
>> To clarify it for me, the a “waterway=spread” tag would be used on a node
>> (rendered possibly as an asterisk) or on a way? Or either depending the
>> situation?
>>
>
> I'd say "spreads" rather than "spread" because that's the term OS uses.
> I've only
> ever seen OS use it on the terminal node of a waterway.  More of a
> crow's-foot
> symbol than an asterisk, usually, but an asterisk works.  I have no idea
> how
> you'd render it sensibly on a way.  I assume you're thinking of something
> like a
> very sandy river bed where the water sometimes gets further than other
> times,
> depending on conditions.  I'd be happy enough with a single node, because
> that's better than we have now.  If you can justify applying it to a way
> and
> think there's a need then do so, but if you're just trying to keep QA tools
> happy...
>
> --
> 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] Aerialway stations

2020-08-12 Thread Joseph Eisenberg
There are 2 lines of the Metrocable gondola system in Medellín, Colombia
which have 4 stations each (one has 5 stations, but that actually appears
to be 2 different cable loops)
https://en.wikipedia.org/wiki/Metrocable_(Medell%C3%ADn)

The variety of different types of "aerialway" is quite large, since there
are urban systems and tourist systems in flat regions (theme parks) as well
as mountain areas.

-- Joseph Eisenberg

On Wed, Aug 12, 2020 at 8:04 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> 1) is bottom station always in valley?
> (This should be fixable)
>
> 2) is there case of 2 and more middle
> stations?
>
> 3) is there case of one station being both
> top and bottom station at once?
>
> Also, it uses single known tag, not
> new discussion purpose ones.
>
> Though, yes processing would be
> much more complicated.
>
> I would consider also tagging elevation
> (ele tag from what I remember).
>
>
> 12 Aug 2020, 16:31 by em...@daniel-korn.de:
>
> Am 12.08.2020 um 16:28 schrieb Niels Elgaard Larsen:
>
> dktue:
>
> Hi,
>
> I was wondering why there's no way to distinguish valley and upper
> stations of
> aerialways in OpenStreetMap.
>
> Usually an aerialway consists of
>
>  * one valley station
>  * zero or more mid stations
>  * one upper station (or "mountain station")
>
> What do you think you tagging this information with
>
>
> You could tag the aerialway with incline=up/down
>
>  station=valley_station/mid_station/upper_station
>
> ?
>
> Cheers
> dktue
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
>
> That's true but I think it would be very hard for consumers to extract
> this information (think of an overpass-query to find all mid stations).
> Would there be any advantage in following your suggestions instead of
> explicit tagging?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Joseph Eisenberg
Re: status to indicate "was not voted upon but is widely used and
most people are happy with it"

That's the "de facto" status.

-- Joseph Eisenberg

On Fri, Aug 7, 2020 at 6:09 AM Paul Allen  wrote:

> On Fri, 7 Aug 2020 at 13:53, Matthew Woehlke 
> wrote:
>
>>
>> Well, yes, voting "no" is probably not useful, but this is also the
>> least "interesting" bit of the proposal. The purpose here would be just
>> to bless the tag with "status=approved" rather than "status=de-facto".
>>
>
> But it wasn't approved by a formal vote.  If you mark it status=approved
> then
> it ought to be possible to find the vote that approved it.  Maybe we need
> a different status to indicate "was not voted upon but is widely used and
> most people are happy with it" but we don't have that.  Please don't
> misuse "approved" to mean that.
>
>
> --
> 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] Rio de la Plata edit war

2020-08-05 Thread Joseph Eisenberg
Here's another issue I would like mural...@montevideo.com.uy to address:

In Venezuela the second largest city is on a body of water called "Lago de
Maracaibo":

https://www.openstreetmap.org/relation/11334852

As mentioned in Wikipedia, local Venezolanos often refer to this as a lake
(lago), not an estuary or bay:

*Lake Maracaibo* (Spanish
<https://en.wikipedia.org/wiki/Spanish_language>: *Lago
de Maracaibo*, pronounced [ˈlaɣo ðe maɾaˈkajβo]
<https://en.wikipedia.org/wiki/Help:IPA/Spanish> ([image: About this sound]
<https://en.wikipedia.org/wiki/File:ES-pe_-_Lago_de_Maracaibo.ogg>listen
<https://upload.wikimedia.org/wikipedia/commons/1/16/ES-pe_-_Lago_de_Maracaibo.ogg>
)) is a large brackish <https://en.wikipedia.org/wiki/Brackish> tidal bay
(or tidal estuary <https://en.wikipedia.org/wiki/Estuary>) in Venezuela
<https://en.wikipedia.org/wiki/Venezuela> and an "inlet of the Caribbean Sea
<https://en.wikipedia.org/wiki/Caribbean_Sea>".[1]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-1>[2]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-2>[3]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-3>[4]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-4> It is sometimes
considered a lake <https://en.wikipedia.org/wiki/Lake> rather than a bay
<https://en.wikipedia.org/wiki/Bay> or lagoon
<https://en.wikipedia.org/wiki/Lagoon>.[5]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-Murphy-5>[6]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-NASA-6>[7]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-Limnol-7>[8]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-Publishing2010-8>[9]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-QuinnWoodward2015-9>
[10] <https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-10>[11]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-11>[12]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-12>[13]
<https://en.wikipedia.org/wiki/Lake_Maracaibo#cite_note-13> It is connected
to the Gulf of Venezuela <https://en.wikipedia.org/wiki/Gulf_of_Venezuela>
 by Tablazo Strait <https://en.wikipedia.org/wiki/Tablazo_Strait>, which is
5.5 kilometres (3.4 mi) wide at the northern end.
https://en.wikipedia.org/wiki/Lake_Maracaibo

So, does this mean that Lago de Maracaibo could be mapped as natural=water
or waterway=riverbank instead, if local mappers feel it is a lake rather
than a tidal bay / estuary?

(It is currently mapped with natural=coastline and with a relation tagged
as natural=bay, like most other similar features in OpenStreetMap, with the
exception of the Rio de la Plata)

– Joseph Eisenberg

On Wed, Aug 5, 2020 at 2:52 AM Alan Mackie  wrote:
>
>
>
> On Wed, 5 Aug 2020 at 01:34,  wrote:
>>
>>
>>
>> - Mensaje original -
>> > De: "Joseph Eisenberg" 
>> > Para: "Tag discussion, strategy and related tools" <
tagging@openstreetmap.org>
>> > Enviados: Martes, 4 de Agosto 2020 16:56:31
>> > Asunto: Re: [Tagging] Rio de la Plata edit war
>>
>> > The graphics in this document are mainly models of current flow,
rather than
>> > actual measurements, but it is mentioned that the average current flow,
>> > neglecting wind, is only 0.1 m/s in the Rio de la Plata. Since winds
of 5 m/s
>> > are routine according to the paper, the currents vary strongly based
on winds
>> > and tides.
>> > See for example the figura on pages 26 to 37 which show the modeled
variation
>> > with different wind direction. I don't see a modeling of the affect of
tides -
>> > this appears to be the average current over the tidal cycle? But I
admit I have
>> > not visited this area.
>>
>> Sure its a model, but the model is validated by drifting bouys, as you
can check in page 37.
>> i just translated here.
>> "The drift buoy trajectories launched in the summer of 2003 and reported
by Piola et al (2003) showed, in consistency with the modeled solutions,
relatively low average speeds (20-30 cm / s) in the middle part of the
river and higher speeds in the outer sector, mainly towards the Uruguayan
coast, where they exceeded 60 cm / s (Fig. 33)."
>>
>> > My main objection is the inclusion of Bahia Samborombon in the
estuary. The
>> > charts and satellite images show very little influence from river
water in that
>> > area, as well as in the section of coast east of Montevideo.
>>
>> You are misreading the imagery. What generaly available imagery shows in
this area is a change of colour, which is dark brown to the NW, and more
clear to the SE. This is caused for the change of turbidity, located near
the 5m isob

Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Joseph Eisenberg
The graphics in this document are mainly models of current flow, rather
than actual measurements, but it is mentioned that the average current
flow, neglecting wind, is only 0.1 m/s in the Rio de la Plata. Since winds
of 5 m/s are routine according to the paper, the currents vary strongly
based on winds and tides.

See for example the figura on pages 26 to 37 which show the modeled
variation with different wind direction. I don't see a modeling of the
affect of tides - this appears to be the average current over the tidal
cycle? But I admit I have not visited this area.

My main objection is the inclusion of Bahia Samborombon in the estuary. The
charts and satellite images show very little influence from river water in
that area, as well as in the section of coast east of Montevideo.

– Joseph Eisenberg

On Tue, Aug 4, 2020 at 12:42 PM  wrote:

>
>
> - Mensaje original -
> > De: "Kevin Kenny" 
> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> > Enviados: Martes, 4 de Agosto 2020 16:28:55
> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> > On Tue, Aug 4, 2020 at 3:18 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com >
> > wrote:
>
> >> These rules would exclude the lower Rio De La Plata and the lower part
> of the
> >> mouth of the Saint Lawrence river, as well as other wide estuaries
> where winds
> >> and tides have more influence on surface water flow than does the
> discharge of
> >> the river. It would not prevent mapping the Hudson mouth at the
> southern tip of
> >> Manhattan, because the flow is strong all the way to New York Harbor,
> if I
> >> understand correctly.
>
> > The Hudson definitely reverses flow. One of its names among the First
> Peoples
> > translates to 'the river flows both ways.' The division in the flow lies
> less
> > in the fraction of the tidal cycle than the speed of the current. It
> flows
> > 'upstream' for half the time, 'downstream' for half, but the downstream
> current
> > is considerably swifter.
>
> Rio de la Plata would not be excluded, as you can read in the document [8]
> i linked in my first mail, for example, see some graphics of the flow of
> the river in page 25.
> [8] DINAMA. Salinidad
> https://www.dinama.gub.uy/oan/documentos/uploads/2016/12/patrones_circulacion.pdf
>
> Regaards,
> M.
>
>
>
>
> ---
>
> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin
> costo.
>
> Informate si aplicás aquí.
>
> mvdfactura.uy
>
>
> ---
>
>
>
> ___
> 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] Rio de la Plata edit war

2020-08-04 Thread Joseph Eisenberg
On Tue, Aug 4, 2020 at 12:31 PM Kevin Kenny  wrote:

> The Hudson definitely reverses flow. One of its names among the First
> Peoples translates to 'the river flows both ways.'  The division in the
> flow lies less in the fraction of the tidal cycle than the speed of the
> current. It flows 'upstream' for half the time, 'downstream' for half, but
> the downstream current is considerably swifter.
>

As long as the current is significantly faster in the downstream direction,
this qualifies by the standard that "the river current is clearly the
dominating current in the water" - that is, oceanic currents and
wind-driven currents are not the definition characteristic

In contrast, the East River, which is a tidal strait, would need to be
mapped on the marine side of the coastline, since the current flows through
the East River are not related to a fresh-water river current at all.
https://en.wikipedia.org/wiki/East_River

By using the dominant currents as a definition, this allows local mappers
with knowledge of the water to determine the right tagging.

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Joseph Eisenberg
"The locals certainly make a distinction between the waters of the
Sacramento and American rivers and those of San Pablo and San Franscisco
Bays, or those of Puget Sound and the many rivers that empty into it. They
also make a distinction between the bays, or the sound, and the ocean. "

And so do the locals in Uruguay and Argentina: the Rio de la Plata is the
name of the marine estuary, while the rivers which empty into it have their
own names: Rio Uruguay and Rio Paraná, which are each about 1.5 km (a
little under a mile) wide, open up to the Rio de la Plata which starts out
at ~30 to 50 km (20 to 30 miles) wide till after Buenos Aires, then becomes
almost 100 km wide by the time it opens up at Montevideo and Samborombon
Bay. The people who named the rivers and the estuary recognized a
difference.

- Joseph Eisenberg

On Tue, Aug 4, 2020 at 12:23 PM Kevin Kenny  wrote:

> On Tue, Aug 4, 2020 at 2:54 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> It's perfectly possible to make a physical definition of an estuary which
>> allows the line of the natural=coastline to be placed across the lower
>> Hudson, rather than at Troy or Albany, if we look at salinity and currents
>> rather than just tides: and we must, because some parts of the coast in the
>> tropics have nearly 0 tidal variation (including the region around the Rio
>> de la Plata).
>>
>> But the current position of the natural=coastline ways between Argentina
>> and Uruguay is like if all of Lower New York Bay were outside of the
>> natural=coastline, and a line was instead drawn from Long Beach NY to Long
>> Branch NJ.
>>
>> This is quite serious when it comes to the Saint Lawrence river (Fleuve
>> Saint-Laurent), which can extend as far west into the Golf of Saint
>> Lawrence as you want, if we take the current placement of the
>> natural=coastline along the eastern edge of the Rio de la Plata as a guide.
>> I would suggest that the natural=coastline should cross no farther
>> downstream than Quebec City, where the river widens into the huge lower
>> estuary.
>>
>> Similarly, should Puget Sound and San Francisco Bay be mapped as
>> natural=water + water=river? These are also estuaries.
>>
>
> Deferring to local cultural understanding is actually a good start for the
> other examples.
>
> For the Hudson, if you wanted to draw the line from Rockaway Point to
> Sandy Hook (the two lighthouses commonly understood to mark the entrance of
> New York Harbor), from the Battery to Liberty Pier (mile 0 of the Hudson as
> it appears on the nautical charts) or from Spuyten Duyvil to Englewood
> Cliffs (just upstream from the first distributary, the Harlem River), I'd
> have no heartburn.
>
>  The lowest point on the river that would be at all defensible by any
> argument other than culture (and 'eyeball' geometry - on the map it *looks*
> like a river) would probably be between Peekskill and Stony Point. That's
> where you'd start to see mean annual salinity start to fall off sharply.
> (The seasonal variation is substantial.) That's already getting culturally
> and "eyeball geometry" start of dodgy.  Beyond that, I'd have to consult
> historical records for the historical maximum retreat of the salt front,
> but we're already quite some way upriver.
>
> Similarly, there's a local understanding of "Fleuve Saint-Laurent" vs
> "Golfe du Saint-Laurent" - and here I see that the locals have compromised
> by creating objects for 'Estuaire fluvial', 'Estuaire moyen' and 'Estuaire
> maritime'. Even there, the 'Estuaire fluvial' does not extend nearly to the
> tidal limit.
>
> The locals certainly make a distinction between the waters of the
> Sacramento and American rivers and those of San Pablo and San Franscisco
> Bays, or those of Puget Sound and the many rivers that empty into it. They
> also make a distinction between the bays, or the sound, and the ocean.
>
> --
> 73 de ke9tv/2, Kevin
> ___
> 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] Rio de la Plata edit war

2020-08-04 Thread Joseph Eisenberg
Re: " Your argument is that the first dam or waterfall is the only
'objective' way to place it. "

That's not what Christoph has proposed. You can read his suggestions at
https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

It provides a great deal of lee-way for mappers to decide on the exact
placement. For the case of the Hudson it could be anywhere from New York
Harbor up to Albany:

"The upper limit

In case of significant tidal influence at the river mouth the coastline
should be closed no further upstream than the range of the tidal influence.

In case of no or insignificant tidal variation the coastline should not
extend significantly above the sea level with the river (*significantly* not
being precisely defined but i'd say at maximum a meter).
"The lower limit

With no or insignificant tides the coastline should go upstream at least to
a point where the river current is clearly the dominating current in the
water under normal weather conditions (i.e. no storm).

With significant tides the coastline should go upstream at least to a point
where on waterflow is going downstream for a significantly longer part of
the tidal cycle than it goes upstream due to rising tide."


These rules would exclude the lower Rio De La Plata and the lower part of
the mouth of the Saint Lawrence river, as well as other wide estuaries
where winds and tides have more influence on surface water flow than does
the discharge of the river. It would not prevent mapping the Hudson mouth
at the southern tip of Manhattan, because the flow is strong all the way to
New York Harbor, if I understand correctly.


- Joseph Eisenberg

On Tue, Aug 4, 2020 at 11:54 AM Kevin Kenny  wrote:

> On Tue, Aug 4, 2020 at 12:59 PM Christoph Hormann  wrote:
>
>> I am not saying that OSM should only record physical geography.  I am
>> saying that natural=coastline is a physical geography tag and should be
>> defined based on physical geography criteria.  If there is no consensus
>> about this we can end the discussion because if we cannot even agree on
>> basic conceptual separation on that level (i.e. that we separate the
>> mapping of the physical extent of surface water cover on this planet
>> from culturally defined elements of the geography) we can close up shop
>> right away.
>>
>
> Your straw man looks to be quite flammable.
>
> A water polygon remains a water polygon whether its boundary is
> `natural=coastilne`, `waterway=river`, `natural=water` or whatever. Nobody
> is arguing over the physical extent of surface water coverage.
>
> The precise line at which a river becomes a lake or the ocean is and will
> always be indefinite. We are arguing about how broadly or narrowly to draw
> it. Your argument is that the first dam or waterfall is the only
> 'objective' way to place it. That may be true: it's the first bright line.
> Nevertheless, in practice, it gives a much broader definition of the World
> Ocean than seems reasonable - placing the line hundreds of km from the
> commonly understood river mouth in many cases.
>
> I'm arguing that both cultural considerations (generally speaking, people
> do not call tidal inland riverbanks 'the coastline') and practical
> considerations (a much longer coastline further complicates the already
> horrible situation for coastline rendering) both militate in favor of
> putting the coastline as far downstream in the estuarine environment as is
> practicable. Nothing in my argument changes the physical extent of the
> mapped water surface by one centimetre. It's simply saying that for any
> indefinite boundary, there is no single right answer. Deference to the
> local cultural definitions, provided that they don't warp the indefinite
> boundary beyond any reasonable physical interpretation, is most likely
> warranted.
>
> --
> 73 de ke9tv/2, Kevin
> ___
> 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] Rio de la Plata edit war

2020-08-04 Thread Joseph Eisenberg
It's perfectly possible to make a physical definition of an estuary which
allows the line of the natural=coastline to be placed across the lower
Hudson, rather than at Troy or Albany, if we look at salinity and currents
rather than just tides: and we must, because some parts of the coast in the
tropics have nearly 0 tidal variation (including the region around the Rio
de la Plata).

But the current position of the natural=coastline ways between Argentina
and Uruguay is like if all of Lower New York Bay were outside of the
natural=coastline, and a line was instead drawn from Long Beach NY to Long
Branch NJ.

This is quite serious when it comes to the Saint Lawrence river (Fleuve
Saint-Laurent), which can extend as far west into the Golf of Saint
Lawrence as you want, if we take the current placement of the
natural=coastline along the eastern edge of the Rio de la Plata as a guide.
I would suggest that the natural=coastline should cross no farther
downstream than Quebec City, where the river widens into the huge lower
estuary.

Similarly, should Puget Sound and San Francisco Bay be mapped as
natural=water + water=river? These are also estuaries.

-- Joseph Eisenberg

On Tue, Aug 4, 2020 at 9:30 AM Kevin Kenny  wrote:

> On Tue, Aug 4, 2020 at 11:24 AM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> This means that the line tagged with natural=coastline is on the inland
>> side of all marine water, including mangroves, salt marshes, and tidal
>> channels, as far as possible. It makes sense that in estuaries, the route
>> of the ways tagged natural=coastline should also extend up to the limit of
>> marine influence. In some cases this has been taken to mean the limit of
>> the tides, in others it is the limit of mixing of salt and fresh water.
>>
>
> I agree that's what the Wiki says. The Wiki says a lot of things.
>
> In actual practice, in the estuaries of rivers, the 'coastline' is very
> seldom tagged that far upstream.
>
> I return to the example of the Hudson River. The tidal influence extends
> upstream to Lock and Dam Number One - 248 km from the river mouth. The salt
> front varies strongly with the season. There can be fresh water in New York
> Harbor during the spring snowmelt, or salt water at Poughkeepsie (122 km
> upriver) in a dry summer. (It's also defined somewhat arbitrarily as a
> conductivity of 510 microsiemens/metre at the surface - but surface
> salinity is, in most seasons, higher than the salinity at depth because the
> cold, fresh river water underlies the relatively warm, brackish surface
> water.) Needless to say, the biome is very different between Albany (always
> fresh water) and Yonkers (always salt, except for snowmelt events).
> Oceangoing vessels of up to 9 m draft can ply the river as far as Albany.
> (In less xenophobic times, vessels of friendly nations could clear customs
> at Albany.)
>
> For pretty much all the rivers in eastern North America, the tidal
> influence extends to the first dam or waterfall. This usually coincides
> with what would be the head of navigation if it were not for modern
> improvements such as locks. Riverports from Augusta, Maine to Macon,
> Georgia would become 'coastal' cities. That's surely no more the local
> understanding on the Kennebec or the Ocmulgee than it is on the Elbe!
>
> For the Amazon, the situation is even more extreme - the river is tidal
> for a thousand kilometres from what would be conventionally recognized as
> the 'coast'.
>
> It appears that for most of the world, this rule, if actually implemented
> - and it is important to stress that it is NOT the way things are mapped at
> present - would extend the 'coastline' for tens or hundreds of km upstream
> on most of the first-order rivers of the world.
>
> Given the fact that even with today's definition, we frequently go for
> months without a consistent coastline to give to the renderer, do we want
> to add tens of thousands more kilometres of 'natural=coastline'? We'd never
> see a coastline update again! (For this reason, I'm inclined to push the
> 'coastline' as far toward the sea as sensibly possible, to have as little
> 'coastline' as possible to get broken, rather than going for months without
> updates or worse, seeing rendering accidents flood whole continents.)
>
> Moreover, I'm somewhat puzzled at Christoph's insistence that
> 'natural=coastline' have a strict physical definition, and dismiss local
> understanding as merely political and cultural. In almost all other aspects
> of OSM, the understanding of the locals is what governs. That understanding
> is, ipso facto, cultural - but we dismiss it at our peril. Ignoring local
> understanding is a path to irrelevance. (In another OSM domain, I've seen
> this sort of nonsense before; I've actual

Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Joseph Eisenberg
We are not talking about a concept like "the coastline", we are talking
about the tag "natural=coastline", which in OpenStreetMap has been defined
(for over 12 years) as "The mean high water (springs) line between the sea
and land (with the water on the right side of the way) ".

"The natural <https://wiki.openstreetmap.org/wiki/Key:natural>=coastline tag
is used to mark the *mean high water springs
<http://en.wikipedia.org/wiki/mean_high_water_spring>* line"

https://wiki.openstreetmap.org/wiki/Tag:natural=coastline

Mean high water springs is " the highest line the water reaches in normal
circumstances".

The problem is that we did not have a clear definition of where this line
should cross a river or estuary.

However, it is widely agreed that the highest tide line is the feature that
should be mapped on the edge of marine water bodies which have tides,
including bays, fjords, lagoons and so on.

This means that the line tagged with natural=coastline is on the inland
side of all marine water, including mangroves, salt marshes, and tidal
channels, as far as possible. It makes sense that in estuaries, the route
of the ways tagged natural=coastline should also extend up to the limit of
marine influence. In some cases this has been taken to mean the limit of
the tides, in others it is the limit of mixing of salt and fresh water.

We are not mapping the low tide line or political baseline with
natural=coastline: the baseline is often far out to sea. Looking at the
Phillipines and Indonesia, the baseline has very little relation to the
physical geographical tide lines, since it merely connects the outer edges
of islands in the archipelago.

Similarly, in Uruguay and Argentina, the local governments have defined the
baseline as far out to sea as possible, so that they can claim a larger
area of ocean as an exclusive economic zone. This should not influence
tagging in OpenStreetMap, which needs to be based on real, verifiable,
physical characteristics.

– Joseph Eisenberg

On Tue, Aug 4, 2020 at 7:57 AM  wrote:

> - Mensaje original -
> > De: "Christoph Hormann" 
> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> > Enviados: Martes, 4 de Agosto 2020 11:17:32
> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> > On Tuesday 04 August 2020, mural...@montevideo.com.uy wrote:
> >>
> >> I linked several scientific studies that clearly shows and are
> >> verifiable geographic evidence that this is not an oceanic coast, its
> >> a riverbank [...]
> >
> > I am not going to start a discussion here on the semantics of terms
> > like 'ocean', 'riverbank', 'coast' or similar which are inherently
> > culture specific and political.
> >
> > So i repeat my request:
> >
> > could you formulate a generic rule for coastline placement similar to
> > what i formulated in
> >
> >
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
> >
> > that
> >
> > (a) allows for the coastline placement you favor in case of the Rio de
> > la Plata
> > (b) is based on verifiable physical geography criteria that can
> > practically be checked by mappers and
> > (c) that is compatible to most of the current coastline placements at
> > river mouths around the world?
> >
> > If you can do that we can try to have a productive discussion without
> > delving into the swamp of politics and cultural differences and maybe
> > can find a consensus position that everyone can be satisfied with.
> >
>
> It's all about semantics.
>
> How could I answer your question if you are not able to define what you
> mean by natural=coastline?
> We must first agree on what features we call it coastline, and then I can
> explain where I think it should be drawn.
>
> Regards,
> M.
>
>
>
>
> ---
>
> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin
> costo.
>
> Informate si aplicás aquí.
>
> mvdfactura.uy
>
>
> ---
>
>
>
> ___
> 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 - Voting - (Ground: natural=bare_soil)

2020-08-03 Thread Joseph Eisenberg
Everyone, the voting period for natural=bare_ground is still open for 4
more days.

I would recommend voting "no" on the current definition, unfortunately.

As mentioned above, the current definition is far too broad, and could
easily be construed to include areas under construction, areas of bare soil
due to use by people as a pathway or road area, and many sorts of arid and
semi-natural areas, including those that are partially covered by shrubs,
heath, grass or other sparse vegetation, or even areas of farmland that are
currently fallow.

Please see the discussion and objections on
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Ground

I think it is a good idea to have a way to tag bare soil which is not sand
(natural=sand) or mostly stones (natural=shingle/scree) or mud, but we need
a clear, limited definition which does not fit with human-use areas like
roads, dirt parking lots, construction sites, abandoned quarries etc, and
there needs to be more consideration about when the tag should be used
instead of natural=heath and natural=scrub in arid regions where there are
scattered bushes.

For the proposal author, I would suggest mapping some local features in
your area which would fit the proposed definition, and then come back with
photos plus aerial imagery of the areas which ought to be mapped with this
tag. So far it has been mostly hypothetical, which makes it hard to
understand which sorts of landscapes would qualify for this tag.

- Joseph Eisenberg

On Mon, Jul 27, 2020 at 5:58 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 27. Jul 2020, at 13:41, Michael Montani 
> wrote:
> >
> > I eventually found on-the-ground images of the feature I would like to
> propose / map.
>
>
> are these suggested to be represented as polygons? How would the border be
> determined? I looks from the imagery as if there is a smooth transition of
> these „features“ and neighbouring land which isn’t completely bare. Did you
> try to map some of these and if yes, could you please post a link to an
> area where a few are mapped?
>
> 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


  1   2   3   4   5   6   7   8   9   10   >