Re: [Tagging] Quarry lakes

[Paul Allen]

On Thu, 24 Dec 2020 at 17:24, Brian M. Sperlongano 
wrote:

>
> Should quarry lakes be tagged under a separate value from water=lake?
>

If they should, then you have to consider that some of them may be ponds.

If there is consensus that quarry lakes should be excluded from water=lake,
> obviously that impacts how water=lake is defined.
>

It can be hard to know if a pond/lake is the result of quarrying or not.  it
depends upon knowing the history of an area.  For the distant past such
information may not be available.  So subtagging with lake=quarry
and pond=quarry may be the way to go - it can be added if known
or if such information arises later.  The Norfolk Broads were long
regarded as natural, until it was proven in the 1960s that they
were excavated in the Middle Ages and later flooded by rising
sea levels.

The question arises as to whether or not peat workings qualify as
quarries.  The Norfolk Broads were peat workings that later
flooded.  https://en.wikipedia.org/wiki/The_Broads

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

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

[Paul Allen]

On Thu, 24 Dec 2020 at 05:40, Andrew Harvey 
wrote:

> I'm giving away all my favourite spots here but both of these the stream
> is mapped a a way, and has the pool under the waterfall mapped as an area,
> so you can determine pools under a waterfall based on the natural=water
> area with one of the nodes being a waterway=waterfall node.
>
> https://www.openstreetmap.org/way/531128566
> https://www.openstreetmap.org/way/32173325
>
> If we want a separate tag for this that's fine, but currently people use
> the water=stream_pool in OSM to tag these.
>

Until water=stream_pool came along, these would have been mapped
as water=pond, or even left as natural=water without defining the
type of water.  I expect many still are mapped that way, even
today.

Do we need to differentiate between stream pools and plunge pools
given that so many of both are already mapped as ponds?  I can
see arguments both ways and don't (yet) have strong feelings
either way.

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

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

[Paul Allen]

On Wed, 23 Dec 2020 at 18:04, Brian M. Sperlongano 
wrote:

>
> It seems like the convention for rivers is that the river's continuity
> (and name) are carried with the waterway=river ways and not the area
> polygons that cover the width of the river (regardless of whether you use
> the water=river or waterway=riverbank scheme).
>

So it appears to me.

  I also note that the distinction (effectively) between stream/river (the
> only variants that are in serious use) is that a stream is small enough
> that it's modeled by a way, while a river is large enough to require
> drawing a polygon.
>

Erm, nope.  The distinction is whether or not you can jump across it.
However,
wider rivers may benefit from a polygon.  But if you're in a hurry, or can't
be bothered, don't use a polygon.  Whenever I have masochistic urges
I extend the polygon on Afon Teifi further upstream.  This is as far as I've
gone from the estuary, and you can see that the rendering without the
polygon doesn't do it justice:
https://www.openstreetmap.org/?mlat=52.05829=-4.58272#map=17/52.05829/-4.58272
Follow the river a little way east from that point and you'll see a stream
join
the unpolygonned river.  Follow the river a little way north from that point
and you'll see the stream Nant Eifed join the polygonned river.


> I will make an assumption that there exists a class of these pools that
> are large enough that we would want to be able to map them as an area (and
> we wouldn't call them a pond),
>

Not so much wouldn't call them a pond as shouldn't call them a pond (unless
we declare pools to be honorary ponds for OSM purposes).

and there are also some that are small enough that mapping them as a node
> or linear way is fine also.
>

A node, maybe.  I'm not sure a linear way makes sense.


> 5. Be the same tagging for both rivers and streams
>

That could be hard.  It doesn't make sense to put a polygon on a
stream, they're not wide enough.

>
> I think it's fine if a river does not have continuity of water=river or
> waterway=riverbank polygons, as long as the waterway=river is properly
> contiguous.  I.e. I think it would be fine to have a sequence of river
> polygons with a stream pool polygon in between.
>

It would be rare (but not impossible) for the whole width of a river to be a
pool.  Mostly it's one side of the river where the flow rate slows.  But
since the
polygons overlay the water=river it should all work.  Maybe a carto problem
with name overlaps/priority, but that's probably soluble.

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

Re: [Tagging] Cartpath RFC

[Paul Allen]

On Wed, 23 Dec 2020 at 08:40, Peter Elderson  wrote:

> It's not about an example, it's about using a general term for a specific
> type.
>

When I saw "cartpath" in the subject, my first thought was NOT golf carts.
My first thought was of a two-wheeled vehicle pulled by one or two
horses.  Around here there are competitions for those types of cart,
run on dedicated gallops.  For all I know, somewhere there are paths
dedicated to them.

"cartpath" is too general.  And should be hyphenated or underscored,
anyway.

And maybe it would be better handled as an access value.

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

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

[Paul Allen]

On Mon, 21 Dec 2020 at 21:50, Kevin Kenny  wrote:

I don't think I've had the situation come up, but if it did, I'd probably
> map the riverbank only once, and split the river at the fall and at the
> outlet of the pool. Do the ordinary waterway=riverbank or water=river
> mapping for the river as a whole, and create a multipolygon (probably
> tagged natural=water water=pond) to represent the pool.
>
> I've seen only one plunge pool.  And that was dammed to turn it into a
mill pond.
But I've seen many stream pools that I've yet to map properly.  They're
usually named, because they are of significance to anglers or boat
builders.  It's easier to do it your way, unless you want to name the pool.

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

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

[Paul Allen]

On Mon, 21 Dec 2020 at 18:51, Brian M. Sperlongano 
wrote:

>
>
>> I think you need to expand a little on how to "conflate" a pool with a
>> river.  The
>> disadvantage of doing so is that the pool then cannot have a name
>> assigned.
>>
>
> Sorry, my words were not clear enough here.  By "conflate" I mean that the
> pool would simply be part of the river polygon.  See this example near
> Boston:
> https://www.openstreetmap.org/way/91082432#map=16/42.2615/-71.2764
>

I knew what you meant by "conflate."  Others may not.

>
> Note that I explicitly included the phrase "if they are named or
> significant in size" to cover the case where a stream pool has a name.  My
> intent is to craft the definition in such a way that it allows either
> scheme without preference (i.e. part of the river polygon, or a separate
> pond/lake polygon with a name).
>

It feels more natural to map a side pool of a wide river which has a river
polygon
by expanding the polygon.  But such a pool cannot be named.  It feels
unnatural to tack a pond onto the side of a river polygon.  But I suppose
it will work.

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

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

[Paul Allen]

On Mon, 21 Dec 2020 at 18:13, Brian M. Sperlongano 
wrote:

>
> "Occasionally a river or stream will form a stream pool or plunge pool,
> which are bodies of water that naturally occur along the course of the
> waterway. These waterbodies may either be tagged as a lake or (usually)
> pond if they are named or significant in size, or else they can be simply
> conflated with the river."
>

I think you need to expand a little on how to "conflate" a pool with a
river.  The
disadvantage of doing so is that the pool then cannot have a name assigned.

Also, there are tidal pools (which may be outside the scope of the
proposal).

Is this distinction satisfactory?  How are folks tagging these features?
>

I've been tagging them as ponds, for lack of anything better.  Well,
until a few days ago I didn't realize the distinction between ponds
and pools so I was tagging them as ponds because I didn't know
they weren't ponds but pools.  If I'd had to map bigger ones
I'd have tagged them as lakes.

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

Re: [Tagging] Fuzzy areas again: should we have them or not?

[Paul Allen]

On Mon, 21 Dec 2020 at 15:47, Brian M. Sperlongano 
wrote:

The current data model works just fine for fuzzy areas: it requires a
> polygon combined with tagging that indicates that the area is "fuzzy".
> Since the current data model allows both polygons and tags, fuzzy areas
> could be mapped just fine from a technical standpoint.
>

I assume that there is a technical limitation on the number of nodes in
such a
polygon.  A limitation that may apply to any or all of editors, database
tables
and renderers.  There may be some technical workarounds, there may not be.


> "Whether we want fuzzy areas"
>

To an extent, everything we map is fuzzy, in that there is always
imprecision.
Aerial imagery may be offset.  Roads may pass through woods giving little or
no visual indication.  GPS traces have errors and require many traces to
achieve good precision.  Everything we map is fuzzy in the sense that it
is imprecise but we live with that and understand that the map is an
approximation that we may be able to improve upon at a subsequent date.

The dislike of fuzziness here appears to centre around verifiability.
We don't want edit wars over the extent of a boundary for which
no definitive answer can ever be given.  We want rigidly defined
areas of doubt and uncertainty.  I'm not sure that a fuzzy tag
will resolve that problem.  The precise boundary of a wetland
doesn't matter too much and a few tens of metres either way
isn't a problem; when it comes to "The Alps" that is a different
matter.  Simply tagging an area as fuzzy doesn't mean another
mapper won't disagree with your polygon and edit it.


> The statement that fuzzy polygons is "damaging" is an argument not based
> in fact.  It is not damaging to me to have building outlines, which I do
> not care about.  I can simply ignore them.  Likewise, fuzzy areas cause no
> damage to people that do not care about fuzzy areas, provided that there is
> tagging that distinguishes them from non-fuzzy areas.
>

The problem is the edit wars that may arise.  Not a technical issue but a
behavioural one.


> Further, since we have free tagging, there is nothing preventing mappers
> (especially ones not party to these conversations) from adding additional
> fuzzy areas to the database, mapped with some invented scheme, and
> potentially even creating data consumers to consume such invented tagging.
> Many tagging schemes in OSM have arisen in this manner.
>

And there is the deeper problem.  People will do it anyway.  And possibly
have
their additions reverted by the DWG.  Repeatedly.  In the short term, that
may
work.  In the longer term, "any tag you want" may win.  You can't turn back
the tide but, with barriers you can divert it.

If we don't have fuzzy areas, people will abuse place=locality and other
tags to get labels rendered.  If we do have fuzzy areas then renderers
can calculate label placement, label size, and which zoom levels the
label appears at.  Fuzzy areas also mean we have meaningful tagging
rather than abused tagging, which makes searching for such areas
simpler.

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

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Paul Allen]

On Mon, 21 Dec 2020 at 15:25, Volker Schmidt  wrote:

> Thanks for the pointer, but It does not help. I'm an iD occasional basic
> user only.
>

Ah.  I thought one of your main gripes was the iD was warning you about
stuff
you weren't editing.

I am talking about the behaviour of JOSM.
>

I'm in the reverse position to you: I use JOSM occasionally, mainly for
splitting areas (there are large woods around here with named portions
that have been mapped as one big wood) which iD doesn't appear to
have any way of doing.

Maybe I am also JOSM ignorant regarding its functionalities.
>

If it isn't built-in functionality then there's probably a module to
do what you want.  And if there isn't a module, I expect one could
be written.

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

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Paul Allen via Tagging]

On Mon, 21 Dec 2020 at 09:02, Volker Schmidt  wrote:

>
> That we will have to live with two tags, or more,  for the same thing is
> nothing new, what I don't like is to be pestered continuously to do things
> to objects that happen to be in my downloaded area, and which I had no
> intention even to look at.
>

If you open iD's issue inspector you have the choice of "My edits" or
"Everything."  You also have the choice of "In view" or "Everywhere."  Does
that help?

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sun, 20 Dec 2020 at 16:11, Peter Neale via Tagging <
tagging@openstreetmap.org> wrote:

> I agree. To be called a "pillow", it would have to be soft and not rigid.
> IIRC there are traffic calming "pillows" that are filled with air and
> deflate, if you drive over them slowly, but remain inflated, if you drive
> over at speed.  I regret that I cannot find a reference to them at the
> moment.
>

https://en.wikipedia.org/wiki/Speed_bump#Dynamic_speed_bumps

Not what you were thinking of, but achieving the same end (the effect
depends on the speed of the vehicle):
https://www.matfoundrygroup.com/News%20and%20Blog/The_Future_of_Roads_Liquid_Speed_Bumps

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

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Paul Allen]

On Sun, 20 Dec 2020 at 15:29, Volker Schmidt  wrote:

>
>
>
> In addition, please consider that deprecated features are being flagged by
> editor sw on
>
saving any changeet that contains an deprecated tag, even if it has nothing
> to do
>
with your actual editing, this would be adding another contnued nuisance
> for mappers
>
(there are already others opf that type).
>

> Please don't do it
>

Too late, at least for iD.  Its authors have already decided to deprecate
landuse=reservoir.  All this proposal does is document the fact.

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

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Paul Allen]

On Sun, 20 Dec 2020 at 15:05, Jeremy Harris  wrote:

> On 20/12/2020 14:42, Paul Allen wrote:
> > There may be many uncontrolled crossings (no lights, no
> > zebra markings) in built-up areas, mostly at junctions.  They
> > typically have a dropped curb with tactile paving of a
> > different colour (does that count as markings or not?).
>
> I use
>
> crossing=unmarked
> tactile_paving=yes
>
> for those.
>

That's probably as good as we have, for now.  I'd go with
tactile_paving=contrasted, if appropriate.  But it doesn't cover
priority.  Until I took a close look at the rules today, I didn't
realize that if it's at a junction then pedestrians crossing
have priority over vehicles turning into the junction (but
presumably not over vehicles turning out of the junction).
No, I'm not a dangerous driver who doesn't know the rules,
I'm a dangerous pedestrian.

That priority over vehicles turning into the junction
makes life easier at an otherwise difficult crossing
near me.  Maybe.  The crossing goes across a
one-way street, so I don't have to worry about cars
turning out of the junction (there aren't any).  But
the layout of the one way system means cars
coming from one direction are forced to turn into
it, so are they really turning into it or just keeping
in lane?  https://goo.gl/maps/JCpDmKtsyZcYSkVm7

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sun, 20 Dec 2020 at 14:55, <80hnhtv4a...@bk.ru> wrote:

> traffic calming device often used in *Czech republic*
>
> I found this;
> https://cs.wikipedia.org/wiki/Zpomalovac%C3%AD_pr%C3%A1h
>
> 
>
> Zpomalovací polštáře, = english, Deceleration pillows
>

"Pillow" in English would not be associated with that shape and
rigidity.  This is a pillow:
https://en.wikipedia.org/wiki/File:Average_White_Pillow.jpg

I doubt any English speaker would look at one of those devices and
describe it as a pillow.

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

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Paul Allen]

On Sun, 20 Dec 2020 at 13:57, ipswichmapper--- via Tagging <
tagging@openstreetmap.org> wrote:

>
> From reading all these comments, it is clear a "crossing=priority" is not
> a good tag. In many places, pedestrians always have priority at
> intersections even if there is no crossing. The "crossing=priority",
> however, assumed that the crossing is marked (if it gives priority). This
> is because of my experience in the UK.
>

Even in the UK it's not quite that simple.

At light-controlled crossings, vehicles must stop on red whether there are
pedestrians or not.  On flashing amber, vehicles must give way to
pedestrians but may proceed with caution if there are no pedestrians.
Even on green, vehicles must give way to pedestrians still on the
crossing (there shouldn't be any, but if there are...)

At zebra crossings, vehicles must slow down if pedestrians are
waiting to cross.  However, vehicles do not have to give way to
pedestrians until they move onto the crossing (this contrasts
with priorities in other countries where pedestrians waiting
to cross but have not yet stepped onto the crossing have priority).

There may be many uncontrolled crossings (no lights, no
zebra markings) in built-up areas, mostly at junctions.  They
typically have a dropped curb with tactile paving of a
different colour (does that count as markings or not?).
Cars have priority (pedestrians must wait for a gap in
traffic) but once a pedestrian has started to cross,
the pedestrian has priority over traffic turning
into the junction.

Crossing is legal elsewhere (unlike some jurisdictions)
but pedestrians are advised to use a controlled crossing
if there is one nearby.  Pedestrians do not have
priority even when they're on the road but motorists
are required to try to avoid running over pedestrians.

There are probably cases I've missed.

Pedestrian priority isn't a simple yes/no.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sun, 20 Dec 2020 at 12:32, Brian M. Sperlongano 
wrote:

>
> "Hillock" is quite common in British English
>
>
> To describe a traffic control device?
>
> It is not the first word that came to my mind when I saw a picture of them.
Not the second, either.  Maybe the 49th.

The first word was "molehills."  The second was "mounds."  The third was
"dalek."  And I'm no longer sure that "mounds" is suitable.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sun, 20 Dec 2020 at 11:52, Peter Elderson  wrote:

> I'd say they are small mounds.
>

Talk to an archaeologist and mounds can be quite large.  Talk to
a baseball player and mounds are smaller than archaeological
mounds but still quite a bit larger than these speed bumps.

>
> Hillock sounds too, er, hilly.
>

Indeed.  Hillocks are small hills.  Bigger than mounds.

Sadly, the manufacturers and purveyors of these things haven't
come up with a name for this particular type of speed bump,
other than proprietary, trademarked names like "Dura-bump,"
and we can't use trademarked names when they are
available from more than one manufacturer under
different trademarked names.

Even if we decide that "hillock" is a suitable description
the tag should be "hillocks" not "hillocky."  A noun, not an
adjective.  Plural because it takes more than one of them to
constitute a traffic calming measure.

They still look about the size and shape of molehills to me.
I suspect that "molehill" will enter the vernacular as a
way of referring to them - if they look like molehills...

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sat, 19 Dec 2020 at 23:58, <80hnhtv4a...@bk.ru> wrote:

> it had the word bump in it.
>

Yes, it had the word "bump" in it.  "Bump" is an English word.  There
are traffic-calming devices with the word "bump" in their name.

The proposal talks of "bumbs."  "Bumb" is not an English word.  I
cannot find any traffic-calming device with "bumb" in their name.

It's bumP versus bumB.  One is a word.  The other is not a word
but is in the proposal.  Twice.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sat, 19 Dec 2020 at 23:45, 80hnhtv4agou--- via Tagging <
tagging@openstreetmap.org> wrote:

>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:traffic_calming%3Ddynamic_bump
>

It's not a "hillocky."  The proposal doesn't contain the word "bumb."  It's
not
a rumble strip.

Was there any reason for posting that?

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

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

[Paul Allen]

On Sat, 19 Dec 2020 at 23:50, Martin Koppenhoefer 
wrote:

>
> On 20. Dec 2020, at 00:35, Paul Allen  wrote:
>
> one swallow doesn't make a summer but it makes a great BJ.
>
>
> you must be talking of ice cream?
> https://en.wikipedia.org/wiki/Ben_%26_Jerry%27s
>

You got it.  It's not the first thing on that page, but it's the first that
fits
how I used it. :)

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sat, 19 Dec 2020 at 23:31, <80hnhtv4a...@bk.ru> wrote:

> Round Circle Speed Humps
> 
>

Indeed.  But you responded with that information to a post of mine which
was solely about the word "bumb" in the proposal.  Your response here
 was a non sequitur.

In a different post somebody suggested these things might act as
rumble strips.  Your response would have been appropriate there.
Assuming they were not misnamed by somebody who couldn't
think up a better name for them.

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

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

[Paul Allen]

On Sat, 19 Dec 2020 at 22:57, Martin Koppenhoefer 
wrote:

>
> > On 19. Dec 2020, at 23:44, Graeme Fitzpatrick 
> wrote:
> >
> > (& I can already hear Paul saying just because it's old doesn't
> necessarily make it historic! :-))
>
> yes, but so far I didn’t read from anybody else that they would share this
> particular concern,


Apart from the wiki page, of course.


> one swallow does not make a summer. ;-)
>

I don't see many sharing your viewpoint, either.  :p

Anyway, one swallow doesn't make a summer but it makes a great BJ.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sat, 19 Dec 2020 at 23:19, 80hnhtv4agou--- via Tagging <
tagging@openstreetmap.org> wrote:

>
> https://streetsolutionsuk.co.uk/collections/speed-ramps/products/round-yellow-circle-speed-humps-50mm?variant=19772633645113
> 
>

That didn't take me where you intended.  I had to navigate from where I
ended
up to those things.  Ended up at the URL you gave, but couldn't get there
directly.  It calls them speed bumps.  Which doesn't answer my original
question of whether the word "bumb" in the proposal was a typo or yet
another kind of traffic calming device.

It also doesn't directly answer if these function in the same way as
rumble strips or as speed bumps, but from the name I'd guess
they're not an alternative to rumble strips.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sat, 19 Dec 2020 at 22:45, 80hnhtv4agou--- via Tagging <
tagging@openstreetmap.org> wrote:

> https://roadsafetygb.org.uk/news/is-the-uk-ready-to-rumble/
>

I am not convinced that article pertains to "hillockys."  It is about
rumble strips and does not show these things.  Somebody else
gave a link to dura-bumps which look similar and have the claimed
advantage of low noise.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sat, 19 Dec 2020 at 19:45, Mateusz Konieczny via Tagging

>
> I wonder whatever there is even a British English name for that
> (or is hillocky an UK name?)
>

As far as I can tell we don't use these in the UK.  If we did, though,
we wouldn't call them "hillocky" but we might call them "hillocks."
Calling them "hillocky" would be like calling other calming
measures "bumpy" and "humpy."  "Hillocky" is an
adjective.

"Hillocks" (plural) would be correct here as a single
traffic-calming object would be composed of several
hillocks.  Correct English grammar, not necessarily
what we'd actually call them if they were introduced
here.  They might end up being called molehills or
mounds.  Hillock implies something larger than these
are.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sat, 19 Dec 2020 at 18:25, Tomáš Hurýn  wrote:

>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:traffic_calming%3Dhillocky
>

Are the two mentions of "bumbs" meant to be "bumps" or are bumbs yet
another undocumented calming device?

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

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

[Paul Allen]

On Sat, 19 Dec 2020 at 20:49, Brian M. Sperlongano 
wrote:

> I understand pitch to mean "a playing field" (as "pitch" is not often used
> in US English -- we would say "soccer field" for example.).
>

Pitch and field are almost synonyms.  A lot of overlap, some differences.


>   I don't know if a shooting range is a pitch or not, but it definitely
> isn't a playing field.
>

A shooting pitch or shooting field is wrong.  As is ice hockey pitch, ice
hockey
field, golf pitch, golf field, tennis pitch, and tennis field.

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

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

[Paul Allen]

On Sat, 19 Dec 2020 at 19:47, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Is there some good use for sport=shooting_range?
>

Not in English as she is spoken.  "Shooting range" is not a sport.
"Shooting" is a sport.

>
> Or is it always preferable to use sport=shooting + leisure=pitch?
>

That's an improvement.  Not ideal, because it's practised at a
range, not on a pitch.  Just because we have other sports that
have been shoe-horned into leisure=pitch I don't see a good
reason to continue making that error.  A few bad ones,
but no good one.

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

Re: [Tagging] Tagging sewage treatment basins

[Paul Allen]

On Fri, 18 Dec 2020 at 01:04, Joseph Eisenberg 
wrote:

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

landuse=basin seems inappropriate for many wastewater  treatment plants.
It may be appropriate for plants which use constructed wetlands, but the
plants
that have aerators, clarifiers, digesters, etc. don't have anything that
could be
called a basin but do have large, mappable objects (the circular profiles
are
a good clue from aerlial imagery that a wastewater plant is there).  See
https://upload.wikimedia.org/wikipedia/commons/5/54/ESQUEMPEQUE-EN.jpg

There are also farm slurry pits, which handle animal faeces but do not
attempt to purify water.  https://en.wikipedia.org/wiki/Slurry_pit

I'm not entirely happy with natural=water being applied to either sewage
treatment or slurry.  Neither are natural and neither store water.

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

On Wed, 16 Dec 2020 at 03:07, Graeme Fitzpatrick 
wrote:

>
> On Tue, 15 Dec 2020 at 23:55, Paul Allen  wrote:
>
>>
>> 1) Holiday cottages are rarely building=cabin, they are mostly
>> building=house.
>>
>
> May depend on where you are? I know of a number of places that advertise
> cottages / cabins eg http://lyrebirdspringbrook.com/index.html
>

Cabins as holiday cottages may be common in your part of the world but
in my part they're rare.  This is a holiday cottage around the corner
from me: http://maenayron.co.uk/accomodation/  And these are
a group of six holiday cottages in converted farm buildings:
https://www.trenewydd.com/

One around the corner from me is a former house
>> that has been converted to a holiday let.  Even the ones on farms
>> are converted stone barns, converted stone stables, etc.
>>
>
> Shouldn't they then stay as their original type of building? From the
> buildings page:  the value may be used to classify the type of building.
> Note that it may be not the same as the building's current use (tagged
> using building:use <https://wiki.openstreetmap.org/wiki/Key:building:use>
> =*). For example, a hospital building that is abandoned or repurposed to
> be a marketplace is still a building=hospital
> <https://wiki.openstreetmap.org/wiki/Tag:building%3Dhospital>
>

Indeed.  building=house + tourism=chalet or building=barn + tourism=chalet
or building=cabin + tourism=chalet, depending on the original building type.

>
>
>> 2) A farm which has converted some of its buildings to
>> holiday cottages will have a mix of building types.  Mappers
>> who wish to go into details would prefer to see the
>> individual holiday cottages rendered distinctly (as
>> they currently are).
>>
>
> But building=yes + name=xxx will still render sufficiently, won't it?
>

Apart from the icon.  Which, if you're looking at a map of the area looking
for places to stay is kinda important.  Just building and name is
indistinguishable from any other building with a name.  See
https://www.openstreetmap.org/?mlat=52.08485=-4.65761#map=18/52.08485/-4.65761

>
> 3) This scheme has problems with individual holiiday
>> cottages, such as the one around the corner from me,
>> unless you retain tourism=chalet for such cases.
>>
>
> Individual as 1 cabin per site, or, as Mateusz raised, multiple cabins on
> one site?
>

Individual as 1 cabin per site.  As in a working farm that has converted
just
one of its outbuildings to a holiday cottage.  As in an ordinary house in a
row of houses that is operated as a holiday cottage.

I can understand some mappers may not want to add multiple holiday
cottages on a single site and want a short cut.  I'm happy with that
as long as it doesn't preclude adding them as individual cottages later.
Some sort of grouping tag is desirable for searchability using
Nominatim.  Some sort of grouping tag is desirable for rendering.
But I'd like to be able to present a usable representation of a
site with multiple holiday cottages so that consumers can tell
what is and isn't a holiday cottage without having to cross-refer
with a website or facebook page.  Such as here
https://www.openstreetmap.org/#map=19/52.10789/-4.61545

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

On Mon, 14 Dec 2020 at 21:07, Jmapb  wrote:

[On distributed motel cabins]

> No indeed it does not. I would be uncomfortable using the tourism=motel
> tag on any establishment with a minimum week stay, kitchens or no. Even a
> 2-night minimum at a motel would wrinkle my brow.
>
There might be individual cases where the lines blur, but mostly holiday
cottages operate on a very different basis to motels.  So tourism=motel
doesn't fit, as we both agree.

> For Canllefaes, I'd be happy enough with leisure=resort.
>
I wouldn't.  Maybe there's a difference between UK and US understanding
of the term resort.

In the UK a holiday resort is in many ways similar to a large village.
Many residences.  On-site facilities usually include some or all of
a pub, a fast-food diner, a restaurant, a night club/disco, maybe a
cinema, a convenience store, an amusement arcade, amusement
rides.  You can get everything you need (except experience the
surrounding area) without leaving the grounds.  Usually
the facilities are open to non-guests but guests may get
discounted prices and or priority access (such as free
rides on the big dipper and the privilege of getting on
the ride ahead of non-guests).  Given on-site
fast food and restaurant, catering in the
accommodations may be limited to kettle,
toaster and maybe microwave.  In some ways
there are similarities between a docked cruise ship
and a holiday resort.

A group of five or six holiday cottages that are converted
farm buildings don't justify that sort of investment in
infrastructure.  You might get a playground with a slide
and swings.  Maybe even a swimming pool (those
are rare and Canllefaes is an exception).  Maybe,
if there are a dozen holiday cottages then a small
convenience store (which may also serve a nearby
hamlet).  There's not the room in a farmyard to
put more holiday cottages (and planning permission
would be withheld even if there were room).  So
the facilities I'd expect at a holiday resort won't
be there.

We might find a case or two where the boundary is blurred,
but mostly leisure=resort (as I understand resort) doesn't
fit.

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

On Tue, 15 Dec 2020 at 08:53, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Dec 15, 2020, 03:33 by graemefi...@gmail.com:
>
> How about tagging the whole area as tourism=chalet + name=Foo Cottages +
> capacity=25
> then tagging each individual cottage / cabin as either
> building=cabin / bungalow + name=xxx?
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dcabin
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dbungalow
>
>
> I am fine with that and I plan to restore this tagging recommendation
> unless someone will proposed a better one.
>

I see four problems with it.

1) Holiday cottages are rarely building=cabin, they are mostly
building=house.  One around the corner from me is a former house
that has been converted to a holiday let.  Even the ones on farms
are converted stone barns, converted stone stables, etc.

2) A farm which has converted some of its buildings to
holiday cottages will have a mix of building types.  Mappers
who wish to go into details would prefer to see the
individual holiday cottages rendered distinctly (as
they currently are).

3) This scheme has problems with individual holiiday
cottages, such as the one around the corner from me,
unless you retain tourism=chalet for such cases.  But
then we end up with two ways of tagging individual
cottages in a group with different renderings.

4) There are a lot of tourism=chalet.  Are you proposing
we bulk edit them?

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

On Mon, 14 Dec 2020 at 20:38, Joseph Eisenberg 
wrote:

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

If it's a single building, maybe it's still a hotel.  Maybe some refining
tags could be added.  Maybe it needs a new value.  Maybe it's not
even tourism.

Things always end up being complicated.  The only way the extended stay
hotel could get more complicated is if it was composed of distributed
cabins.

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

On Mon, 14 Dec 2020 at 10:57, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

So my questions are: what is the UK (or English in general) word for
> location with group
> of holiday cottages?
>

I can't think of an English term, other than "holiday cottages."  These
places
generally call themselves "Foo Holiday Cottages" or "Foo Holidays" or
"Foo Farm Cottages" or things like that.


> Especially group of them in a fenced area, with shared amenities
>

There isn't anything I can think of, other than holiday cottages (plural).

such as restaurant/cafeteria,
>

Far too grandiose.  For starters, the whole idea of holiday cottages is
that they are self-catering.  A restaurant or cafeteria is something
you'd find at a resort.  Occasionally I've seen a farm conversion
which has a B and a couple of holiday cottages where the
B could provide meals by special arrangement, but that's
rare.


> firepit,
>

Firepit, barbeque, swimming pool, fishing pond are all things I've
seen with a group of holiday cottages.


> maybe sauna or lake access.
>

I've not seen a sauna.  A couple of hot tubs (we don't have a good
official way to tag them as the wiki recommendation of Jacuzzi is
a registered trademark).  I'd say a sauna is highly unusual for
holiday cottages in the UK, but might be common in Nordic
countries.

>
> But without extensive entertainment infrastructure that would qualify for
> leisure=resort.
>

Also without the restaurant/cafe you suggested.

>
> Would it be a good idea to revert this two edits and fully restore
> recommendation
> to use tourism=chalet for group of chalets?
>

I would say it's a bad idea for tourism=chalet to apply to both
individual holiday cottages and to groupings.  It makes it harder
to figure out how many there are.  A building tagged with it might
be an individual holiday cottage but I've seen a long barn converted
to three holiday cottages.  A number of buildings within an outline
might all be holiday cottages or a couple of holiday cottages and a
couple of farm buildings.

Or maybe we need a new tag?
>

I think we need a new tag.  Either a boundary or a relation.

Note also that there may be hybrids.  Just as we've come to the
realization that caravan parks may allow some tents and camping
grounds may allow some caravans, some farms offer holiday cottages
and camping.  It gets messy.

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

On Mon, 14 Dec 2020 at 06:22, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> There are cases where there is group of multiple holiday cottages,
> each rentable independently. I know about cases with just 2 and big
> groups, 25 in one place.
>

I know many of those.  It happens around here when a farmer decides it's
more profitable to farm humans than animals so converts outbuildings
to holiday cottages.  Sometimes with names reflecting their former
usage (The Barn, The Dairy, etc).

> How it should be tagged?
> I found https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dchalet
> that is for a single one.
>

Yes, that's for one.  But there is nothing for a group,  Operator on each
ties them together loosely, but it would be nice to have a relation or
a boundary for them that could be rendered as a name for the grouping,
would have a link to the web site for the whole enterprise, etc.  It would
also make the operator name findable with Nominatim.

>
> Tagging 25 tourism=chalet independently is sill when they form
> single object, not 25 separate ones.
>

I would still tag them independently, so that people can see which building
is Chestnut Cottage, Oak Cottage, etc.  Also so as to distinguish holiday
cottages from unconverted farm buildings (some of the farms around
here still operate as farms but have converted only two or three of
many farm buildings).  But mappers could leave the buildings untagged
if they were unsure or didn't want to put too much time into it.

If we go for a relation rather than a boundary there would be a need for
other
roles. Some places have a playground, or a games building, or a common
building for laundry, or a soccer pitch, or a barbeque area, or a swimming
pool, or
a miniature railway (yes, I've mapped a miniature railway at a group of
holiday
cottages), etc.

leisure=resort doesn't fit.  At least not as it's described in the wiki.
There may be no other recreational features at all, just accommodation.
If there are recreational features they are (usually) only for those
staying at the accommodation and not available to the general
public.

In some ways the concept resembles a small static caravan park
but with buildings rather than static caravans.

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

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

[Paul Allen]

On Sun, 13 Dec 2020 at 14:13, Brian M. Sperlongano 
wrote:

>
> Is it time to more directly recommend that mappers favor natural=water +
> water=reservoir *instead of* rather than *in addition to* landuse=reservoir?
>
> The reality is that no matter what it says in the wiki and no matter what
conclusions we reach on this list, tagging practise is largely determined
by editor presets.  If the user searches for reservoir then how it is
tagged depends on the editor (a very small fraction of users tag
manually, but most do not).

I just tried iD and it gives me natural=water + water=reservoir.  If
the other major editors do the same then the thre choices are:

1) Persuade all the major editors to revert (difficult)

2) Amend the wiki pages to reflect the new reality.

3) Ignore the issue.

-- 
Paul
___
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?

[Paul Allen]

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

>
> In many cases, the buildings are long gone and just the name remains. I
> *thought* that those places were still labelled in upright letters in the
> ”official” maps, but it turns out that I was wrong — in the present-day
> online-only version of those maps, those names that have lost their
> buildings have turned italic.
>

If the places have lost their buildings, that is what place=locality is
for.  As for
the label being italic or upright depending upon national sensibilities,
that is
why many countries have their own carto.  Sweden has its own carto at
http://openstreetmap.se/ although that has been down every time I've tried
it
in the past couple of weeks.  I don't know if that's recent or is a
continuation of it going down in April.  It may be worth your while
trying to find out why it's down and what it would take to fix it.


> Which is good for us, because it means we could still map building=torp
> where there actually is a building, and something else (historic=torp?
> historic=farm, farm=torp?) where there isn’t. :)
>

 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.

As for historic=farm, the tag historic doesn't mean old (use start_date=*)
or disused (use disused:landuse=farm or add disused=yes).  If the
building is under the protection of a recognized heritage
organization (in Sweden it's the Riksantikvarieämbetet) then add
heritage=* and associated tagging.

Note that one person will probably chime in with a view of historic=*
that makes it applicable to anything more than 1 second old and
therefore meaningless.  I prefer the wiki definition which means it
is for things that are notable rather than just old: historic, not
historical.

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

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

[Paul Allen]

On Thu, 10 Dec 2020 at 17:08, Joseph Eisenberg 
wrote:

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

We cannot be certain of the dialect of English spoken by that page's
author.  When it
states the official names are "The British Armed Forces" and "Her Majesty's
Armed
Forces" that is probably correct.  Referring to them as "military services"
may be
influenced by the USAian dialect.

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

The same goes for the dialect spoken by that page's author.

However, whilst only the military services in the UK are armed forces,
police in
the US are generally armed.  So there would be confusion if we used UK
terminology here.


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

Lizzie Windsor speaks with a Birmingham accent.  An old Birmingham accent
that differs
greatly from the current one, but a Birmingham accent.  It's a relic of the
time when
Birmingham and the surrounding area was responsible for much of the
country's
wealth.

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

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

[Paul Allen]

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

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

[Paul Allen]

On Wed, 9 Dec 2020 at 20:43, ael via Tagging 
wrote:

> On Wed, Dec 09, 2020 at 01:07:52PM -0500, Brian M. Sperlongano wrote:
> > >
> > >- Hidden dip
> > >
> > > Maybe.  There is a barely used tag hazard=dip.  Is this a permanent
> > feature?
>
> We have examples in the UK, even on major roads like the A346 between
> Marlborough and Swindon. I don't think they are tagged. I struggle to
> see why tagging as a hazard would be useful in OSM today, but perhaps
> with sophisticated routers issuing an alarm on approach might be
> something in the future. These dips are clearly signed.
>

I would prefer a router warn me of such things at the outset, when I could
ask it for an alternative route.  Finding out when you get near may still
need extensive back-tracking.

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

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

[Paul Allen]

On Wed, 9 Dec 2020 at 20:01, Jeremy Harris  wrote:

> On 09/12/2020 19:43, Paul Allen wrote:
> >
> > For the swing bridge, it's covered.  But the text says "Opening or swing
> > bridge."
> > I have no idea what an opening in a route might be if it's not a movable
> > bridge
> > but maybe somebody else on the list does.
>
> Lift bridge.  Has a horizontal axis for the moving part, which moves
> vertically.
> Think of Tower Bridge,
>

Thanks.  I was parsing that wrong.  I was thinking "(opening) or (swing
bridge)"
not "(opening or swing) bridge."  No wonder it had me puzzled.

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

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

[Paul Allen]

On Wed, 9 Dec 2020 at 18:13, Brian M. Sperlongano 
wrote:

>
>
>> Here are the ones that I think are worth considering:
>>
>>- Opening or swing bridge ahead
>>
>> This is already covered by the approved tag bridge:movable and its
> various sub-keys that describe different types of movable bridges.
>

For the swing bridge, it's covered.  But the text says "Opening or swing
bridge."
I have no idea what an opening in a route might be if it's not a movable
bridge
but maybe somebody else on the list does.


   - Overhead electric cable

Overhead powerline cables are already mapped, it seems that would be
> sufficient to know that there is an overhead cable.
>

Only if the height of the cable is specified, and it rarely is.  In my
country there
are minimum clearances in most cases, and only extra-tall vehicles need to
take special care.  But there are cases where the clearance is lower than
might
normally be expected.  My feeling is that if some authority thinks a cable
needs a
warning sign then it should be considered a hazard.

   - Hidden dip

Maybe.  There is a barely used tag hazard=dip.  Is this a permanent feature?
>

I don't know.  I don't recall ever seeing that sign.  But in my part of the
world we have old hump-backed bridges so it's conceivable we have
roads with hidden dips, too.

One not covered there is the warning that a route is unsuitable for long
>>
> vehicles.  There are a few minor roads near me like that.  Drive a long
>> vehicle along them and (at best) you have a long reverse or (at worst)
>> you get stuck.
>>
>
> Since we have tags to describe the width of roads, and the ways making
> them up have a geometry associated with them, it seems that this is
> something that routers could simply calculate based on existing tagging.
>

Routers could calculate it, but at what computational cost?  Maybe it's
something
they do anyway, so zero cost.  Maybe it could be derived from something they
already do, so low cost.  My guess is that they don't examine road geometry
in that much detail, if at all, and it would be expensive.

Also, think of a T junction.  A sharp, 90-degree turn.  In practise, lane
widths
give some leeway for the turn.  In practise, junction corners may be rounded
to allow long vehicles to turn.  Routers which tried to evaluate road
geometry
for long vehicles could end up incorrectly discarding T junctions.

Digging around, I found
https://www.legislation.gov.uk/uksi/2002/3113/schedules/made
which lists several "unsuitables": heavy goods vehicles, long vehicles, wide
vehicles, buses, caravans, trailers, articulated vehicles.  Some of those
might
be better handled by the appropriate access restriction, if we had access
restrictions for them and if this were a legal prohibition (it isn't).

>
>
>> Also, in the UK, the sign for unexploded ordnance is the same as you
>> have for minefields.  That symbol first appeared in UK Defence Standard
>> 05-34, Marking of Service Matériel, and was called (bizarrely) "Unexploded
>> explosive ordnance" (if it has exploded it would no longer be explosive,
>> and if it's explosive then it must be unexploded).  In old money it
>> would have been called "unexploded bomb."
>>
>
> Thanks!  This is not a sign I normally see on my daily commute :)
>

I did some more digging.  It's not a sign associated with minefields unless
those minefields also have unexploded ordnance that isn't mines.  There
is no standard sign for minefields, but there is a semi-standard.  See
https://studioissa.com/warning-signs-how-landmines-can-teach-us-about-project-design-and-communication/
and
https://www.mineactionstandards.org/fileadmin/MAS/documents/archives/IMAS-08-40-Ed2-Am1.pdf

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

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

[Paul Allen]

On Wed, 9 Dec 2020 at 16:53, Brian M. Sperlongano 
wrote:


> I think there may be other hazard warning signs in that document for you to
>> consider.
>>
>
Many of the signs on that list are already described by other tags.
>

It's a list of all warning signs, not merely hazards.  But there are quite
a few hazard signs in there.


> Are there specific signs you feel are missing from the hazard key?
>

I didn't do a full comparison.  I was kinda hoping you would, seeing as you
probably remembered which ones you'd added to your proposal.  Some
of them are debatable as to whether or not existing tagging is
adequate.  Here are the ones that I think are worth considering:

   - Opening or swing bridge ahead
   - Steep hill
   - Trams crossing ahead
   - Level crossing without barrier or gate
   - Frail (or blind or disabled) pedestrians crossing
   - Pedestrians in road ahead [no sidewalk]
   - Overhead electric cable
   - Sharp deviation of route
   - Ice
   - Hidden dip

I wouldn't have thought the ice hazard needed mentioning, if it weren't
for the plot of a Jack Reacher novel.  Some bridges can ice over sooner
than the rest of the road even when icing doesn't seem much of a risk,
and that may be a problem other than on bridges.  Depending on climate,
such a warning may be present year-round.

One not covered there is the warning that a route is unsuitable for long
vehicles.  There are a few minor roads near me like that.  Drive a long
vehicle along them and (at best) you have a long reverse or (at worst)
you get stuck.

Also, in the UK, the sign for unexploded ordnance is the same as you
have for minefields.  That symbol first appeared in UK Defence Standard
05-34, Marking of Service Matériel, and was called (bizarrely) "Unexploded
explosive ordnance" (if it has exploded it would no longer be explosive,
and if it's explosive then it must be unexploded).  In old money it
would have been called "unexploded bomb."

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

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

[Paul Allen]

On Wed, 9 Dec 2020 at 14:26, Brian M. Sperlongano 
wrote:

> I have found examples of both falling rock[1] and fallen rocks[2] on
> signage and it's not clear to me which is the more common.
>

The UK signage for this hazard doesn't have text.  But the explanation of
the
signage in the Highway Code says it warns of "Falling or fallen rocks."  See
https://www.highwaycodeuk.co.uk/warning-signs-on-the-road.html
and search for "falling".

In that same document, just above the falling/fallen rocks sign is the
aircraft sign which it says warns of "Low-flying aircraft or sudden
aircraft noise".
Low-flying aircraft will often cause a sudden aircraft noise, but a
high-flying
supersonic aircraft can generate a sonic boom (but these are rare and if
they occur they are not likely to be predictable as they will usually be
the result of an emergency).

I'd suggest fallen_rock and low_flying_aircraft as tag values based upon
the common case but have the proposal mention their secondary application.

I think there may be other hazard warning signs in that document for you to
consider.

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

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

[Paul Allen]

On Wed, 9 Dec 2020 at 13:13, Brian M. Sperlongano 
wrote:

Add hazard=falling_rocks, landslide; deprecate rock_slide, rockfall
>

Kevin Kenny argued (I think convincingly) that the hazard is fallen, not
falling, rocks.  There is a very slight risk that a rock will fall on your
vehicle but the greater risk, by far, is that you will drive into a fallen
rock.

Editors could make both fallen and falling searchable, and identify
the preset as "falling/fallen rocks," so we might as well make the
value reflect the really big risk rather than the very small one.

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

Re: [Tagging] Feature Proposal - RFC - barrier:guard_stone

[Paul Allen]

On Tue, 8 Dec 2020 at 09:56, Martin Koppenhoefer 
wrote:

>
> I am not saying that these stones should or not get a historic tag, but
> surely it isn’t an argument that one of the OpenStreetMap based maps
> highlights things based on a wildcard selection.
>

Not an argument, merely a piece of evidence to consider.


> If this tag would pose a problem for their rendering I am sure they would
> adjust the selection rules.
>

Or perhaps we should not force them to adjust their selection rules by
abusing
"historic" to mean "old."  We have start_date=* to specify that things are
old.

>
> Regarding “historic means historic as in the battle of Waterloo or the
> pyramids of Gizeh”, we have seen from previous discussion that this was a
> minority opinion.
>

An explanation, by one person, of what the wiki page says and the
distinction
between "historic" and "historical."  Those do not mean the same thinhg,
however much you wish them to.

On the one hand we have the wiki page, the distinction between
"historic" and "historical" and a map with the sole purpose of
rendering historic, rather than historical, objects.  On the other
hand we have people who insist that "historic" means "historical."

Many people see historic as a keyword for objects that typically could be
> seen as historic, but then includes any objects of the class, without
> further  differentiating them by “historic value”.
>

Many people do not read the wiki page.  Many people do not understand
the distinction between "historic" and "historical."

>
> We do not have different tags for truly historic wayside shrines or
> crosses and others. How many charcoal piles do you expect to be of
> exceptional historic value?
> https://taginfo.openstreetmap.org/keys/historic#values
>

I would expect a handful, at most, not the tens of thousands that have been
mapped.  Those SHOULD have been mapped with a lifecycle prefix.  But
people who don't understand the difference between "historic" and
"historical" and don't read the wiki misuse historic=* then document it.

>
> For guard stones I could imagine using the man_made key as well, but
> historic would seem to work because most of these are giving testimony of
> former times.
>

"Historic" does not mean "historical."  Those stones are historical but
they are not historic.  If you want to emphasise that they are old,
start_date=* is the way to go.

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

Re: [Tagging] Many historic=wayside_cross are not historic

[Paul Allen]

On Mon, 7 Dec 2020 at 23:11, Volker Schmidt  wrote:

> That includes everything from a homemade little altar on the fence of a
> private home to a minute chapel-like shrine on a minor road crossing that
> most likely sits on top  of a Roman shrine for the local water goddess.
>
> My real question is: Am I correct that this is the accepted tagging after
> all, and that's it?
>

It is in use, perhaps even de facto.  Some purists (such as myself) think
it is
not always justified.

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

Re: [Tagging] Many historic=wayside_cross are not historic

[Paul Allen]

On Mon, 7 Dec 2020 at 22:33, Volker Schmidt  wrote:

> I am sure someone has made this observation before me:
>

We rehash this frequently. :)

Many historic=wayside_cross and historic=wayside_shrine are not historic
> objects in the sense of the definition of the wiki page Historic
>  which reads:
> "The historic =* key is
> used to identify features that are of historic interest"
>

That depends how you define "historic interest."

We have 130k "historic" wayside crosses and 80k "historic" wayside shrines
> in the database.
> Many of these are "mine" and many of these are certainly not of any
> historical interest, they are often not even old. But some few certainly
> are historic.
>

The roadside shrines commemorating accidents are historic.  That accident
may have happened long ago and the memorial erected yesterday.  Or the
 accident may have happened recently.  Such shrines act as a form of
plaque saying "this happened here on this date."

The ones that do not commemorate an accident or other historic event are
merely open-air places of worship.  The equivalent of a chapel of ease
without the building.  However, if they were on a historic pilgrimage route,
then they may count as historic, although that is debatable.

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

Re: [Tagging] Feature Proposal - RFC - barrier:guard_stone

[Paul Allen]

On Mon, 7 Dec 2020 at 21:28, Anne-Karoline Distel 
wrote:

mostly for European use (I think), I propose a new node type barrier,
> namely "guard stone":
>

Your proposal says these should be tagged historic=yes.  Historic is not
a synonym for old, or disused, or even historical.  Historic means that
something is of note or importance.  Napoleon's loss at Waterloo was a
historic battle; Napoleon's loss in the school playground when he was 12
may be of historical interest but it was not a historic fight.

In any case, I see no reason why stones such as these might not be added
today, or replaced, which would mean they weren't even old, let alone
historic.

And if none of that persuades you, the historic=* tag is treated specially
by the Historic Places map and is given special emphasis.  It would
get very cluttered if these stones were classed as historic.  See,
for example,
http://gk.historic.place/historische_objekte/l/en/index.html?zoom=16=51.34027=12.3893=3=HaHbHcSaHe

If you have one of these stones where some important person wrecked
his carriage against it and that influenced subsequent events, that
might count as historic.  Otherwise it's just old.

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

Re: [Tagging] Feature Proposal - RFC - Military=Coast-Guard & Rescue=Marine_Rescue

[Paul Allen]

On Sun, 6 Dec 2020 at 16: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.
>

Branch or branches.   There are an increasing number of joint bases.
https://en.wikipedia.org/wiki/Joint_base

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

Re: [Tagging] Feature Proposal - RFC - Military=Coast-Guard & Rescue=Marine_Rescue

[Paul Allen]

On Sun, 6 Dec 2020 at 10:40, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> But maybe emergency=marine_rescue (or amenity=marine_recsue) would be
> better
> than a brand new key rescue in rescue=marine_rescue tag?
>

I can see both ways.  With emergency=rescue_station you have the
possibility of rescue=marine (not marine_rescue, because that is
needless duplication) and rescue=mountain and whatever else has
rescue stations.  OTOH, emergency=marine_rescue works and
is simpler.

The one thing I would avoid is tagging it as an amenity.

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Paul Allen]

On Fri, 4 Dec 2020 at 19:56, Martin Koppenhoefer 
wrote:

>
> They do not imply that you have to fear airplanes on the street, they
> are meant to prepare you for low flying aircraft.
>

Up until around ten years ago, a minor road went past the end of the
runway at what passes for an airport.  The planes could be so low on
approach to the runway that there were traffic signals to prevent
vehicles crossing the path of an aircraft.  There were also signs
warning of low-flying aircraft, which I referred to as "Give way
to aircraft."

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

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

[Paul Allen]

On Fri, 4 Dec 2020 at 01:05, Kevin Kenny  wrote:

> On Thu, Dec 3, 2020 at 1:09 PM Paul Allen  wrote:
>
>> That's not to say we don't have landslides in the UK, but it appears
>> we don't construct roads in places where they are anticipated to
>> happen.
>>
>
> The idea of "we don't build where the rocks might fall in the road"
> doesn't work all that well when every mountain pass poses the same risk.
>

We have quite a lot of falling/fallen rocks hazards.  We seem happy to build
roads there.  Not so many roads by landslide hazards.  Apart from a few
by colliery spoil tips, but there was no anticipated landslide hazard with
those.

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

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

[Paul Allen]

On Thu, 3 Dec 2020 at 18:16, Philip Barnes  wrote:

> On Thu, 2020-12-03 at 18:06 +0000, Paul Allen wrote:
>
>
> That's not to say we don't have landslides in the UK, but it appears
> we don't construct roads in places where they are anticipated to
> happen.
>
>
> https://en.wikipedia.org/wiki/A625_road#Mam_Tor_road
>

How could I forget Mam Tor?  I did cover myself by saying
"anticipated" but that was insufficient cover.  I should have said
"anticipated by morons."

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

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

[Paul Allen]

On Thu, 3 Dec 2020 at 17:54, 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.
>

In the UK we do not appear to have any signage warning of landslides.  The
one sign we have is described as warning of "falling or fallen rocks."  A
landslide is very different to falling rocks.

That's not to say we don't have landslides in the UK, but it appears
we don't construct roads in places where they are anticipated to
happen.

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

Re: [Tagging] Tagging Digest, Vol 134, Issue 130 animal tracks ?

[Paul Allen]

On Wed, 2 Dec 2020 at 22:35, Graeme Fitzpatrick 
wrote:

>
> On Wed, 2 Dec 2020 at 22:24, Paul Allen  wrote:
>
>> Here is a videoabout a bridleway.  Which is also a footpath (by legal
>> definition).  In fact,
>> it's also a Byway Open to All Traffic (BOAT).  Most of the time it's the
>> ONLY way to visit Foulnes Island.  It's also the most dangerous
>> path in Britain.  https://www.youtube.com/watch?v=mM7C_Pw7OL8
>>
>
> & which we do indeed have mapped:
> https://www.openstreetmap.org/way/158785097#map=14/51.5857/0.9244
>

And which somebody edited 2 hours ago (as I write this).  I suspect
that person read my previous mail or saw the video.

Which then goes back to the discussions we were having a while back about
> tagging the "dangerousness" of tracks.
>

Indeed it does.  Quicksand.  Tide.  Unexploded ordnance.  Maybe drop
bears, too.

Yes, it's marked as being a ford, tidal=yes, & visibility=no, which
> suggests it's not the spot for a Sunday afternoon stroll, but it's also
> marked as foot, horse, bicycle, car & motorbike=yes, which then suggests it
> can't be too bad after all?
>

That's legal access, not sane access.  You are legally permitted to drive
any legal road vehicle on it, but you would be crazy to do so.

>
> The basic facts given in that video could be included as a description,
> but shouldn't we have some sort of "danger" classification?
>

When we've figured out the tagging for dangers.

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

Re: [Tagging] Tagging Digest, Vol 134, Issue 130 animal tracks ?

[Paul Allen]

On Wed, 2 Dec 2020 at 04:38, Warin <61sundow...@gmail.com> wrote:

> Bridal ways are normally constructed. They normally remove obstructions to
> have a convenient route.
>
You were wise to cover yourself by adding "normally." :)  Here is a video
about a bridleway.  Which is also a footpath (by legal definition).  In
fact,
it's also a Byway Open to All Traffic (BOAT).  Most of the time it's the
ONLY way to visit Foulnes Island.  It's also the most dangerous
path in Britain.  https://www.youtube.com/watch?v=mM7C_Pw7OL8

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

Re: [Tagging] How to tag for dualband GPS ?

[Paul Allen]

On Wed, 2 Dec 2020 at 10:43, Martin Koppenhoefer 
wrote:

Setting it to 1s has the drawback of point clouds when you stand still (I
> used to stop recording every time I stopped moving, but admittedly it
> requires attention, also when you continue moving to set it back to rec).
>

That depends on the software.  Some software allows you to set a
minimum distance between points.  On my Android phone I use
GPS Logger
https://play.google.com/store/apps/details?id=eu.basicairdata.graziano.gpslogger=en=US
where I can tell it, for example, to add a point every second if
the distance from the last added point is more than 1 metre.  No
point cloud.  No remembering to stop recording when I stand
still.

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

Re: [Tagging] Tagging Digest, Vol 134, Issue 130 animal tracks ?

[Paul Allen]

On Tue, 1 Dec 2020 at 11:57, St Niklaas  wrote:

> A horse track is not a good choice to tend to walk on foot, it already has
> its own tag bridle way.
>

There is a difference between tracks worn by wild animals and bridleways.
Wild
animal tracks may not be walkable on foot.  Bridleways are intended for
riders on horses AND for walkers.  There may be no physical difference
between a footpath and a bridleway, the distinction being a legal one of
who is allowed access.

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

Re: [Tagging] Animal trails

[Paul Allen]

On Mon, 30 Nov 2020 at 21:45, Brian M. Sperlongano 
wrote:

> Note that there is already an animal=* tag for describing things related
> to animals, so that probably shouldn't be overridden.  Perhaps a
> combination of foot=no and animal=yes satisfies what we're describing?
>

 Or not:highway=path + note=animal trail.

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

Re: [Tagging] Feature Proposal - RFC - Hazards (mine shaft)

[Paul Allen]

On Thu, 26 Nov 2020 at 21:56, Brian M. Sperlongano 
wrote:

I'm not sure if all mine shafts are hazardous or only some of them, but in
> any case,
>

If the mineshaft is capped in some way, such as a grill, and the cap cannot
be removed without special tools, it's probably safe.  If the mineshaft has
a
sturdy fence preventing access, it's probably safe.  If you can just wander
along and fall down it without realizing it was there, it's probably not
safe.
I suspect the last of those three is the type ael was thinking of.

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

Re: [Tagging] Feature Proposal - RFC - Hazards (animals)

[Paul Allen]

On Thu, 26 Nov 2020 at 16:40, Brian M. Sperlongano 
wrote:

>
> On Thu, Nov 26, 2020 at 2:25 AM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>- Why hazard:animal and hazard:species is needed instead of animal
>>and species?
>>
>> I initially had it as just animal and species as you suggest.  However,
> for hazards along a stretch of road (for example, "moose crossing next 5
> miles"), you would end up tagging a way with animal=moose.  This creates
> ambiguity in the tagging as to whether the road is *for* moose or
> contains a *moose hazard*.  Thus, I invented hazard:animal to explicitly
> draw a distinction.
>

Good point.  A section of way is a moose hazard because a moose might wander
into the road and damage your car.  A different section of way is a child
hazard
because a child might wander into the road and damage your car.

There was me thinking that the hazard was to the child and that the warnings
should be made clear to the child, but the hazard is to the car and and
children
killed are just more roadkill to be disposed of.

More seriously, I don't think the children crossing case should be handled
the
same way.

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

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

[Paul Allen]

On Thu, 26 Nov 2020 at 02:35, stevea  wrote:

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


In the UK we don't have much of a drive-thru anything except maybe some
fast-food outlets of American origin.  Yet all the covid-19 testing centres
I'm
aware of are strictly drive-thru.  As in you're not allowed to turn up on
foot,
because if you're infected you may pass it on to other pedestrians you walk
near.  And they're drive-thru because the swabs are taken in the open.
The swabs are taken in the open because there is far less risk of
transmission outdoors than indoors.


>   I would guess that vaccination centers that are also "drive-thru" are
> likely soon (early 2021?), too.


The same reasons that make the test centres drive-thru apply to
vaccination centres.  Eventually, when we have herd immunity
(one way or another) indoor vaccination may be feasible (but
probably undesirable).  The health workers will be vaccinated
first so they won't be at risk either way, but these places will
be handling large numbers of people and having them all wait
indoors is a good way of infecting lots of people.


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


There is a temporary, short-duration, won't be there for long, test centre
just
popped up in my town because a couple of weeks ago some idiots decided
to celebrate the end of firebreak restrictions by going to the pubs and
ignoring social distancing completely.  Fifty-five cases came of that, and
three hundred contacts have been traced.  I expect it to go away in a few
weeks if the outbreak gets under control.  I'm not confident the outbreak
will be under control very soon because a lot of the celebrants were
shop workers.

But as well as that pop-up test centre because of the sudden surge, there
is an existing test centre.  That's based at the leisure centre that was
converted to an emergency overflow hospital several months ago. I only
found out the test centre was there a few days ago because we try to
keep their locations secret, so I probably won't map it.

Vaccination centres are going to handle more people than test centres
do because nearly the entire population will have to be vaccinated but
only a very small fraction of the population is tested (we ought to be
testing everyone at least once a week, but my country's government
is somewhat incompetent).

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

[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

Re: [Tagging] surface=rock

[Paul Allen]

On Fri, 20 Nov 2020 at 22:35, Graeme Fitzpatrick 
wrote:

> I was having similar thoughts just a couple of days ago, about what to
> call a pile of rocks that a farmer has cleared from, then piled up in, a
> field?
>

In the part of the world I was raised, rocks cleared from fields were used
to build drystone walls.  Solves two problems with one stone.

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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Paul Allen]

On Sat, 14 Nov 2020 at 17:24, Lukas Richert  wrote:

The possible values for any of these subkeys is then yes/backup/no (i.e.
> electricity:battery=no), where *yes *means the device/grid is always
> connected and it is usually (daily?) used. The term *backup* then means
> that the device is only used when the usual device reaches its capacity or
> fails, so it is not always on/connected.
>

I'm not committing to supporting or opposing this scheme, just bikeshedding.
But it's a BIG bikeshed.

It isn't as simple as your tagging scheme makes out.

A photovoltaic system for a house may charge batteries, which come into
play when there is no sun (it's night or it's too cloudy).  There is no grid
connection at all.

A photovoltaic system for a house may provide electricity when it can,
with the grid providing electricity when the photovoltaic system cannot.
There are no batteries involved.

A photovoltaic system for a house not only provides electricity for the
house, it also feeds electricity into the grid (for which the owner gets
a rebate on the bill) with the grid supplying power when the
photovoltaic system cannot.  There are no batteries involved.

As either of the preceding two cases, but with batteries also involved.

Electric vehicles may be used as storage capacity for the grid.  When
they're on charge (usually at night) they may supply power to the
grid to cope with brief increases in demand (people putting the
kettle on during TV adverts).  I don't know if any current systems
do so, but it would be possible for the car to provide household
electricity for a while during a power outage.

I've probably missed something.  Your tagging either needs to
cover less cases or more.

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

Re: [Tagging] Deprecate water=pond?

[Paul Allen]

On Thu, 12 Nov 2020 at 19:30, Joseph Eisenberg 
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 activity is harder.
Possible for retention basins that are still in use.  Mostly
possible for reservoirs, although some reservoirs are
based around natural lakes.  But historical records are
incomplete (and some mappers insist we should never
ever make use of historical data to inform our mapping).

Maybe we need an artificial=yes/no.

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

Re: [Tagging] Deprecate water=pond?

[Paul Allen]

On Wed, 11 Nov 2020 at 15:02, Brian M. Sperlongano 
wrote:

> If the consensus is to go with a limnological definition - I think that's
> fine.  Let's lay out the limnological description of "pond" and "lake" and
> let mappers sort out edge cases based on their best interpretation of the
> definitions provided.
>

I would be happy with that.  However, there may be unknown cases as well
as edge cases - the mapper just doesn't have enough information at the
time of mapping.  In such cases I'd support the wiki stating "Make your
best guess and if new information comes along the tagging can be
edited."


>   That's no different than the wetland= tag in which there are lots of
> edge cases in the real world that are not quite one or the other.  I assume
> there will be cases where "such and such pond" is properly tagged
> water=lake and vice versa, but that's fine if there's a definition to stand
> on.
>

I suspect there will be more ponds named "something lake" than vice-versa.
Property developers have been alleged to rename ponds as lakes just to
make their development seem more attractive.

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

Re: [Tagging] Deprecate water=pond?

[Paul Allen]

On Wed, 11 Nov 2020 at 13:12, Brian M. Sperlongano 
wrote:

> Is it actually desirable to distinguish a "lake" from a "pond"?  If so,
> what is the difference?  Is it just that a body of water is named "XYZ
> Pond" versus "XYZ Lake"?  If so, isn't water=pond versus water=lake derived
> from and redundant with name?
>

It's possible to make the distinction.  It's not clear-cut.  There are
several
definitions which are not entirely compatible with each other, but they
have more similarities than differences.  Edge cases are hard.

See, for example:

https://lakes.grace.edu/ponds-vs-lakes-whats-the-difference/
https://www.lakemat.com/whats-the-difference-between-a-lake-and-a-pond/
https://www.des.nh.gov/organization/commissioner/pip/factsheets/bb/documents/bb-49.pdf
https://www.lakescientist.com/lake-facts/how-lakes-differ/

Most of them agree that lakes have aphotic zones (deep areas that receive
no sunlight, preventing plants from growing there).  But wave height,
uniformity
of temperature, and area of water may play a part.  And, of course, there's
what
the locals call it.

>
> Is there a conceivable scenario where a data consumer or renderer would
> care about the distinction between these two tags?
>

Renderers will probably treat them identically  A limnologist would find the
distinction useful.

There is also a distinction between pools and ponds.  However, since pools
are supplied by a spring or a stream, most can be distinguished by other
water=* occurring in conjunction with them (a lot of the ponds I've mapped
are actually pools).

https://www.askdifference.com/pool-vs-pond/

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

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

[Paul Allen]

On Mon, 9 Nov 2020 at 20:06, stevea  wrote:

>
> For example, you complain that natural=peninsula doesn't render.  So?
> That's not a problem with OSM, it is you assuming that a particular
> renderer is going to display the semiotics you believe it should, when it
> likely does not (exactly as you believe it should).  That doesn't mean OSM
> has "basic cartography features missing," it means you are expecting
> something from a particular renderer it likely doesn't perform or deliver
> as you expect.
>

This is one reason different countries have set up their own renderers
with cartographic styles that align better with the expectations in those
countries.  There even seems to be a Swedish version, although
whenever I've tried it over the past few days it times out.  See
https://openstreetmap.se/

In principle it would be possible to use that, or even your own private
renderer, to develop a cartographic style that does what you want
(provided the objects you are interested in, such as peninsulas,
exist in the database).  If you can achieve something there that the
standard renderer does not offer, you could even submit your
new features to the standard renderer.  Some of your changes might
conflict with other goals but, where there are no conflicts, submitting
working code to do X has a far better chance of happening (and happening
relatively quickly) than adding another wish to an already-long list.

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

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

[Paul Allen]

On Sat, 7 Nov 2020 at 14:26, Brian M. Sperlongano 
wrote:

> I note that "visitation room" is a term that describes "A room designated
> in the funeral home for the deceased to lie before the funeral so that
> people can view the deceased."
>

I hadn't come across the term in the UK, but that could be because I
have little interest in that sort of thing.

Conveniently, it carries no religious connotation.
>

It's funny you should say that. :)  Meaning 3 given in
https://en.wiktionary.org/wiki/visitation is "An encounter with supernatural
beings such as ghosts or aliens."  Meaning 5 is "A punishment or
blessing ordained by God."

It also has the problem that it has "room" in the name but is
intended to be applied to a building which may have several
such rooms.

And then there is the fact that the emphasis is on those
attending to view the corpse even though in some cases
there are no attendees.  I'd go with "place to view
corpses" since the corpse is pretty much guaranteed to
be there even if nobody comes to look at it.

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

Re: [Tagging] How to tag a threshing floor

[Paul Allen]

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 list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a threshing floor

[Paul Allen]

On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer 
wrote:

> Am Do., 5. Nov. 2020 um 13:59 Uhr schrieb Paul Allen :
>
>> This may be a losing battle but I'll point out (once again) that historic
>> is not
>> a synonym for old, disused or repurposed.
>>
>
> I agree, the word "historic" isn't always a synonymon for old , but the
> things that we tag in "historic=*" are not necessarily "historic" in this
> strict sense, they are objects of certain types that are generally seen to
> fit well under the "historic" umbrella.
>

The wiki page gives guidelines as to what counts as historic.


> We do not distinguish "truly historic" wayshrines from "ordinary"
> wayshrines.
>

We currently do not make the distinction because we lack the tagging to
do so.  That is not an argument for not making a distinction.

>
> It is for objects that are of
>> historic interest
>>
>
>
> in the past century the focus of historians has widened, today there are
> many of them who are interested in the general conditions and circumstances
> of the society, much more than looking only at single impactful events or
> acting persons.
>

If we open the scope that widely then we include everything, which is not
useful.

Anything can become of historic interest, it depends how you integrate it
> in the tale ;-)
>

Here are some of the criteria I use:

1) Is there a plaque?  The plaque itself is historic=memorial, even if
it was installed yesterday.  The POI the plaque refers to may also
count as historic=*.

2) Is the POI in guidebooks or tourist information as being where a
significant historic event took place?

3) Many old fortifications, such as castles.

Those aren't comprehensive rules.  I might map something that doesn't
fit them.  I might not map something that does fit them.  They're just
the rules of thumb I apply.

- not just old (how old is old, anyway?) but which are
> in some way historically noteworthy.
>


>
> A threshing floor where a
>> general planned a decisive battle might be of historic interest, an
>> old threshing floor where nothing ever happened but threshing probably
>> isn't.
>>
>
> it will be a testimony of historic agrarian production processes and
> conditions, in any case.
>

As has since been revealed, these threshing floors are protected by a
heritage
organization for that reason.  They aren't historic, though, not unless
something
significant happened there.  The toilet in my house is around 15 years old
and
is a testimony to my bowel movements, but I do not consider it historic.
The
toilet Elvis died on, however...


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

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

Re: [Tagging] How to tag a threshing floor

[Paul Allen]

On Fri, 6 Nov 2020 at 08:41, Jez Nicholson  wrote:

>
> Is there a subtag to distinguish an historical/protected amenity from a
> straight/unprotected one?
>

heritage=* and associated tags.

For Portugal, see https://wiki.openstreetmap.org/wiki/Key:heritage#Portugal

For Spain, see https://wiki.openstreetmap.org/wiki/Key:heritage#Spain

heritage=* and historic=* are handled specially by the Historic Place map.
See, for example,
http://gk.historic.place/historische_objekte/l/en/index.html?zoom=13=40.13318=-8.84788=3=n7098422115=HaHbHcSaHe

Note also that historic=* and heritage=* are independent.  A historic item
may not be protected and a protected item may not be historic, or the
item may be both.

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

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

[Paul Allen]

On Thu, 5 Nov 2020 at 18:56, Joseph Eisenberg 
wrote:

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

https://www.vintag.es/2018/01/living-room-what-we-call-today-was.html

https://blogsurabhi.wordpress.com/2013/03/09/what-is-the-origin-of-the-term-living-room/

Those two aren't entirely independent but each provides details the other
omits.

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

I haven't encountered anyone using it but then I've rarely been in a
situation where such a room was discussed.

When I search for "mourning room" with google i get a few links
to pages actually using the term and a lot of links to pages about living
rooms, sitting rooms and parlours.  Nothing for chapels of rest (or
whatever we end up calling them), just rooms in private houses.
Google search results are personalized, but I can't think of any reason it
would be giving me these particular results.  So it appears that google
still
thinks a mourning room is a room in a private house.

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

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

[Paul Allen]

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

Re: [Tagging] How to tag a threshing floor

[Paul Allen]

On Thu, 5 Nov 2020 at 17:25, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Nov 5, 2020, 13:56 by pla16...@gmail.com:
>
> 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.
>
>
> Those are tagging errors, then.
>
> What would be even correct tag for them?
>

Bear in mind that I indulge in lateral thinking that some might
describe as "outside the box" although others prefer to say
that I am out of my box...

To the extent that some of them are places to pray, then
amenity=place_of_worship seems to fit.  Possibly
needs a subtag.

To the extent that some of them are memorials to road
accidents, historic=memorial + memorial=wayside_shrine.

To the extent that some of them were waymarkers for
pilgrims, marker=wayside_shrine.

One size doesn't fit all since there are (at least)
three different types.

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

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

[Paul Allen]

On Thu, 5 Nov 2020 at 08:46,  wrote:

>
> amenity=mourning
>

Barely acceptable.  It's a verb not a noun, an activity not a place.

amenity=place_of_mourning
>

Acceptable.  Some would say mourning could happen anywhere, and
not necessarily for the dead.  But those people miss an important
fact about English: an arrangement of words may have a
different meaning from the literal interpretation of the
individual words.  Compare with "listed building" which
means a structure (not necessarily a building) which is
under the legal protection of a national heritage
organization.

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.

amenity=viewing_arrangements
>

This is a verb, not a noun.  It is the process by which plans are
made to look at a corpse, not the place where the corpse is
viewed.  In American English it has taken on a meaning
different from a literal interpretation of the individual words,
but we use British English in OSM.

amenity=deceased_viewing
>

That almost works.  But it's a verb not a noun, an activity not a place.
With additional words it could work, but it would be rather inelegantly
named.

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

Re: [Tagging] How to tag a threshing floor

[Paul Allen]

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

Those are tagging errors, then.

>
> Overall man_made=threshing_floor seems OK, though tagging also
> historic=threshing_floor
> for old ones seems fitting.
>

This may be a losing battle but I'll point out (once again) that historic
is not
a synonym for old, disused or repurposed.  It is for objects that are of
historic interest - not just old (how old is old, anyway?) but which are
in some way historically noteworthy.  A threshing floor where a
general planned a decisive battle might be of historic interest, an
old threshing floor where nothing ever happened but threshing probably
isn't.

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

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

[Paul Allen]

On Wed, 4 Nov 2020 at 23:20, Peter Elderson  wrote:

> place_of_mourning then? Just like place_of_worship?
>

I could live with that.

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

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

[Paul Allen]

On Wed, 4 Nov 2020 at 20:50, Tom Pfeifer  wrote:

> I was surprised that this tag is rushed into voting despite the arguments
> against it even here in the tagging list discussions.
>

The proposal itself contains paragraphs indicating it is a work in progress
rather than a finished proposal.  I would have commented but the wiki
is using a black-hole service that has blocked a large chunk of
addresses belonging to my mobile network because some open
proxies were detected.  This is not really ideal for a mobile
service where IP addresses are very volatile.

>
> Let's summarize the criticism first, and look into the alternative
> "mourning room"
>

Not in current use in British English.  And even when it was used, it
generally referred to the room in a house that we now call the
"living room."  See
https://www.vintag.es/2018/01/living-room-what-we-call-today-was.html
Also not really suited to a large, dedicated building with more than one
room
for this purpose.  It's that "room" bit that is the problem.

* Vollis (the proposer) 18 Sep: ""chapel" will be opposed by some for being
> religiously connotated"
>

He was correct.  But it's rare for a proposal to get unanimous approval.

>
> * Peter Elderson 21 Sep: "I have heard mourning chapel, mourning room,
> funeral chapel, funeral room.
> Chapel of rest does not seem right to me"
>

As I understand it, English (British, American or any other variety) is not
Peter's first language.

>
> * Clifford Snow 24 Sep: "Chapel of Rest" sounds to me more like a
> marketing term not something we should be using in OSM.
>

What something "sounds like" to an individual is not a strong determinant of
its propriety.

>
> * Michael Patrick 24 Sep: 'Chapel of Rest' seems to be a dated UK specific
> term.


It's what they're known as in my part of the UK.  So still contemporary in
at least
parts of the UK.


> ... The euphemistic 'Chapel of Rest' is more generically known as 'Viewing
> /Visitation Service',
>

"amenity=visitatation_service" makes even less semantic sense than
"amenity=mourning_room."  It's not a term I've encountered, anyway.


> * 27 Sep: 'Chapel of Rest' seems to be one of those terms like 'Take the
> goat to the butcher...
>

That sentence no sense makes.


> * 28 Sep: since OSM is an international project, my practice is to make it
> as easy as possible for non-native English users.
>

That is why editors have translations of their presets.

>
> Indeed, the proposed value contains 'chapel' which is biased to christian
> religion.

It might be used in British English, however that is biased itself for
> having
>
Christianity as a cultural background.
>

Congratulations.  You have successfully argued that we must change from
using British English to the language of a country which has no
religious cultural background whatsoever.  Offhand, I can't think of
such a country but why should that stop us?

"Chapel of rest" is an euphemism that avoids death-related terminology,
> butmight be mistaken for a chapel where somebody could rest along a hiking
> or pilgrim route.


Except that the correct name for such a chapel is "chapel of ease" not
"chapel of rest."


> OSM is a map for the whole world, and it does not improve acceptance when
>
a bunch of old white males (such as myself) chose a biased term for a
> feature
>
that naturally exists in other cultural/religious contexts as well.


Do other religions have such places?  If so, what do they call them?  And
can we then abstract a neutral name from that?


> To close with an alternative, "mourning room" would be a neutral
> alternative from my perspective, reflecting the process of mourning which I
> suppose exists in all cultures.
>

I object to room being applied to a building which may have many such rooms.
I'd have less of a problem with amenity=mourning.

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

Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

[Paul Allen]

On Wed, 28 Oct 2020 at 12:14, Martin Koppenhoefer 
wrote:

>
> these areas are usually not access=no, there will be no parking / stopping
> signs, but otherwise these are "normal" areas where other activities (like
> walking, playing with a ball, etc.) will take place. Think of it as part of
> the building regulation picture.
>

Perhaps true of such areas set aside for firefighters.  But there are other
areas used by other emergency services.  In the UK there are small parking
areas set aside for use by police vehicles.  Ostensibly where they wait
for something to happen, probably just so they can have lunch.  Here's
one: https://goo.gl/maps/76Yv2vKKhpSnuDMd6  It's a bit weird because
it's parking for police patrol vehicles and also a turning area (it's not
specified who can use it, but it is an important part of a local bus route
where the bus does a 180-degree turn with passengers still on it).

It probably doesn't fall under emergency=* even though only vehicles
of one of the emergency services can park there.  I tagged it as
private parking, years ago, for lack of anything better.  If whatever
we come up with for the fire service can accommodate this then
I'll retag it.

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Paul Allen]

On Sat, 24 Oct 2020 at 15:51, Jeroen Hoek  wrote:

> On 24-10-2020 15:58, Paul Allen wrote:
> > I don't see any valid reason for wanting to de-emphasize them and you
> > do not attempt to provide one.  Maybe there is a valid reason but I
> > don't see it.
>
> Thanks for the feedback; we'll clarify that point. From the proposal:
>
> > Furthermore, this type of parking may have different rendering and
> > navigation needs compared to other types of parking (see below).
> This is mainly about preventing the visual clutter of blue P's that are
> the result of tagging amenity=parking without any parking sub-tag or an
> unsuitable one.


Ah, so you want to tag for the renderer.  Firstly, the renderer could
choose not to show small car parks below a certain zoom level,
which would prevent clutter automatically and is preferable to
mappers tagging "In MY opinion, this car park is unimportant."

Street-side parking usually isn't of interest until you
> are in the area or are orienting yourself for a trip to visit a POI
> nearby.


If you're not in the area but expect to go there and are looking
for parking, ALL parking areas are of potential interest.


> Unlike dedicated parking facilities (like a parking lot or
> parking garage), the scale of these is much smaller, yet they are also
> much more ubiquitous.
>

And people park in them.  Which kind of defeats any argument that
they are of lesser importance.  Often they are free, although of
limited duration, which can make them preferable.  Often they
are nearer to a POI or group of POIs than the larger car parks.
Often such parking areas are full when large car parks are not.

>
> Parking=street_side allows for renderers to de-emphasize these areas
> (for a few suggestions, please see the proposal under 'Rendering'),
> without sacrificing the findability of dedicated parking lots/garages
> (especially if these lack capacity information).
>

So tagging for the renderer because, in your opinion, these car parking
areas are unimportant.

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Paul Allen]

On Sat, 24 Oct 2020 at 15:25, Janko Mihelić  wrote:

>
> These two variants are mapping for the renderer,
>

Incorrect.  They are approximations to reality.  Everything we map is
an approximation to reality, one way or another, because the map is
a representation.  That they happen to render in a way that is a
closer representation to what is there is a bonus.


> and both add false data.
>

The first one can be interpreted that way.  The second cannot.


> The first one extends the parking over half the road.
>

Yes.  That's what the data purist objected to.  But for the average human
data consumer, that is not apparent.

You may object to it somehow being tagging for the renderer (it isn't)
but it is relying on one error in representation hiding a different
error in representation.  The renderer doesn't show the true width
of the carriageway - if it did then mapping the actual extent of
the parking area would result in it abutting the carriageway.
However, a different error in representation results in the
carriageway being rendered over the parking area.

The result that is rendered better represents reality on the
ground and what an ordinary user expects to see.  But you
seem to object to maps that match what a human user would
expect to see.


> The second creates a service road area over half the road. There is no
> service road area there,
>

Yes there is.  It's a very wide, very short service road connecting the
carriageway to the parking area.  You're trying to pretend it isn't there
and that there is a void between the two.


> you are just trying to connect the parking to the road so it looks nice on
> the map. And it does look nice, but it's false data.
>

It is absolutely true data.  It is the same surface as the carriageway and
the parking area with only lane markings to delineate it.  It looks rather
ugly, not nice.  But it is absolutely true.  Are you saying there is no way
to drive from the carriageway to the parking area?  If not, there is
something
connecting the two.  That connection is a very wide, very short service
road.  It is you who is insisting on false data by pretending there is no
road surface between carriageway and parking area.

If we want to describe how you get onto street side parking, and it's not
> obvious, we could use additional tags, like parking_entrance_direction=*.
>

Let's tag everything so that NOTHING renders and the user has to use the
query tool to find out what is there.  Apart from the fact that no human
map user is going to see any clue about the parking entrance direction,
now will the human user know that the entrance extends the whole length
of the parking area.


> Street side parking is a very different parking area from a big enclosed
> surface parking. Some people may find it hard to park there because you
> back up onto traffic,
>

The two examples I gave have the parking parallel with the carriageway, so
there is no backing up involved.


> and they may want to avoid parking there. This information is definitely
> very useful.
>

If that information is very useful, why are you proposing tagging it in a
way
that is not only not rendered but doesn't give any clue about it if you use
the
query tool?

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Paul Allen]

On Sat, 24 Oct 2020 at 14:35, Jeroen Hoek  wrote:

> On 24-10-2020 15:11, Paul Allen wrote:
> > As rendered it appears you need a skyhook or
> > a cargo helicopter to park.  Not good.  You're probably as unhappy with
> that
> > method of tagging as I am.
>
> True, but the same goes for lots of points-of-interests and other mapped
> parts of the urban landscape; e.g., patches of grass, shrubs, benches,
> bicycle parking areas, etc. In all these cases mapping the exact area
> results in a neat map that makes sense for orientation as well as
> finding parking spaces for motorists in the neighbourhood.
>

Car parking areas are, I feel, in a different category to benches.  You
walk to a bench and can infer that if a bench is present you can
walk to it unless there are barriers.  With car parking areas you
need actual routes.  There are off-carriageway parking areas
where the entry might be from either of two parallel streets
(or both) which is unclear if we adopt helicopter parking
tagging.  Fixing the helicopter tagging also fixes the
ambiguities that seem to be the only justification for
your proposal.



> While being able to route exactly onto a point-of-interest is valuable
> in some cases, for the use case of this proposal I would say that it is
> not as relevant.


In which case, I don't see any use case for your proposal at all.


> Besides, if someone really wants to navigate to a
> specific mapped street-side parking area, their router will tend to
> route to the nearest point it can get too, which more often than not
> will be right in front of the parking area.
>

And sometimes isn't.  Two parallel roads.  I've seen this case somewhere,
but I can't remember where.  Worse, the nearest point a router could get
to is the road that doesn't have access to the parking.

>
> This proposal provides tag-values for a common type of parking area
> already mapped in great quantities, and hard to ignore at a certain
> level of detail. It gives mappers a way to map them without bending
> existing tags (e.g., parking=surface, parking=layby),


I agree, it's not a layby.  Technically, cars do park at a layby but I
don't think of a layby as being a car parking area or vice versa.
It's certainly not parking=surface which applies (by default) to
any car park that isn't either multi-storey or underground.

What you haven't convinced me of is that it isn't amenity=parking.
By any rational definition it is.  I know of off-carriageway parking
which is controlled by a county council and has a ticket
machine.  The county council lists it as a car park, one
of three car parks in the town, and makes no distinction.

and it eventually
> gives renderers a way to de-emphasize them (the proposal has a few
> suggestions) compared with the more 'high-value' parking facilities like
> large capacity public parking=surface|multistory|underground.
>

I don't see any valid reason for wanting to de-emphasize them and
you do not attempt to provide one.  Maybe there is a valid reason
but I don't see it.  It's a place to park.  Somebody looking for
a place to park near to their objective will be just as interested
in off-carriageway parking as an ordinary car park.

If applied consistently, this proposal will increase the relevance of
> parking areas that really are parking=surface|layby|etc.
>

You wish to increase the relevance by de-emphasising.  I don't
see how that works.  Maybe we could increase the relevance
even more by not mapping them at all - the ultimate in de-emphasis
and therefore the ultimate in relevance.

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Paul Allen]

On Sat, 24 Oct 2020 at 12:42, Supaplex  wrote:

I would like to invite you to discuss a proposal for "parking =
> street_side" for areas suitable or designated for parking, which are
> directly adjacent to the carriageway of a road and can be reached directly
> from the roadway without having to use an access way:
> https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side
>

I don't think a new parking=street_side is necessary for off-carriageway
street-side parking.

The example image you give in the sub-section "Tagging"
https://wiki.openstreetmap.org/w/images/thumb/b/b8/Parking-render-carto.png/500px-Parking-render-carto.png
is (in my opinion) not a good way to use existing tagging.  The parking
areas
are not routeable (not a big problem unless somebody wants to route
to a named parking area).  As rendered it appears you need a skyhook or
a cargo helicopter to park.  Not good.  You're probably as unhappy with that
method of tagging as I am.

Connecting it with an invented service road also misrepresents the true
situation.

But there is another way of doing it.  A way which comes in two variants,
either quick-and-dirty or purist.

Variant 1. Extend the parking area out to the roat it is on.  Pretty much as
you handled the lay-by example.  As far as rendering goes, where most
carto renders the road on top of the parking area, it represents things
as a way that matches reality.  Here's one I did years ago.

https://www.openstreetmap.org/?mlat=52.08560=-4.65830#map=19/52.08560/-4.65830
Streetview for comparison:  https://goo.gl/maps/R7Q1RUWGziLaMemW8

A data purist on the list objected to that.  The rendering is a good
representation of reality but if a data consumer were to look at the
data rather than the rendering then he or she would assume the
car could be parked perpendicular to the carriageway with half
the car blocking traffic.  So for purists...

Variant 2.  Map the precise boundary of the parking area.  Connect it
to the carriageway with highway=service + area=yes.  This results
in rendering that is an even better (if slightly uglier) representation of
reality at the expense of extra effort.  Here's one I did a few weeks
ago to test the idea.

https://www.openstreetmap.org/?mlat=52.08268=-4.66461#map=19/52.08268/-4.66461
Streetview for comparison: https://goo.gl/maps/YHTv9dDvSbm6DL1A8  The
streetview is somewhat misleading as recent aerial imagery shows clear
surface marking delineating the boundaries.  That's also a weird example
because some of it is off-carriageway and some on-carriageway (turn 180
degrees in streetview and move forward to see), a situation your proposal
doesn't cater to.

I don't see your proposal achieving anything we can't already do and
doesn't keep the data purists happy, either.

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

Re: [Tagging] Feature Proposal - RFC - Artificial

[Paul Allen]

On Wed, 21 Oct 2020 at 15:00, Matthew Woehlke 
wrote:

> On 21/10/2020 00.57, Robert Delmenico wrote:
>
> Also:
>
> > The word 'Man' in the Old English sense 'mann' had the primary meaning
> of "adult male human"
>
> Citation needed, particularly as the other thread contains a statement
> which directly contradicts this.
>
> It was I who made that statement.

https://en.wiktionary.org/wiki/man#Etymology_1

See also the usage notes on that page for a little more of the
etymology (it clarifies aspects that are ambiguous in the etymology
ifself).  It also gives a link to the Old English "mann" (from which
"man" derives) that makes clear that the primary meaning of
"mann" in OE was person/human and that it was rarely used
to mean adult male.  https://en.wiktionary.org/wiki/mann#Old_English

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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Paul Allen]

On Mon, 19 Oct 2020 at 14:04, Dave F via Tagging 
wrote:

I mean, *everything* is either man made or natural.
>

Unless you want to argue that humans are supernatural or unnatural,
humans are natural.  Therefore anything humans make is natural,
just as beaver dams and wasps' nests are natural.

If you wish to argue that humans are a special exception then
everything we make is man_made, so buildings, bridges, parks,
gardens, etc. is man_made.

OSM tagging is not a good candidate for cladistic taxonomy.  There
is too much multiple inheritance to even consider that type of
taxonomy.  Houses are buildings, which are man-made, houses
have walls and walls are built, so man_made=house and building=wall
Except humans build walls, so man_made=wall.


>   We really should come up with more specific, accurate key tags.
>

Perhaps in some cases.  Where such need arises it happens, such as
with healthcare.

On balance, moving to human_made or artificial is a lot of pain without
any gain whatsoever with regard to map accuracy in order to appease
the feelings of those who do not understand etymology.  Are we
to next propose persontoric=* because those who do not understand
etymology object to a supposed gender bias in "historic"?

That the proposer profusely thanks those who put forward
arguments against the change whilst apparently ignoring
those arguments does nothing to persuade me of the
merits of his/her case.  It smacks of the so-called
"non-confrontational" tactics that might better be
called "passive confrontational."

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

Re: [Tagging] railway=station areas

[Paul Allen]

On Sat, 17 Oct 2020 at 10:03, Martin Koppenhoefer 
wrote:

buffer kisser (not sure this term exists in English)
>

I've not encountered it (but there's a lot I don't know).  This WIkipedia
article
https://en.wikipedia.org/wiki/Railfan doesn't mention it either.  One of the
few mentions I've found of it is at
https://www.trainorders.com/discussion/read.php?6,1289802

All of which is going far off topic.

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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Paul Allen]

On Thu, 15 Oct 2020 at 09:38, Martin Koppenhoefer 
wrote:

>
> I fear in „human“ there is still a man, even in every woman there‘s a man,
> as in female there is a male. Overall it looks as if English is not
> suitable for gender neutral language,

everything refers back to men. I propose to use German as the language for
> tags.
>

Hahahaha.  That would resolve "man made."  By replacing "made."


> It might look like an impossible endeavor at first glance to retag those
> millions or billions of objects, but if you dig deeper you will find that
> many tags are already more German than English, so ultimately it wouldn’t
> be as much change as it may sound initially.
>

 It only needs a little re-tagging.  Simple.

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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Paul Allen]

On Thu, 15 Oct 2020 at 01:57, Robert Delmenico  wrote:

>
> I also understand that generally speaking the use of man_made is
> commonly accepted as a gender neutral term, but in reality it has been
> adapted that way due to past practices of gender bias.
>

You are correct that there was a change of usage.  In Old English "mann"
meant "human" of any gender, with "wer" meaning "adult male."   When
"wer" fell out of use, "mann" was used for both "human" (of any gender)
and "adult male."

So you are wrong to imply that some sort of denial of gender bias
retrofitted "man"
as a gender-neutral term.  it always was a gender-neutral term, although it
has
latterly taken on an additional meaning.

The references you give in your proposal discuss the problems with
introducing such a change to tagging.  They point out that editors and
applications often hide raw tags from mappers anyway.  They point out
the headaches in changing established tagging without any benefit to
the map itself.

I doubt this change would be even one small step for a human, let
alone one giant leap for humankind.  Don't have a cow, wer.

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

Re: [Tagging] Should the tag proposal process force voters to vote for an option?

[Paul Allen]

Apologies for previous incomplete message.   I hate the keyboard on
this laptop, which seems to interpret simultaneous depresion of
some combination of control, shift and function keys on the left
as "send mail."  Grrr.

On Mon, 12 Oct 2020 at 23:23, Andrew Harvey 
> wrote:I wrote about changing from a for/against vote to a pick your
> preferred option at
> https://www.openstreetmap.org/user/aharvey/diary/394419
>


>  Interested to hear what others think about this.
>

There are inherent problems when using first-past-the-post voting with
more than two political candidates, and these have been covered
extensively in the field of political science.

Assume somebody who favours X over Y adds Z (that is similar
to Y) in an attempt to split the vote for Y.  It could turn 4,6 for X,Y
into 4,3,3 for X,Y,Z.

Assume Y is a compromise between X and Z.  Those who want
X could live with Y.  Those who want Z could live with Y.  The
vote ends up as 4,3,3 for X,Y,Z, so X wins even though only
4 people wanted X and 6 people did not want X and Y would
have been a compromise acceptable to all.

There are many other problems, particularly if bad actors
are involved.  You can get around some of them with
schemes like single transferable vote, but even those schemes
have problems.  The scheme with fewest problems is a
Condorcet method.  Even that is not without flaws, but
the biggest can be eliminated by saying that if you get a loop
you have a completely new vote.

It's a lot of work to make this fly.  Maybe you should put propose
a list of options and we'll vote on it...

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

Re: [Tagging] Should the tag proposal process force voters to vote for an option?

[Paul Allen]

On Mon, 12 Oct 2020 at 23:23, Andrew Harvey 
wrote:

> I wrote about changing from a for/against vote to a pick your preferred
> option at https://www.openstreetmap.org/user/aharvey/diary/394419
>
> Interested to hear what others think about this.
>

There are inherent problems when using first-past-the-post voting with
more than two political candidates, and these have been covered
extensively.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a government job centre

[Paul Allen]

On Sun, 11 Oct 2020 at 22:44, António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

> In Portugal, the Government's employment centre gets you a job and gives
> you professional formation. It has  a list of all the companies seeking
> for workers and distribute them based a very specific system.
>

That's about the same as the UK.  There's a website listing available
jobs which you can use whether you're employed or unemployed and the
lists of jobs in the centres themselves have largely disappeared.

The money that comes from the Government to people without job is given
> via Social Security, it's not handed by the employment centre.


That's how it used to be in the UK.  The Benefits Agency used to
handled the money side of things.  But it was almost always in the
same building as the Jobcentre.  Then the government realized
it could almalgamate the two, so the Jobcentre became the
Jobcentre+.

Given these arguments, I'm getting more inclined to use
> office=government + government=employment_centre
>

I like employment_centre more than employment_agency for
the government-run endeavour.

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

Re: [Tagging] Tagging a government job centre

[Paul Allen]

On Sun, 11 Oct 2020 at 19:46, António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

Although an employment centre is not an office that governs, like Tom
> Pfeifer wrote, (nevertheless we could argue they govern/regulate the
> unemployed and the work market)
>

That depends how you define government.  Is the department that collects/
enforces income tax government or not?  I'd say it is, not just because it
acts
to enforce and not just because without the monies it collects the
government
could not operate.  If employing civil servants to take money from people is
government then so is employing civil servants to give money to the
unemployed.


> it operates very differently from an employment agency (the difference in
> the name is not incidental)
>

The day I can claim unemployment benefits from employment agencies
is the day I look very carefully at which of them is going to give me
the most money before I choose to sign up with one.


> and I think that should be stated or even differentiated in the wiki.
>

I think we got deflected by considering Jobcentres (or whatever they're
called elsewhere) to be employment agencies.  That is only part of
what they do.  Nevertheless, office=government  +
government=employment_agency may be as close as we're going to get
without many weeks of arguments on the list.

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

Re: [Tagging] Tagging a government job centre

[Paul Allen]

Sigh.  Managed to hit some keystroke combination on this damned
laptop that triggered a send.  Now what I intended to write...

On Sun, 11 Oct 2020 at 02:16, António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

Anyway, maybe the wiki could be updated to reflect the entire scope of
> the office=employment_agency
>

Perhaps.  With qualifications and exceptions.  In the UK there were
differences between Jobcentres and employment agencies.  Those
differences became more pronounced when Jobcentres turned
into Jobcentres+ (or is that Jobcentre+s?).

Employment agencies are happy to have you on their books even if you are
currently employed and many will notify you by e-mail if suitable
opportunities
arise; Jobcentres deal with the unemployed who are looking for work.

If you sign up with an employment agency you do not receive any
money for doing so; signing up with a Jobcentre is how you
qualify for unemployment benefit.

[Now the new/fixed stuff]

Jobcentres merged with the Benefits Agency (which handled benefits
other than unemployment benefits) and so pay out money for more
than just unemployment; employment agencies don't pay out any of
those benefits either.

Jobcentres are staffed by civil servants and are part of the
Department of Work and Pensions (a branch of government);
employment agencies are non-governmental.

I'd say UK Jobcentre+s are definitely office=government rather
than office=employment_agency because they ARE government
offices and do things that employment agencies do not.
I'd settle for government=employment_agency even though
they do more than just that.

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

Re: [Tagging] Tagging a government job centre

[Paul Allen]

On Sun, 11 Oct 2020 at 02:16, António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

>
> Anyway, maybe the wiki could be updated to reflect the entire scope of
> the office=employment_agency
>

Perhaps.  With qualifications and exceptions.  In the UK there were
differences between Jobcentres and employment agencies.  Those
differences became more pronounced when Jobcentres turned
into Jobcentres+ (or is that Jobcentre+s?).

Employment agencies are happy to have you on their books even if you are
currently employed and many will notify you by e-mail if suitable
opportunities
arise; Jobcentres deal with the unemployed who are looking for work.

If you sign up with an employment agency you do not receive any
money for doing so; signing up with a Jobcentre is how you
qualify for unemployment benefit.

Jobcentres merged with the Benefits Agency (which handled benefits
benefits such as discretionary gran
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging