Re: [Tagging] Feature Proposal - RFC - Hazards

[Mateusz Konieczny via Tagging]

It is not explicitly mentioned, but it would be a good idea to have explicit 
mention
is it OK to tag hazard that

- exists
- is unsigned
- government has not declared that it exists (maybe government is 
dysfunctional/missing like
in Somalia, or it is covering-up the problem, or it has higher priorities - for 
example during war)

Currently it is implied that it is not taggable, it would be good to have it 
mentioned explicitly.

Why hazard:animal and hazard:species is needed instead of animal and species? 

--

The use of hazard =rock_slide 

 is more popular than several alternatives, 
which are essentially describing the same thing: a hazard where rocks, earth, 
or mud might fall from above.

There is a big difference between rock slide, failing rocks and landslide.

I do not thing that deprecation of failing_rocks and landslide is a good idea,
I would keep them (I have seen signposted sign about landslide exactly once,
many, many signs of failing rocks - tagging rock_slide for either of them would 
be incorrect).

Nov 25, 2020, 14:12 by zelonew...@gmail.com:

> Comment is requested on the proposal "hazard", which describes hazardous or 
> dangerous features.  This tagging was first proposed in 2007, and I have 
> adopted the proposal with permission from the original author.  Thanks to the 
> various folks that assisted in the development of this proposal prior to this 
> RFC.
>
> The key "hazard" has achieved over 28,000 usages, and it is proposed to 
> formalize usage of the most popular values of this key while deprecating 
> less-popular synonyms.  In addition, this proposes to deprecate 
> protect_class=16 in favor of the hazard key.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>

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

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[stevea]

I'm in California, where it's almost cliché we love our cars and car culture, 
but it is true that not only here but in many USA states, we have "drive-thru" 
COVID-19 testing centers.  I would guess that vaccination centers that are also 
"drive-thru" are likely soon (early 2021?), too.  These being mapped with 
"indefinite duration" seems a bit much (sorry, Brian), but they are usually 
more of a "pop-up" kind of thing:  one-time or "only on Saturdays" or something 
like that.  OSM could use the opening_hours syntax to describe the "when" of 
these being available.  But let's be clear on whether they are "testing" or 
"vaccination" (I have seen the former, but not yet the latter, unless for the 
usually-winter flu, not COVID-19).

Whether these belong in the healthcare=* key, I don't know.  The testing or 
vaccination aspect both are certainly a form of healthcare.  However, while 
COVID-19 is new, and there is now testing, but not vaccination (I expect there 
will be), regular-old "flu vaccines" (not testing for it, but a vaccine 
injection) are and have been widely available for years.  These are often at 
"drugstores" (in the USA, these are a sort of large variety store that has a 
full pharmacy in the back), and once becoming established at being a place 
where one can get your usually-in-autumn-or-winter flu vaccination, often 
perform this service year after year.  Some even advertise that they are free:  
it may be that an insurance certificate / card must be provided, rarely, though 
sometimes, even this is not required, especially for elderly / senior citizens. 
 I hope this helps.

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

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[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] RFC: vaccination / COVID-19 vaccination centres

[Brian M. Sperlongano]

Unless somebody has a crystal ball, it's at least plausible that these
could be around for quite some time.  If we're lucky and they go away
quickly, it's easy enough to remove the tagging later.  But, "indefinite
duration" seems like a sufficient level of permanence for an OSM feature.

On Wed, Nov 25, 2020 at 5:20 PM Peter Elderson  wrote:

> We (Nederland) will likely use the flu vac system of local practitioners
> and old people's homes to do groups at risk first, and health care
> personnel will take care of themselves while administering.Will take two to
> three weeks for the first shot, and if a second shot is needed, 6 weeks.
>
> The rest will probably need to apply, and I think the Covid testing
> facilities will be used for the mass vax. This will probably take months,
> mainly because of supply chain and cold chain problems. Everybody will
> turn into an opportunist, politicians will literally lose their voices
> because of all the yelling at each other. Then it will become a standard
> yearly vaccination and we will all return to normal. O, the stories we will
> tell our grandchildren when they really just want to hang out with each
> other and play games...
>
> Best, Peter Elderson
>
>
> Op wo 25 nov. 2020 om 22:33 schreef Paul Allen :
>
>> On Wed, 25 Nov 2020 at 20:01, Philip Barnes  wrote:
>>
>> Although in this case I would expect the approach to be to set up
>>> sessions for schools, universities and at larger employers and for the
>>> general population it will simply attend an appointment at their local
>>> medical centre.
>>>
>>
>> Even back in the Before Times, flu jabs were not given at the local
>> medical
>> centre but in a large exercise hall.  I think that was more to do with
>> numbers
>> than anything else.  Covid is more infectious than flu (but less so than
>> measles)
>> and the indications are strong that you're at a lot greater risk indoors
>> than
>> outdoors.
>>
>> I doubt that testing or vaccination will take place at local medical
>> centres.  All
>> the testing centres I know of, whether short-term or longer-term have the
>> testing conducted outdoors.
>>
>> Right now, because of a recent surge in cases in my town the medical
>> centre is only permitting people to turn up if they get an appointment
>> because it is "absolutely necessary" (their words, not mine) they see
>> a doctor.
>>
>> I've been paying a lot of attention to this stuff (because of underlying
>> health conditions which mean I'm very unlikely to survive it) and I
>> seriously doubt we'll see testing or vaccination conducted indoors
>> until all medical staff have been vaccinated and enough of the
>> general population have been vaccinated to achieve herd
>> immunity.
>>
>> --
>> 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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Graeme Fitzpatrick]

On Wed, 25 Nov 2020 at 23:27, Brian M. Sperlongano 
wrote:

> Comment is requested on the proposal "hazard", which describes hazardous
> or dangerous features.  This tagging was first proposed in 2007, and I have
> adopted the proposal with permission from the original author.  Thanks to
> the various folks that assisted in the development of this proposal prior
> to this RFC.
>

Good work, Brian!

Couple of comments added to the talk page

Thanks

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

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[Peter Elderson]

We (Nederland) will likely use the flu vac system of local practitioners
and old people's homes to do groups at risk first, and health care
personnel will take care of themselves while administering.Will take two to
three weeks for the first shot, and if a second shot is needed, 6 weeks.

The rest will probably need to apply, and I think the Covid testing
facilities will be used for the mass vax. This will probably take months,
mainly because of supply chain and cold chain problems. Everybody will
turn into an opportunist, politicians will literally lose their voices
because of all the yelling at each other. Then it will become a standard
yearly vaccination and we will all return to normal. O, the stories we will
tell our grandchildren when they really just want to hang out with each
other and play games...

Best, Peter Elderson


Op wo 25 nov. 2020 om 22:33 schreef Paul Allen :

> On Wed, 25 Nov 2020 at 20:01, Philip Barnes  wrote:
>
> Although in this case I would expect the approach to be to set up sessions
>> for schools, universities and at larger employers and for the general
>> population it will simply attend an appointment at their local medical
>> centre.
>>
>
> Even back in the Before Times, flu jabs were not given at the local medical
> centre but in a large exercise hall.  I think that was more to do with
> numbers
> than anything else.  Covid is more infectious than flu (but less so than
> measles)
> and the indications are strong that you're at a lot greater risk indoors
> than
> outdoors.
>
> I doubt that testing or vaccination will take place at local medical
> centres.  All
> the testing centres I know of, whether short-term or longer-term have the
> testing conducted outdoors.
>
> Right now, because of a recent surge in cases in my town the medical
> centre is only permitting people to turn up if they get an appointment
> because it is "absolutely necessary" (their words, not mine) they see
> a doctor.
>
> I've been paying a lot of attention to this stuff (because of underlying
> health conditions which mean I'm very unlikely to survive it) and I
> seriously doubt we'll see testing or vaccination conducted indoors
> until all medical staff have been vaccinated and enough of the
> general population have been vaccinated to achieve herd
> immunity.
>
> --
> 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] RFC: vaccination / COVID-19 vaccination centres

[Paul Allen]

On Wed, 25 Nov 2020 at 20:01, Philip Barnes  wrote:

Although in this case I would expect the approach to be to set up sessions
> for schools, universities and at larger employers and for the general
> population it will simply attend an appointment at their local medical
> centre.
>

Even back in the Before Times, flu jabs were not given at the local medical
centre but in a large exercise hall.  I think that was more to do with
numbers
than anything else.  Covid is more infectious than flu (but less so than
measles)
and the indications are strong that you're at a lot greater risk indoors
than
outdoors.

I doubt that testing or vaccination will take place at local medical
centres.  All
the testing centres I know of, whether short-term or longer-term have the
testing conducted outdoors.

Right now, because of a recent surge in cases in my town the medical
centre is only permitting people to turn up if they get an appointment
because it is "absolutely necessary" (their words, not mine) they see
a doctor.

I've been paying a lot of attention to this stuff (because of underlying
health conditions which mean I'm very unlikely to survive it) and I
seriously doubt we'll see testing or vaccination conducted indoors
until all medical staff have been vaccinated and enough of the
general population have been vaccinated to achieve herd
immunity.

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

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[Philip Barnes]

On Wed, 2020-11-25 at 13:28 +, Paul Allen wrote:
> On Wed, 25 Nov 2020 at 13:15, Phake Nick  wrote:
> > I don't thibk it is appropriate to add one-off temporary facilities
> > into OSM.
> 
> How temporary is temporary?  All of man's works eventually crumble
> and
> decay.  No man-made feature is permanent.  On a long enough
> timescale,
> no geological feature is permanent either.
> 
> We shouldn't map a one-off.  But such facilities are likely to
> operate for months,
> if not years.  Testing and vaccination facilities are generally not
> located in
> places like hospitals and doctors to minimize infection.  Often open-
> air
> for the same reason, which means they are going to be building=roof
> or building=marquee.  Most won't be constructed to last decades but
> will be there for many months.
> 
Although in this case I would expect the approach to be to set up
sessions for schools, universities and at larger employers and for the
general population it will simply attend an appointment at their local
medical centre.

Phil (trigpoint)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[Niels Elgaard Larsen]

På Wed, 25 Nov 2020 13:34:24 +
Andy Townsend  skrev:

>As an aside, it's probably worth explaining why people sometimes say 
>that OSM isn't a place for one-off temporary things 

I mostly use OsmAnd. I update it every month, but that is of course
mostly because i want to my own edits.

I have added a lot of POI's. Mostly restaurants, cafes, bars etc.
Some are pop-up restaurants, beach bars that might not be there next
year, etc. Usually I add them because it is useful for users if they
have for example agreed to meet in a specific bar. If there are lots of
other options around there is little risk of annoying users.

If it is in the middle of nowhere, we should be more careful.

Currently everything in Denmark have to close at 22:00, but I leave
opening hours for bars and nightclubs that are open late and even add
later hours based on the establishments websites, because:
  1. offline use.
  2. I could not promise to revert them all back to normal then
  covid19 is over and I doubt that other mappers would.
  3. It could change any day to 20:00, 23:00 or something else.
  4. It would add no real information anyway because *everything* has
  to close at 22 and everyone here knows it.

Many places are closed because of covid19. I do not delete them but add
access:covid19=no

>(for example, a 
>music festival that usually happens over a couple of days, once a 
>year).

I see nothing wrong in mapping recurring events if they are tagged with
something like opening_hours=Jul Sa[2],Su[2]
or even:
 opening_hours="a weekend in august",website="https://xxx.example.org";

No one will be traveling to a music festival unless they know that it
is on. But if you are going there, it is useful to have in OSM.

>  The reasoning goes that although some people look at OSM data 
>"live", many do not.  Many (perhaps most) 3rd-party consumers of OSM 
>update only rarely, and by definition all offline apps show data as it 
>was at some point in the past. If the data that they grab happens to 
>coincide with a temporary event in OSM their users will be very
>confused.

Only if it is not tagged as a temporary event or with specific dates.

>There comes a point, of course, when a "temporary " thing is worth 
>mapping.  I've mapped https://www.openstreetmap.org/way/601820045 as 
>closed because it's been that way for a couple of years and (despite
>the council signage) is pretty unlikely to be sorted out in the next
>few weeks.

For me the most difficult to handle is roads.
I was just driving on motorways that had roadworks lasting to next
summer, changing max speed from 130 to 80. But other times I discover
low max speed from road work that was finished a long time ago.

I would like a good way to tell routers that for the next couple of
months to expect going at half speed on a stretch of road.

>At what stage something changes from a "one-off temporary" thing to 
>something definitely worth mapping is a question worth discussing,
>though.

I think that covid19 vaccinations centers are important enough.

We also have a lot of Olympic villages in OSM.

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

Re: [Tagging] coastline v. water

[Andy Townsend]

Hi,

Recently, Chesapeake Bay (the largest estuary in the United States with a surface area of over 
10,000 sqkm) has been changed from "natural=coastline" tagging to form a large 
"natural=water;water=lagoon" multipolygon instead. The area has also been split into the 
bay itself, the Pocomore Sound, the Tangier Sound, and other smaller bodies.

Current coastline:https://overpass-turbo.eu/s/10xZ  (zoom in or out and 
re-query as desired).

Previous coastline as of 2020-06-01:https://overpass-turbo.eu/s/10y1  (again, 
zoom in or out and rerun the query).

As a consequence, the world-wide coastline processing is stuck. Discussions 
have happened here on this list, as well as on talk-us and on the changeset 
itself:https://www.openstreetmap.org/changeset/94093155

Among the reasons for this change, the following have been mentioned:

* polygon allows better labelling
* polygon allows better geocoding for points on bay water surface
* bay is not really "sea" hence coastline is incorrect
* natural=water tagging allows for quicker turnaround times to see your edits 
on the map
* local mappers should decide how they want stuff tagged

Opponents of the change have said, among other things:

* natural=coastline does not mean "literal" coastline
* a major change like this should be discussed thoroughly before executing
* large polygon hampers editing+QA
* boundaries between water polygons, or between water polygons and sea, are 
arbitrary and not verifiable

The possible solutions to this issue are:

* accept current situation as correct and resume world-wide coastline processing based on 
this as a new "known good" state
* revert the change wholesale and request prior discussion and consensus in the 
community
* any mixture of the above

Following internal discussion within the DWG, we propose the following:

* the polygons that have been created will not be removed

* the land-side members of the polygons for Chesapeake Bay, Tangier Sound, 
Pocomore Sound and potentially others that have been created as part of this  
operation will be given back their natural=coastline tags

In addition, currentlyhttps://www.openstreetmap.org/relation/11884052  is mapped as 
"natural=water; water=lagoon" which does not match the wiki definition 
athttps://wiki.openstreetmap.org/wiki/Tag:water=lagoon  .  
Perhapshttps://wiki.openstreetmap.org/wiki/Tag:natural%3Dbay  would be a better tag?  This is of 
course an entirely separate discussion to where the OSM concept "natural=coastline" 
should go - we don't propose to change the tagging on relation
11884052 now but it probably does need looking at.

This is not intended as a definitive solution for all times, just as a stop-gap 
measure until a consensus is found and, once it has, tools have been amended 
where necessary. Future community discussion may still lead to the removal of 
the coastline tagging, or to the removal of the polygons and their replacement 
by a label point.  For now we're just trying to get to a place where other 
people around the world can make valid coastline edits and see their changes go 
live.  The current impasse over Chesapeake Bay is currently stopping that.

Are the local mappers willing to help implement this? If not, the DWG will do it so that 
normal coastline processing elsewhere can resume.  We apologise in advance to anyone who 
thinks that this is an incorrect decision, but unfortunately sometimes a decision between 
one of two outcomes (neither of which is universally popular) has to be made.  In such 
cases the DWG often reverts to the "status quo ante", and we think that makes 
sense here too.

Best Regards,

Andy Townsend, on behalf of the Data Working Group

On 18/11/2020 20:19, Eric H. Christensen via Tagging 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 s

Re: [Tagging] coastline v. water

[Ture Pålsson via Tagging]

By the way, an... amusing test case for all things related to water and 
label placement is Lake Mälaren, the lake that Stockholm is separating 
from the sea, and all its (named!) nooks and crannies: 
https://www.openstreetmap.org/relation/1433877 . I've had at least 3 
different bits of it poking into different corners of the map at times.


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

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[Andy Townsend]

On 25/11/2020 12:54, Phake Nick wrote:
I don't think it is appropriate to add one-off temporary facilities 
into OSM.


As soon as you do the sums it seems pretty unlikely that these will be 
"one-off temporary facilities".


Governments and health authorities may be able to move to a more 
"business as usual" vaccination approach (e.g. alongside things like TB 
or seasonal flu) in the fullness of time, but that's going to be at the 
absolute earliest the back end of next year.


As an aside, it's probably worth explaining why people sometimes say 
that OSM isn't a place for one-off temporary things (for example, a 
music festival that usually happens over a couple of days, once a 
year).  The reasoning goes that although some people look at OSM data 
"live", many do not.  Many (perhaps most) 3rd-party consumers of OSM 
update only rarely, and by definition all offline apps show data as it 
was at some point in the past. If the data that they grab happens to 
coincide with a temporary event in OSM their users will be very confused.


There comes a point, of course, when a "temporary " thing is worth 
mapping.  I've mapped https://www.openstreetmap.org/way/601820045 as 
closed because it's been that way for a couple of years and (despite the 
council signage) is pretty unlikely to be sorted out in the next few weeks.


At what stage something changes from a "one-off temporary" thing to 
something definitely worth mapping is a question worth discussing, though.


Best Regards,

Andy


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

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[Martin Koppenhoefer]

sent from a phone

> On 25. Nov 2020, at 14:15, Phake Nick  wrote:
> 
> I don't thibk it is appropriate to add one-off temporary facilities into OSM.


everything is temporary, e.g. buildings, trees, even mountains, although the 
latter on a geological time scale. Not to speak of businesses. Things come an 
go, the question is where you draw the line. IMHO if something is not 
exceptionally important (read: to many people), a few weeks or months seem a 
reasonable period (read: you suppose that they last at least this long, 
naturally nobody can foresee the future). Frederik mentioned in a local forum 
that the DWG sees 6 months as a reasonable timespan for borders in areas with 
ongoing conflicts. 
IMHO, COVID19 related features are falling into the exceptional clause and 
could be mapped even if you expected them to last only 3 weeks (which is not 
the case in many areas).

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

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[Paul Allen]

On Wed, 25 Nov 2020 at 13:15, Phake Nick  wrote:

> I don't thibk it is appropriate to add one-off temporary facilities into
> OSM.
>

How temporary is temporary?  All of man's works eventually crumble and
decay.  No man-made feature is permanent.  On a long enough timescale,
no geological feature is permanent either.

We shouldn't map a one-off.  But such facilities are likely to operate for
months,
if not years.  Testing and vaccination facilities are generally not located
in
places like hospitals and doctors to minimize infection.  Often open-air
for the same reason, which means they are going to be building=roof
or building=marquee.  Most won't be constructed to last decades but
will be there for many months.

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

Re: [Tagging] coastline v. water

[Paul Allen]

On Wed, 25 Nov 2020 at 08:45, Ture Pålsson via Tagging <
tagging@openstreetmap.org> wrote:

>
> (And I agree with Kevin about reconstructing an area from a point +
> surrounding coastline. I'd like to see at least an outline of an
> algorithm for that! Having said that, I also recognise that
> gazillion-point polygons to outline Skagerrak, Kattegatt, the North Sea
> and what-have-you may not be the prettiest state of things either...)
>

I'm not convinced that point + coastline will give a reasonable result
enough of the time.  But I could be wrong about that.

Polygons that are contiguous with the coastline are a pain to add, even with
generalized coastline (and even worse if Slartibartfast has added crinkly
bits to
the coastline).  It's a lot of work.  If the polygon is crude and not
contiguous
with the coastline that can give bogus results when trying to determine
if a given co-ordinate is in a named bay or not.

However, it is often the case that the ends of bays are known (local
knowledge that village X is in Y bay) or are obvious from inspection.
Since at least one person is confident that a single point is enough
to create a workable algorithm, two points should be twice as good!
Yeah, I was joking, but a lot less code and a lot less algorithmic
guesswork would be involved in marking two points on a coastline
that define the extent of the bay.  An algorithm can generate a bounding
polygon from those two points, the coastline between them, and a straight
line connecting them.  The hardest part would be ensuring that the
algorithm takes the shortest segment of coastline between the two
points and not the longest segment.

Better than two points would be a way joining those two points.
In the absence of further knowledge, map a simple straight line.
A straight line is an approximation because currents and water
depths might mean hydrographers and/or mariners regard the
seaward extent of the bay to be wibbly-wobbly (one of the
examples posted on the list showed a convex seaward extent
of a bay).  So use a way rather than two points to allow for
curvy seaward extents, where known.

Using a way rather than a polygon avoids the problems of
nested bays.  There are many small bays within Cardigan
Bay (mapped by somebody as a polygon):
https://www.openstreetmap.org/way/651881240
It would also deal with the potential problem of
overlapping bays (imperfect nesting), should that
ever be necessary, without mappers having to
jump through hoops constructed of multipolygons.

As far as I can see we can use a point, placed by visual inspection,
and add a tag for importance which determines (in cartos that
make use of it) the size of the label and at what zooms the
label appears.  Or we use a way to determine closure of the bay
and let an algorithm handle placement and importance of the
label.  An algorithm would give greater consistency than mappers
using their best guess at how important the label should be.

Yes, the way could be abused by people wanting to control
placement of the label.  As could the point.  As could any other
way of mapping bays that we come up with.  I don't think
we should reject solutions because somebody could abuse
them, otherwise we wouldn't have any tags at all.

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

[Tagging] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

Comment is requested on the proposal "hazard", which describes hazardous or
dangerous features.  This tagging was first proposed in 2007, and I have
adopted the proposal with permission from the original author.  Thanks to
the various folks that assisted in the development of this proposal prior
to this RFC.

The key "hazard" has achieved over 28,000 usages, and it is proposed to
formalize usage of the most popular values of this key while deprecating
less-popular synonyms.  In addition, this proposes to deprecate
protect_class=16 in favor of the hazard key.

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

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[Phake Nick]

I don't thibk it is appropriate to add one-off temporary facilities into
OSM.

在 2020年11月25日週三 01:30，Tom Pfeifer  寫道：

> 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

[Tagging] Feature Proposal - Vote aborted - Pumping proposal

[François Lacombe]

Dear all,

Voting on the pumping proposal has been aborted following several comments
that should be studied for a second version.
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

For now, 11 opposition against 10 approval votes shows that no consensus
could be achieved shortly and improvements have to be made.

A special thank to 21 voters who spent time to give their feedback.

Established tagging qualifications have to be widely discussed at a global
level. Such a question often arises without any agreement on both sides,
every time. It would be more usable to have to-be-defined thresholds above
which a tagging can't be changed, if a significant part of the community
agrees it's desirable.


All the best

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

Re: [Tagging] Elevated housing estate

[Yves via Tagging]

I guess the level won't be completely sealed and may serve for something once 
the building is inhabited.
Wait and them!
Yves 

Le 25 novembre 2020 02:26:22 GMT+01:00, Graeme Fitzpatrick 
 a écrit :
>On Wed, 25 Nov 2020 at 11:20, Joseph Eisenberg 
>wrote:
>
>> Is the whole ground level a parking lot or parking structure, perhaps?
>>
>
>No.
>
>It's built right beside a Creek, on a flood-plain (yeah, thanks Council!),
>so it's done like that so that the apartments are up away from the water
>the next time the Creek floods!
>
>Thanks
>
>Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Elevated housing estate

[Alan Mackie]

This probably isn't too far off from many of the larger man_made=pier
structures in resort towns, although it lacks the water underneath most of
the time. Would man_made=bridge be appropriate for the surrounding area?

I think this is becomming fairly common in some flood prone areas, so
dedicated tagging seems like a good idea, both for the usually dry
situation, and for buildings that sit over water but don't even have
vestigial mooring areas.

The wiki lists building=stilt_house, but this seems overly specific.
Whether a building is tagged as being on stilts should be independent of
building use IMO. Regardless in this case min_level=1 seems about right to
me to denote the absence of a ground floor.

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpier
https://wiki.openstreetmap.org/wiki/Tag:building%3Dstilt_house

-Alan

On Wed, 25 Nov 2020 at 06:34, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> add location=overhead on buildings and other objects?
> https://wiki.openstreetmap.org/wiki/Key:location
>
> https://wiki.openstreetmap.org/wiki/Key:building:min_level
>
> https://wiki.openstreetmap.org/wiki/Key:building:levels#Buildings_with_parts_that_don.27t_start_at_ground_level
> (not sure can it be applied if entire building starts above ground level)
>
> Certainly add also description=* tag with info what is happening here,
> maybe with link to this mailing list thread.
>
>
> Nov 25, 2020, 01:00 by graemefi...@gmail.com:
>
> 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] Elevated housing estate

[Martin Koppenhoefer]

sent from a phone

> On 25. Nov 2020, at 02:28, Graeme Fitzpatrick  wrote:
> 
> It's built right beside a Creek, on a flood-plain (yeah, thanks Council!), so 
> it's done like that so that the apartments are up away from the water the 
> next time the Creek floods!


AFAIK we do not have a specific tag for this kind of configuration. There’s the 
generic building:min_level to map omitted levels below the building.


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

Re: [Tagging] coastline v. water

[Ture Pålsson via Tagging]

I mentioned the problem of mapping "fuzzy" areas to a friend, who 
replied along the lines of "why, of course such areas should be mapped 
as functions, taking a point as input and returning a real between 0 
(definitely outside) and 1 (definitely inside)!".


I'd rather not have to implement that, though. =)

(And I agree with Kevin about reconstructing an area from a point + 
surrounding coastline. I'd like to see at least an outline of an 
algorithm for that! Having said that, I also recognise that 
gazillion-point polygons to outline Skagerrak, Kattegatt, the North Sea 
and what-have-you may not be the prettiest state of things either...)


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