Re: [Tagging] Coach parking

[Andy Townsend]

On 09/06/2023 10:52, Greg Troxel wrote:

Anne- Karoline Distel  writes:


I came across a case where someone had added name=coach and name=car
to amenity=parking, which is obviously not how we do things [snip]

I can't find it either.


https://taginfo.openstreetmap.org/keys/name#values allows you to search 
within values, and entering "coach" in the search box at the right finds:


https://taginfo.openstreetmap.org/tags/name=Coach%20Park#overview

https://taginfo.openstreetmap.org/tags/name=Coach%20Parking

https://taginfo.openstreetmap.org/tags/name=Coaches

https://taginfo.openstreetmap.org/tags/name=Coach%20Stop

and also

https://taginfo.openstreetmap.org/tags/name=car#overview

which seems to be commonly used as a name for (presumably coach) parking 
in France


Some of those (especially "Coach Park") are likely to be entirely valid 
names, but some may not be.


Best Regards,

Andy




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

Re: [Tagging] Coach parking

[Andy Townsend]

On 09/06/2023 21:21, Anne-Karoline Distel wrote:

Since these are all descriptive values in the name which we are not
supposed to do, I don't understand what you're trying to say. 



Two things really - one was in case one of them was your "name=coach" 
that you thought that you've seen; the other was that anyone seeing one 
of these near them (like https://www.openstreetmap.org/way/118443549 
near me) might ask themselves whether more tags might be helpful.


Best Regards,

Andy



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

Re: [Tagging] Adding 'flood' as value to the key 'hazard' (to be used in combination with the tag boundary=hazard)

[Andy Townsend]

On 15/06/2023 16:59, Cornelia Scholz via Tagging wrote:

Dear all,

I would like to propose to add*'flood'* as value to the *key 'hazard'* 
(to be used in combination with the tag*boundary=hazard*).



...
What already exists is the key flood_prone 
=*which is mainly 
for roads that are known to be flooded frequently. The mapping 
descriptions include instructions for mapping flood prone waterway 
crossings, bridges, and highways. However, it is not intended to tag 
areas, which would be covered by the proposed new tag of hazard=flood 
for areas tagged as boundary=hazard.


Hello,

flood_prone=yes on areas does actually get a reasonable amount of use:

https://overpass-turbo.eu/s/1w7k

(about 3000 worldwide)

https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dhazard has much less use

https://overpass-turbo.eu/s/1w7l

and seems so far been restricted to "fixed" areas such as (clicking at 
random)


 * A shooting range: https://www.openstreetmap.org/way/1149857565
 * An explosives depot: https://www.openstreetmap.org/way/1166217800

hazard=flooding is used, but mostly on hghways:

https://overpass-turbo.eu/s/1w7m

I'd suggest exploring taginfo (and the overpass links from it) to see 
what keys and values are in use already.  There may well be a use case 
for some new key/value, but I'm not convinced yet.  See e.g. 
https://taginfo.openstreetmap.org/keys/hazard#values and filter the 
various values.


Is "OpenHazardMap" an actual map or just a wiki page?  I ask because I 
live somewhere where river flooding is a thing (although usually of very 
low impact in terms of people or property) and I have created maps of 
"what is currently flooded" based on current measured level and previous 
observations.  See 
https://www.openstreetmap.org/user/SomeoneElse/diary/398374 .


Best Regards,

Andy




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

Re: [Tagging] Adding 'flood' as value to the key 'hazard' (to be used in combination with the tag boundary=hazard)

[Andy Townsend]

On 15/06/2023 20:47, Jez Nicholson wrote:
Whilst it is a great idea to capture local knowledge about flooding, 
especially where it is currently not available, I am concerned that 
this doesn't have on-the-ground verification.


I don't think that anyone has suggested that - at least not in this thread?

The original email said "The location and extent of these hazard areas 
is often well known by local communities with knowledge of past events."


When I talked about "what is currently flooded based on current measured 
level and previous observations"I meant exactly that - recording that 
when a river level at a known point reads X, land at Y (in the vicinity 
of X) will also be flooded.




Flood risk areas are predictions generated via modelling software and 
it depends on which software you use, and the quality of the input data.


Indeed - the Environment Agency in the UK (and other agencies elsewhere) 
make extensive use of this sort of model, but I suspect that mapping 
this sort of thing goes  bit beyond what can usefully done within OSM, 
though of course it can be combined with OSM data by a data consumer to 
create "risk maps".




The current hazardous areas get away with it by mapping areas marked 
out by signage. Sure, the signs may have been placed following 
predictions, but they are physically there to be seen.


I suspect that this isn't true for all "boundary=hazard" in OSM at the 
moment (picking one at random, the signage for 
https://www.openstreetmap.org/way/500428513 and the wider 
https://www.openstreetmap.org/relation/15680620 doesn't look especially 
extensive - see 
https://www.abc.net.au/radio/programs/australia-wide/australia-wide/13490888#:~:text=Wittenoom%20is%20the%20largest%20contaminated,site%20in%20Western%20Australia%27s%20Pilbara. 
)


Best Regards,

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

Re: [Tagging] How to Tag Steps in a Bridleway

[Andy Townsend]

On 28/04/2024 15:19, Peter Neale via Tagging wrote:
A local Public Bridleway has a few (3, 4 or 5 from Aerial imagery) 
steps going down before it passes under a road bridge, and a similar 
number up again on the other side.


How can I best tag this? According to the wiki, "highway=steps" seems 
to be *an alternative to*, not *a qualification of * 
"highway=bridleway". I don't want to mislead consumers by breaking the 
bridleway, but I don't want cycling consumers to be unaware of the 
fact that there are a few steps to descend / ascend, which may require 
a dismount.


Assuming we're talking about something that's signed as a "Public 
Bridleway" in England and Wales*, then at the most basic level there are 
two tags to consider:


 * highway=steps
 * designation=public_bridleway

The first of those says that there are some steps.  There's no other way 
of doing that; there are steps, so highway=steps it is. There are of 
course lots of other tags that can add information to the physical steps 
(how many, which way is up, is there a bicycle ramp, etc.)


The second of those covers the legal "this is a public bridleway" part, 
as per 
https://wiki.openstreetmap.org/wiki/Tag:designation=public%20bridleway?uselang=en-GB 
.  You can also add "foot", "horse" and "bicycle" tags too as a helper 
to data consumers that may not understand "designation".


There are plenty of designated bridleways with steps on them - see 
https://overpass-turbo.eu/s/1KNx .


Best Regards,

Andy

* for Scotland see 
https://wiki.openstreetmap.org/wiki/Access_provisions_in_the_United_Kingdom#Scotland 
and for Northern Ireland see 
https://wiki.openstreetmap.org/wiki/Access_provisions_in_the_United_Kingdom#Northern_Ireland 
.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to Tag Steps in a Bridleway

[Andy Townsend]

On 28/04/2024 23:09, Graeme Fitzpatrick wrote:

... how do horses handle the steps in the bridleway?


better than cyclists :)

Lots of historic bridleways in hilly areas in England are quite steep, 
and often steps have been added for foot access to stop hikers sliding 
down the slope. Sometimes there's a sloped part alongside; sometimes 
there isn't. I've added "horse_scale" in some cases locally (see 
https://overpass-turbo.eu/s/1KQS ) although that may not really be 
relevant here (MK is famous for concrete cows rather than horses of any 
type).


Best Regards,

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

[Tagging] Difference between "yes" and "designated" in access tags (was: Re: How to Tag Steps in a Bridleway)

[Andy Townsend]

On 29/04/2024 16:22, Jass Kurn wrote:


On Mon, 29 Apr 2024 at 10:03, Peter Neale via Tagging 
 wrote:


It is "bicycles=yes" and not "bicycles=designated" because, for a
bridleway https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbridleway
"Cyclists also have a right, unless the local authority makes
orders to the contrary ...The local authority is not obliged
to ensure suitability for bicycles, unlike for foot or horse users."#


Disagree with that, I always map a Public Bridleway as 
bicycle=designated. Cyclists have a statutory right to use these ways, 
which should be meaning behind the designated. The fact there is no 
requirement to maintain a Public Bridleway to a standard acceptable to 
all cyclists, does not impact on the right to use the way. It's a 
secondary matter that does not fall under "access". Or looking at this 
in another way. The fact a Public Footpath does not have to meet 
standards that would allow ALL pedestrians to use them, but does not 
mean a public footpath should be tagged foot=yes



In terms of access rights*, I've always thought that (in England and 
Wales**) "yes" and "designated" mean both "a legal right to access", as 
opposed to "permissive" that means "you can go there, but that right can 
be removed by the landowner whenever they wish".  What would you say the 
difference between "yes" and "designated" are?


Best Regards,

Andy

* ignoring the use of "designated" on "highway=path" etc. where it is 
used to say that a path is really a footway or a cycleway.


** and also ignoring countries such as e.g. Scotland, Sweden, Finland et 
al where you have a legal right of access on foot across most areas, 
with some caveats.


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

Re: [Tagging] Difference between "yes" and "designated" in access tags

[Andy Townsend]

On 30/04/2024 14:51, Jass Kurn wrote:
Need to point out for others reading this than I am in England, and 
influenced by what I believe was likely the original intent of these 
tags, that is mapping of the "English/Welsh, rights of way"


I've always treated " foot|bicycle|horse=yes, as a means of showing I 
confidently believe with evidence available that access is allowed. 
Done with regard to the defaults for tag (eg don't add when 
highway=footway)


Designated & Permissive allow me to tag in more detail if evidence is 
available to support tags
I use ''designated" for where there is a demonstrable "right of 
access" eg Specific recognisable signage, online usable data, etc, 
which demonstrates a legislative or contractual, rights of way.
I use "permissive" for the common British situation of ways being 
provided on private land, and where the owner has displayed signage to 
inform the public that the way is "Permissive" and not an 
English/Welsh "Public Right of Way". (This should block the 
private way becoming a "right of way" through continuous use.)


Issues I have are separating "legal right of access" and the ability 
to actually use the way. A common problem with British/Welsh rights of 
way which do not have to be managed to to allow all foot users



Thanks to all who replied.  For what it's worth I can see why people 
would use "designated" if, for example, a cycleway was clearly built 
with foot, cycle and horse usage in mind; it would make sense to tag 
that as "designated" for all three modes. However, this only makes sense 
when the "legal right of way" for that mode is also "yes".  Problems 
occur when something is clearly designated for bicycle use but access is 
only permissive (there are sections of the UK's National Cycle Network 
in England and Wales like this).


With a data consumer hat on I treat "yes" and "designated" the same, and 
rely on other tags (the relevant PRoW tags for England and Wales, 
Scotland, and Northern Ireland) to indicate rights of way.**


Best Regards

Andy

** which leaves (for me, still wearing my "data consumer" hat) Ireland, 
which seems _complicated_: 
https://www.lawsociety.ie/Solicitors/knowledge-base/Practice-Notes/rights-of-way-in-rural-areas
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

[Andy Townsend]

On 02/06/2020 13:48, Volker Schmidt wrote:



On Tue, 2 Jun 2020 at 09:04, Daniel Westergren > wrote:


I think the reason that this is so messed up because of the
desire to tag according to function.   A trail/path can have
many users/functions, but it's still a dirt path.


Right. But is there another way? Can we tag dirt paths/wilderness
paths/forest paths/mountain paths with another main tag?

No you cannot inroduce another main tag, because of the existing stock 
of "path" 8.7 million and "track".(18.7 million). This would only add 
additional confusion with mappers and an enormous burden on renderers 
and routers


Can we somehow "enforce" additional tags for physical
characteristics that will tell what this path|footway|cycleway
actually looks like?

We have no way to "enforce" anything in OSM. But, as we do have the 
necessary tags (maybe to many different ones, but they all are in 
use.and we need to reamin backaward compatible in view of the 
enourmous numbers). What we can do and need to do is to improve the 
description of the various existing tagging options in the wiki 
(without touching their definition)


To be honest, I'd expect that most OSM contributors (new and old) don't 
look at the wiki at all.  If you want to influence how people tag 
things, it'd be more effective to try and ensure that editor presets in 
the commonly-used editors match whatever the community consensus is 
(although after 116 messages about this last month on the tagging list, 
I'm not sure that there is a consensus about even what the problem is).


Best Regards,

Andy




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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Andy Townsend]

On 06/06/2020 16:18, Phake Nick wrote:



在 2020年6月6日週六 11:03，Warin <61sundow...@gmail.com 
> 寫道：



As a general tourist I would have no interest in traveling along a
railway route here nothing remains of the railway.


OSM is not *only* for general tourist.

I bet even a general tourist would be interested if they could be 
assured that a route was flat :)


Best Regards,

Andy


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

Re: [Tagging] Is there any case of valid numeric addr:housename - for example addr:housename?

[Andy Townsend]

On 30/06/2020 14:06, Mateusz Konieczny via Tagging wrote:
We have 15000 addresses such as addr:housename=3 ( 
http://overpass-turbo.eu/s/VBS )


Is there some chance that any of them is valid? Because it seems to me 
that

editors should complain about addr:housename with just numbers.


Any?  Quite possibly:

https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/

(especially "A building name won't also be a number").  Pretty much 
every edge case exists somewhere.


I doubt that those 15k are all valid though.

Best Regards,

Andy



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

Re: [Tagging] site relations for city walls?

[Andy Townsend]

On 12/07/2020 20:13, Taskar Center wrote:


Why is the relation type on the Berlin Wall a “collection” rather than 
“boundary”?


Over its history as an object in OSM it's had a whole variety of tags.  
Different people have said "This is important!  We should render it!" 
and have sometimes tried to do that by adjusting the tags until they 
found something that rendered.  Other people have tried to change tags 
to better reflect the current reality. 
http://osm.mapki.com/history/relation.php?id=6651797 tells the story.


Personally, I don't think that "boundary" would be a good relation type 
for it because it isn't one - it's the route of a former barrier within 
a boundary.  Compare 
https://www.openstreetmap.org/relation/6651797#map=19/52.51616/13.37698 
with the suburb boundary just to the west.


Best Regards,

Andy



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

Re: [Tagging] Waterway equivalent of noexit=yes?

[Andy Townsend]

On 18/07/2020 19:41, Alan Mackie wrote:



On Sat, 18 Jul 2020 at 19:09, Paul Allen > wrote:


On Sat, 18 Jul 2020 at 18:53, Tod Fitch mailto:t...@fitchfamily.org>> wrote:


What I’d like is one or two tags to indicate that all visible
indications of a water way ends at this point and that the QA
tools should not flag them as errors to be fixed.


One of the things we need is an anti-spring. Marked on Ordnance
Survey maps
as a sink.  We have natural=sinkhole but that seems only to apply
to a large
hole and/or depression.


The closest I can find on the wiki is manhole=drain? sinkhole=ponor 
seems to be for natural-looking versions.


The "one that everyone* did in geography at school" is 
https://www.openstreetmap.org/node/944314148/history


That's currently tagged as "waterway=cave_of_debouchement".

Best Regards,

Andy

* everyone in my school in Yorkshire, UK, anyway.


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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Andy Townsend]

On 21/07/2020 12:04, Michal Fabík wrote:

Hi,
in some parts of the world, it's common practice to paint guidepost 
information (destinations, distances etc.) on rock faces, trees, walls 
and similar existing surfaces, rather than use purpose-made plates 
attached to a pole. (Example: 
https://osm.fit.vutbr.cz/fody/files/21255.jpg)


Do you think that these warrant their own tagging style? Or is it 
acceptable to use information=guidepost, maybe with an additional tag 
(although I can't think of one off the top of my head)?


I've used "tourism=information; information=route_marker" for these.  
"trail_blaze" is also frequently used (in the US I think): 
https://taginfo.openstreetmap.org/keys/information#values .


I've also been trying to add these (both guideposts and route markers) 
to the relevant hiking route relation.


Best Regards,

Andy




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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Andy Townsend]

On 21/07/2020 20:37, pangoSE wrote:


Andy Townsend  skrev: (21 juli 2020 13:31:45 CEST)


I've also been trying to add these (both guideposts and route markers)
to the relevant hiking route relation.

That does not sound right to me. Why would you do that?


How would you indicate which relation a particular guidepost or route 
marker belongs to?


Best Regards,

Andy



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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Andy Townsend]

On 22/07/2020 16:08, pangoSE wrote:


I suggest you add the guidepost to a node on the path instead.

Please don't do this.  If there's a gate on one side of the road you 
wouldn't add that gate to the road itself, would you?



I really think it would be nice to be able to say query and list all 
hotels, wilderness huts and shelters within 200 m of the Kungsleden 
trail (Swedens most famous trail) but I don't think adding them to 
relations is the way forward. Maybe this can already be done with 
overpass. 


What Overpass certainly can't do is tell you "which guideposts are for 
which trail" if that information isn't recorded anywhere.



Best Regards,

Andy



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

Re: [Tagging] Finger- or guide-post text

[Andy Townsend]

On 17/07/2020 16:24, Jan Michel wrote:

Hi Andy,
we already have (not well documented) tags for this:

Either you use destination_sign relations as Sarah pointed out. Or, if 
you prefer a more simple approach, there are eight defined keys to add 
the information with approximate directions:


direction_north, ..., direction_southwest, direction_northeast, ...

For some reason they are only mentioned on the German Wiki page
https://wiki.openstreetmap.org/wiki/DE:Tag:information%3Dguidepost

But they are used almost 30,000 times already, see e.g.
https://taginfo.openstreetmap.org/keys/direction_south

These eight cardinal directions seem to be quite imprecise, but if you 
look at common intersections, they are able to cover almost all cases.


Jan


Thanks - that's really useful.  With the best will in the world I'm 
really not going to create several relations for each signed guidepost, 
so this is perfect for me for "ad hoc destination signs" on otherwise 
unimportant guideposts (which are the most common type where I'm mapping)


Best Regards,

A different Andy



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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Andy Townsend]

(re adding guideposts to route relations)

On 21/07/2020 22:18, Peter Elderson wrote:

I think the Why question comes first!


Why do people in OSM map anything?  I can't see any reason why I'd want 
to add urban buildings, or comprehensive address data, or a whole bunch 
of other things that people think are _really important_.  Part of the 
reason that OSM works as a project is that people map what is important 
to them without many predefined rules of what should be mapped, and the 
variety of people's interests means that OSM tends to record stuff that 
commercial maps simply don't bother with - not because they didn't think 
that it would make money, but because they just never thought of it.


To answer the direct question - having the guideposts visible as part of 
the relation makes it easy to visualise how (and where) a trail is signed.


https://www.openstreetmap.org/relation/1996318 is "officially unmarked", 
but there is some signage - more in some places than others.


https://www.openstreetmap.org/relation/8450999 I've walked quite a lot 
of and I've found exactly _one_ guidepost so far.


https://www.openstreetmap.org/relation/6366232#map=11/54.4646/-0.9798 I 
have not found any signage for at all.


Best Regards,

Andy


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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Andy Townsend]

On 25/07/2020 17:21, Matthew Woehlke wrote:

On 25/07/2020 07.06, Andy Townsend wrote:
Why do people in OSM map anything?  I can't see any reason why I'd 
want to add urban buildings, or comprehensive address data, or a 
whole bunch of other things that people think are _really important_.



How are addresses _not_ important? If I'm trying to find 123 Cherry 
Lane, I really, really appreciate if that entity actually exists in OSM.


What I was trying to say was that different people perceive different 
things in OSM as being "important" - there's no universal list.  That's 
why for that example I deliberately chose two types of data that I know 
people spend lots of time adding (even if I don't, much), and OSM is 
much the richer for all that added data.




For me, it's probably power lines that seem useless, but someone else 
probably has a use case where having those mapped is really helpful. 
(Maybe someone planning to buy a house wants to know, without having 
to drive there, if there are high-voltage power lines nearby?)



Well like many walkers I use those for navigation :)

Best Regards,

Andy



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

Re: [Tagging] Rio de la Plata edit war

[Andy Townsend]

On 26/05/2020 00:20, Alan Mackie wrote:

Has this edit war stabilised?

Apparently it has been blocking coastline updates across the whole 
world for /months /now.


https://osmdata.openstreetmap.de/data/land-polygons.html 

https://github.com/fossgis/osmdata/issues/7 



(picking this thread up again because there still hasn't exactly been a 
meeting of minds here)


land polygons have been generated (see 
https://osmdata.openstreetmap.de/data/land-polygons.html ) and 
https://github.com/fossgis/osmdata/issues/7 has been resolved by 
manually "releasing" the coastline.  The current situation in OSM is 
https://overpass-turbo.eu/s/WD8 - at the time of writing this the 
coastline crosses the river north of Buenos Aires.


However, edits are continuing (see 
https://www.openstreetmap.org/changeset/88787419 ).  I'm not convinced 
that moving to one of two extremes, even a small amount at a time, is a 
good idea until there's actually been discussion between the proponents 
of the various positions.


For what it's worth, neither extreme position looks the best answer to 
me - looking at the salinity change between river to ocean at 
https://www.sciencedirect.com/science/article/pii/S0307904X07000716 (see 
https://www.sciencedirect.com/science/article/pii/S0307904X07000716 for 
the key picture) and looking at 
https://de.wikipedia.org/wiki/Datei:Rio_de_la_Plata_BA_2.JPG suggests a 
location some way between the two.  Despite the NASA photo it looks like 
there isn't a "step change" in salinity - and of course values will 
fluctuate based on winds and tides etc.


Best Regards,

Andy



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

[Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Andy Townsend]

Hello,

This is a question that actually arose out of a "how to tag" argument 
that's come to the attention of the DWG in the USA, but it's actually 
easy to describe in terms of data in the UK that I'm familiar with, so 
I'll do that.


https://www.openstreetmap.org/node/12004813 is a 
"public_transport=stop_position" for a local station and is part of 
https://www.openstreetmap.org/relation/6396491 among other relations.  
The problem is that train lengths vary, and there are a number of stop 
positions, each of which are actually signed on the platform for the 
benefit of the drivers.  From memory I think that there's at least a 
2-car stop, a 4 car stop and 6/8 and 10/12 car stops.  The problem is 
that the current node doesn't correspond to any of them.


As I asked on the changeset that added the one above 
https://www.openstreetmap.org/changeset/40603523 , how should these be 
mapped and how should the PTv2 relations be set up for the different 
services that use them, given that different train services will use 
different stop locations here depending on train length?  Should each 
stop position be mapped and should there therefore be different copies 
of each relation for all the possible train lengths?  Should a "pretend" 
average stop position be added which is actually never correct but will 
at least look nice to data consumers that use PTv2 data?  Given that we 
don't know the actual stop position perhaps the railway=station object 
(in this case https://www.openstreetmap.org/node/7154300845 ) should be 
used instead?


Maybe the public_transport=stop position should be omitted entirely?  
This last option seems extreme, but one reading of 
https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position 
where it says "However, marking the stop position adds no information 
whatsoever when it is placed on the road at the point closest to 
highway=bus_stop or on the tram tracks closest to railway=tram_stop. In 
that case it can be abandoned. " might actually support that (and that 
seems to be the view of one side of the argument in the USA).


Maybe the "correct" answer is none of the above?  With a "local mapper" 
hat on I've managed to avoid PTv2 since it basically isn't relevant 
anywhere I normally map things, largely because I don't tend to do that 
near any actual public transport infrastructure, but with a DWG hat on I 
haven't been able to avoid the question, hence me asking here.


Best Regards,
Andy


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

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Andy Townsend]

On 12/08/2020 01:37, 80hnhtv4agou--- via Tagging wrote:
i have been to 11 stations in the last 3 weeks, the trains are not 
doing what the tags represent


If you've done this, and care that stop positions are mapped in the 
correct place, then I'd suggest that you actually map these stop 
positions (just as stop positions - don't worry about the relations).  
Add some sort of description that says in which circumstances a 
particular stop position would be used.


If you do that, people adding relations can use those stop positions as 
the see fit.  No-one can guarantee if or when they'll do that, but if 
they do, they'll be able to add the stop positions to relations.




Tuesday, August 11, 2020 7:25 PM -05:00 from Clay Smalley
:
You really need to stop calling people's edits "fake". It's
disrespectful. You're not in a position to determine whether my
edits were estimation or actually fictitious data.


Agree 100%.

No-one has a monopoly on "correct" information - everything is to some 
extent an abstraction.


Best Regards,

Andy


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

Re: [Tagging] Benches and hostile architecture

[Andy Townsend]

On 23/08/2020 21:22, Joseph Eisenberg wrote:

The term "hostile architecture" is too vague.


It is the normal British English (at least) description of this stuff.

Best Regards,

Andy



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

Re: [Tagging] bridge:name and tunnel:name

[Andy Townsend]

On 24/08/2020 01:12, Graeme Fitzpatrick wrote:



On Sun, 23 Aug 2020 at 23:45, Paul Allen > wrote:



Theyargued that name should be the name of the road and
bridge:name should
be used for the name of the bridge.  Which did nothing to change all
the existing bridges mapped the old way, and didn't get incorporated
in carto immediately (has it been, yet?)


No :-( Have just checked a few around here, & while the bridge renders 
as a bridge, the name isn't shown.


Some maps definitely will try and do sensible things with bridge:name 
etc. - see 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L3519 
which results in 
https://map.atownsend.org.uk/maps/map/map.html#zoom=19&lat=54.051964&lon=-1.177194 
for example.  I'm sure that isn't the only example.  I'm sure that OSM 
Carto will catch up with them at some point.


Best Regards,

Andy


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

Re: [Tagging] tagging for fairgrounds

[Andy Townsend]

On 27/08/2020 17:04, Richard Welty wrote:

so i'd like to propose one of these two


"fairgrounds" is more of an American rather than a British English way 
of referring to these sorts of things, I think.  See 
https://lists.openstreetmap.org/pipermail/talk-gb/2020-February/thread.html#24188 
for a discussion on the GB list, and the first reply to that links to 
previous discussions.  Also on this list 
https://lists.openstreetmap.org/pipermail/tagging/2020-February/thread.html#51268 
etc.


Best Regards,

Andy



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

Re: [Tagging] Powerbank Sharing Systems

[Andy Townsend]

On 19/09/2020 11:59, Jake Edmonds via Tagging wrote:
https://commons.wikimedia.org/wiki/Category:Powerbank-sharing_systems_by_name 


https://heychimpy.com
https://www.wecharge.me


I can’t see any tagging related to powerbank sharing systems.


Have you tried searching OSM data by name using Taginfo?


Unless anyone can point me to existing tagging, I will submit a 
proposal, based on amenity=bicycle_sharing, titled 
amenity=powerbank_sharing for tagging docking station.


I wouldn't worry about that - that'll just waste everyone's time.  If 
some on-the-ground infrastructure is missing from the map, just map it.  
It's perfectly possible to search by name or operator later if a 
consensus emerges about tagging.



Chimpy (linked above) appears to use docking stations and 
over-the-counter rentals. Should an additional tag, such as 
service:powerbank:rental=yes, be included for existing features?


Probably not.  We don't tend to tag "everything a shop might sell".  
There are exceptions (food, drinks), and if you want to map the 
availability of a particular service then you are free to do so - just 
don't expect everyone else to do it too.


Best Regards,

Andy



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

Re: [Tagging] Powerbank Sharing Systems

[Andy Townsend]

On 19/09/2020 11:59, Jake Edmonds via Tagging wrote:
https://commons.wikimedia.org/wiki/Category:Powerbank-sharing_systems_by_name 


https://heychimpy.com
https://www.wecharge.me


I can’t see any tagging related to powerbank sharing systems.

You might be able to find some of them if you search for the name in 
taginfo - go to https://taginfo.openstreetmap.org/ , search for the name 
and click the "values" tag - you'll get something like 
https://taginfo.openstreetmap.org/search?q=chimpy#values .



Unless anyone can point me to existing tagging, I will submit a 
proposal, based on amenity=bicycle_sharing, titled 
amenity=powerbank_sharing for tagging docking station.


If there really are none of these mapped right now, and they are 
mappable (fixed things that don't move about), I'd concentrate on adding 
the ones that you know about to the map as "some new tag that you think 
is appropriate".   It's perfectly possible to search by name or operator 
later if a consensus emerges, and change the ones that you mapped 
previously to that new consensus.


I wouldn't bother with a proposal - I really don't think that it would 
add any value in a case like this.


Best Regards,

Andy


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

Re: [Tagging] Powerbank Sharing Systems

[Andy Townsend]

On 19/09/2020 12:47, Jake Edmonds via Tagging wrote:
Maybe a proposal that needs voting on isn’t need but is it accepted to 
add things to the wiki without one? 


People certainly do do that (an example that comes to mind is 
https://wiki.openstreetmap.org/wiki/Key:verge ).  I don't see a problem 
with adding a page that says "this is how I'd suggest mapping this 
feature".  What's more problematic is adding something to "map features" 
that isn't really an accepted tag, just one person's "good idea", or 
gaming taginfo numbers by mechanically editing values to match a new tag 
(which has been done in the past).  An example of a group of tags where 
problems were reported was 
https://wiki.openstreetmap.org/wiki/Key:motorcycle:theme and earlier 
related pages - there were suggestions that the wiki was edited so that 
it looked like "accepted tagging" when it wasn't.


If you're worried that creating a new wiki page will make it look "too 
official" you can always create a wiki page underneath your wiki user 
and make it clear that it's a personal page (but still a suggestion to 
other mappers).




It’s much nicer to find a page on the wiki than looking through tag info trying 
to decide if something already exists.


Ultimately it's tag usage (by "real human beings" rather than imports 
etc.) that matters - that means that lots of people have agreed that 
it's a good idea to map a certain feature a certain way.  Any one person 
can add a wiki page; a few more can create and accept a wiki proposal, 
but neither of those really means that it's a widely accepted tag.  That 
doesn't mean that the proposal process has no value at all, but it does 
mean that if none of X are currently mapped let's at least try and map 
some of X before having a discussion about it.


Best Regards.

Andy

PS: Sorry for double post earlier - problem was not enough coffee yet.









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

Re: [Tagging] Feature Proposal - RFC - (shop=direct marketing)

[Andy Townsend]

On 02/10/2020 08:58, Shawn K. Quinn wrote:

On 10/1/20 14:46, Wieland Kestler wrote:

Hi everyone!

  


Due to the discussion in the german OSM-Telegram-group I made a proposal
for tagging points where people can buy e.g. game (meat) directly from
the forester.

  


For more details see the proposal page:
https://wiki.openstreetmap.org/wiki/Proposed_features/shop%3Ddirect_marketing



At least in the US, "direct marketing" usually refers to things like
infomercials or mail advertising campaigns. Such a shop would typically
not be mapped as such.


It also means that in the UK.

I'd suggest shop=farm, as another commenter has already suggested.

Regards,

Andy



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

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

[Andy Townsend]

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


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


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


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


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


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


Best Regards,

Andy


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

Re: [Tagging] coastline v. water

[Andy Townsend]

Hi,

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

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

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

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

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

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

Opponents of the change have said, among other things:

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

The possible solutions to this issue are:

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

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

* the polygons that have been created will not be removed

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

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

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

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

Best Regards,

Andy Townsend, on behalf of the Data Working Group

On 18/11/2020 20:19, Eric H. Christensen via Tagging wrote:

After a few days of much work, a recent collaborative project to turn the 
Chesapeake Bay from a nothing space outlined by natural=coastline to what we 
considered to be a more accurate relation of natural=water, we've received some 
negative feedback.

The difference of opinion seems to lie in the definition of what we're mapping.  The use of 
coastline is for "seas"[0] while the use of water is for "inland areas of 
water"[1].  Even though the Chesapeake Bay is tidal, there is no question that it is an inland 
waterway (it is completely surrounded by land except for the mouth at its southeast side).  The 
idea of using coastlines for basically creating an edge between the land and the nothingness of the 
ocean makes sense when, as far as the eye can see it's only water.

Now, some of the feedback that has been presented[2] is that because it is 
tidal it is part of the sea.  I have pointed out that many rivers and streams 
(and ditches!) are tidal; does that make them part of the sea?  I would not 
think so.  In fact, there are named seas on this planet that are not even 
connected to other water 

Re: [Tagging] Feature Proposal - RFC - Hazards

[Andy Townsend]

On 27/11/2020 04:25, Brian M. Sperlongano wrote:
Assuming that the boundary of that area is reasonably permanent, my 
first reaction is that this could be described by 
military=danger_area.  However, that tag requires landuse=military as 
the primary tag, which probably isn't correct here.


On Thu, Nov 26, 2020 at 10:59 PM Graeme Fitzpatrick 
mailto:graemefi...@gmail.com>> wrote:


Not wanting to create a bunfight, but just reading the news, &
wondering if this sort of thing should be tagged as a hazardous area?


https://www.abc.net.au/news/2020-11-27/ethiopia-to-launch-final-phase-of-offensive-in-tigray-region/12926606





Yes, there are precedents for having that sort of thing in OSM as 
military areas of some sort - have a look at how the frontline in the 
recent Azerbaijan / Armenia conflict was mapped over the last few months.


Best Regards,

Andy


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

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

[Andy Townsend]

On 03/12/2020 10:47, ael via Tagging wrote:

On Wed, Dec 02, 2020 at 11:08:55PM +, Paul Allen wrote:

Which then goes back to the discussions we were having a while back about

tagging the "dangerousness" of tracks.

hazard=extreme   surely?


Actually,

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

suggests the type (rather than the severity) of the hazard is what's 
most used there.  To be fair though, hazard tagging in OSM is a bit hit 
and miss - I did try and render commonly-used values and couldn't see 
any real consensus (Giant Hogweed was about the only one I could use).


Best Regards,

Andy



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

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

[Andy Townsend]

On 09/12/2020 14:36, Michael Tsang wrote:

Dear all,

I'm working with some roads in Central area in Hong Kong. Des Voeux Road
Central is considered one of the most important roads in the area which I
tagged it as highway=secondary, however another editor has repeatedly changed
it to highway=service on the fact that that road is closed to motor vehicles
except buses. An edit war has appeared.

Here is the relevant changesets and ways:
https://www.openstreetmap.org/changeset/94428780#map=17/22.28199/114.15872
https://www.openstreetmap.org/way/242113655#map=17/22.28168/114.15911
https://www.openstreetmap.org/changeset/95558773


My recollection from when I was there about 10 years ago was "primary", 
actually - and that's what OSM had at around that time: 
http://overpass-turbo.eu/s/113u 
http://osm.mapki.com/history/way.php?id=88695241 .  Unless things have 
changed significantly on the ground (always possible - 10 years is a 
long time in Hong Kong) I'd definitely have thought somewhere at the 
higher end would make sense.  I would never have thought of it as a 
service road.


In case anyone's wondering "how on earth can you remember one road from 
10 years ago" the HSBC building on that road is a huge landmark (in all 
senses of the word).


Best Regards,

Andy




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

Re: [Tagging] natural=fell not rendered, alternatives?

[Andy Townsend]

On 21/12/2020 07:39, Anders Torger wrote:

Hello,

I'm doing further mapping of Swedish national parks, now in the 
mountains, and I have noted that natural=fell (habitat over tree line) 
is not rendered.


Looking into why it seems that OSM-Carto implementors want more 
specific landcover tags to be used. ...


This isn't really anything to do with tagging, but I can understand why 
some renderers decide not to render it.


Usage, at least where am I, is hugely problematic: 
http://overpass-turbo.eu/s/11nH .


Usage in the Pennines northwest of Leeds is almost exclusively just a 
bunch of names that have been copied from old out-of-copyright NPE 
maps.  The features may be peaks, or patches of moorland, or something 
else again.  If a renderer was to do something with them, it'd probably 
be as "place=locality".


Further west examples like https://www.openstreetmap.org/way/412325588 
correspond better to the wiki definition.  In that example other landuse 
(woodland, heath) is also mapped.


There are also some surprising uses in place of other tags - on 
https://www.openstreetmap.org/way/368051383 it surely means 
"trail_visibility"!


Best Regards,

Andy



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

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

[Andy Townsend]

Hi all,

I'll reply to this as me since the DWG's ticketing system was cc:ed on 
this mail and we can't reply from there because the messages will bounce.


On 21/12/2020 15:42, Brian M. Sperlongano wrote:



On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm > wrote:


Our current data model is not suitable for mapping fuzzy areas. We can
only do "precise". Also, as you correctly pointed out, or basic
tenet of
verifiability doesn't work well with fuzzy data.


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.



(snipped discussion)


Since "fuzzy areas" are allegedly harmful to the database and data 
model, will the DWG be taking swift and immediate action to delete the 
49 objects currently harming the database by the use of the "fuzzy" key?


https://taginfo.openstreetmap.org/search?q=fuzzy 



Has the DWG ever taking swift and immediate action to enforce a 
particular tagging scheme?  We've certainly taken swift and immediate 
action to reverse the deletion of countries that someone didn't like, 
and to remove genitalia from the front lawn of the White House, but I 
can't think of an occasion when we've enforced a particular tagging 
scheme in that way.


The nearest recent example that I can remember was us having to "pick a 
side" in the Chesapeake Bay debacle 
(https://lists.openstreetmap.org/pipermail/tagging/2020-November/056426.html 
), but that was essentially just a revert to the "status quo ante" so 
that normal coastline processing could continue.





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.


I think we need to know whether these comments represent the opinion 
of the DWG, and whether the DWG is signaling to the community that 
they will be taking a heavy-handed approach against mappers that 
invent schemes for or create fuzzy areas through the principle of free 
tagging.



People add new stuff to OSM all the time, and invent new tagging 
schemes.  As long as it's possible to retag later when something better 
comes along, that's fine.  People who try and use the data may well say 
"I can't possibly use data tagged like that, I'll just ignore it", and 
that's fine too.  As long as proponents of the new scheme don't try and 
misrepresent it (e.g. have the wiki say that it is really popular when 
it isn't), or mechanically edit existing data to match it, or misuse an 
existing key in some way, I can't see why anyone would want to purge a 
new key from the database.


Best Regards,

Andy (from the DWG)

PS (not with a DWG hat on): Just to pick up on one other thing- as some 
people may know, the last time "tagging list mail volume" was mentioned 
I wrote https://www.openstreetmap.org/user/SomeoneElse/diary/393175 .  
By my reckoning, Anders is only in 5th place this month on the tagging 
list in terms of number of posts, and is some considerable way off the 
all-time record (someone managed 132 personal posts one month earlier 
this year).  How we try and map fuzzy stuff is worth discussing, even if 
with a rendering hat on I'm still in the "I can't possibly use data 
tagged like that, I'll just ignore it" corner on that one.  Mind you, I 
didn't think that anyone would do anything useful with site relations, 
and openinframap does.




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

Re: [Tagging] feature Proposal - Voting - settlement_type=crannog

[Andy Townsend]

On 07/10/2022 11:27, Marc_marc wrote:

Hello,

Le 07.10.22 à 12:11, Martin Koppenhoefer a écrit :

who cares for "in use" or "approved"


me :)

approved that means that the subject has been discussed,
that people have spent time on it, that there has been
an opportunity to detect problems, to propose improvements
it's quite different from an "in use", because a guy invented

Unfortunately discussion and "voting" by people who have only the 
vaguest idea of what the thing being voted on is adds no value*. There 
is a place on the "B Ark" for them...


The fact that there was only one comment during the fortnight of 
discussion means that people really don't know (or don't care) what 
these are, and people who do know and care (such as the proposer) should 
probably "just map these".  Whether that's via 
https://taginfo.openstreetmap.org/tags/defensive_settlement=crannog 
(which is slightly ahead in taginfo) or 
https://taginfo.openstreetmap.org/tags/settlement_type=crannog matters 
little; there are few of them in OSM right now, and the word "crannog" 
is characteristic enough, that they can fairly easily be remapped into 
some "better" archaeological scheme at some later stage.


What matters is getting them mapped, and getting from the 10s currently 
in OSM to the 1500 or so that apparently do or did exist**.


Best Regards,

Andy

* We still don't know what bicycle=designated means 
https://community.openstreetmap.org/t/use-of-bicycle-designated-vs-bicycle-yes-outside-of-germany/3230 



** According to wikipedia.  I was surprised that there were apparently 
as many as 1200 in Ireland.



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

Re: [Tagging] Feature Proposal - RFC - Historic

[Andy Townsend]

On 11/10/2022 14:54, Anne-Karoline Distel wrote:


Obviously, I support this. It has its own preset scheme in the iD 
editor, its own icons etc.


The following are missing (of the top of my head, because I proposed 
them) from the list and were approved already:


creamery 

ogham stone 



Anne



I suspect that most editors' preset schemes aren't driven entirely by 
what tags are "approved" and what aren't.  iD has historically used 
previous usage, so for example values suggested for the key "building" 
match https://taginfo.openstreetmap.org/keys/building#values .  JOSM 
uses a different list of curated values, but defaults to what the 
current mapper has used most recently.


For a new "historic" node, JOSM out of the box doesn't offer "creamery" 
or "ogham_stone", and it wouldn't really make sense for it to do so, 
since there are relatively few of either (even unmapped) around the 
world compared to the other historical suggestions already on JOSM's list.


Best Regards,

Andy


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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Andy Townsend]

On 11/10/2022 19:34, Evan Carroll wrote:


Some examples of these nameless sections are,

* w1101484647 by A_Prokopova_lyft

That was added in https://www.openstreetmap.org/changeset/127101982 , 
which was that user's first edit in OSM.


I'd suggest asking them in the changeset about that edit, including 
where they got the data from.  I'd also be perfectly reasonable to ask 
them what the "proprietary sources" were that they used, and why 
https://www.openstreetmap.org/way/1101484647 doesn't include the vet's 
to the west, for example.


Best Regards,

Andy




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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Andy Townsend]

On 12/10/2022 18:56, Evan Carroll wrote:


But in some places,
mappers have been more rigorous about respecting each building's
architectural origins.


This is all 100% new to me.  Where is it documented that a "shop" in a 
detached house should be mapped as a detached house, and not a shop? 
Where is the notion of "architectural origins" documented.


https://wiki.openstreetmap.org/wiki/Buildings

(which is the first page that I got when I searched the wiki for 
"building") has a prominent example "Tenement house containing a church, 
it is still building=apartments not building=church" (one of the 
pictures on the right; the one below it is the opposite situation).



I thought we could treat the wiki as authoritative and everything else 
not in the wiki as a wrong or mistaken, or unsupported?


No.  The wiki is maintained by volunteered on a "best efforts" basis, by 
human beings who may not have the same vision of what keys are used 
for.  That's why you'll see discussion on this list and other places 
saying things like "someone has changed wiki page X to say Y, which is 
wrong".


Sometimes there are long threads discussing exactly what people in 
different places mean by a certain form of tagging - 
https://community.openstreetmap.org/t/use-of-bicycle-designated-vs-bicycle-yes-outside-of-germany/3230 
is a recent example.  No-one there is "wrong", because they're 
explaining how they use that tag and how other people use it locally to 
them.


Best Regards,

Andy

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

Re: [Tagging] Feature Proposal - Voting - man made=evaporation tower

[Andy Townsend]

On 20/10/2022 20:36, Illia Marchenko wrote:

https://wiki.openstreetmap.org/wiki/Proposed_features/man_made%3Devaporation_tower

чт, 20 окт. 2022 г., 22:25 Illia Marchenko :

Please give link :-)

чт, 20 окт. 2022 г., 20:57 Kamil Kulawik :

Hi!

Voting has started for evaporation towers tagging -
man_made=evaporation_tower.



Hang on - you're asking people to vote for a thing that doesn't appear 
in the OSM database /at all/?  No-one - not even you - could be bothered 
with actually mapping one of these things using this tag before asking 
people to "vote" on it?


There has been recent criticism* that the way that some people are using 
the "proposal process" is wasting everyone's time.  I'm sure that you're 
doing this with the best of intentions, but this seems to be another 
example of it.


Best Regards,

Andy

* 
https://lists.openstreetmap.org/pipermail/tagging/2022-October/066190.html 
et al
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Window tinting?

[Andy Townsend]

On 20/10/2022 20:34, Illia Marchenko wrote:

Maybe craft=window_construction?
wiki.openstreetmap.org/wiki/Tag:craft=window_construction 



No, because it's not that.

There are a few dozen examples in taginfo:

https://taginfo.openstreetmap.org/search?q=tinting#keys

https://taginfo.openstreetmap.org/search?q=tinting#values

I'd pick one of those examples.

Best Regards,

Andy

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

Re: [Tagging] Feature Proposal - RFC - archaeological_site

[Andy Townsend]

On 22/10/2022 11:44, Anne-Karoline Distel wrote:

Following the rejection of the crannog proposal with the concern about
the hierarchy above the proposed tag, I now propose to change the key
from site_type to archaeological_type for reasons laid out under
"Rationale":

https://wiki.openstreetmap.org/wiki/Proposed_features/Key:archaeological_site 




Hello,

That page says "This would apply to c. 113 000 features".  For the 
avoidance of doubt, are you suggesting (after the acceptance of this 
proposal) that people would "just start using the new values", or are 
you planning a series of edits following 
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct , or 
do you believe that acceptance of 
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:archaeological_site 
implies acceptance of a change to OSM data as well?


The reason that I'm asking is as can be seen from 
https://taginfo.openstreetmap.org/keys/site_type#projects I'm currently 
using that tag to control display of features (actual example code at 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L5622 
for info) and it'd be good to know when I need to change that to say 
something else.


Best Regards,

Andy




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

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Andy Townsend]

On 23/11/2022 22:23, Graeme Fitzpatrick wrote:
But we're supposed to be tagging the base / buildings, not the boat 
itself.




Why not both?

Taking an example:

https://www.openstreetmap.org/node/8321217532

 * amenity = lifeboat
 * emergency = marine_rescue
 * lifeboat = offshore
 * lifeboat:class = RNLI Trent
 * name = George and Mary Webb
 * operator = Royal National Lifeboat Institution
 * operator:short = RNLI
 * ref = 14-14
 * seamark:name = George and Mary Webb
 * seamark:radio_station:category = ais
 * seamark:radio_station:mmsi = 232002370
 * seamark:rescue_station:category = lifeboat_on_mooring
 * seamark:source = Bing; https://rnli.org/find-my-nearest
 * seamark:type = rescue_station
 * website =
   
https://rnli.org/find-my-nearest/lifeboat-stations/whitby-lifeboat-station/whitby-lifeboats

The matching lifeboat station for that is:

https://www.openstreetmap.org/way/167044613

building 
 	yes 

description 
 
Search and Rescue
emergency 
 
lifeboat_station 

name  
Whitby Lifeboat Station
operator 
 	Royal 
National Lifeboat Institution
operator:short 
 
RNLI
operator:wikidata 
 
	Q2166873 
seamark:name 
 
Whitby Lifeboat Station
seamark:rescue_station:category 	lifeboat 

seamark:type 
 
rescue_station 

website  
https://rnli.org/find-my-nearest/lifeboat-stations/whitby-lifeboat-station
wikidata 
 
Q64584542 


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

Re: [Tagging] plantation=yes?

[Andy Townsend]

On 10/12/2022 18:23, Mark Wagner wrote:

As actually used on the map, "natural=wood" and "landuse=forest" are
synonyms.

Depends on the map - if there are no other tags 
https://map.atownsend.org.uk will show "landuse=forest" in a lighter 
green to "natural=wood" (to indicate "forestry"; it also supports 
"landuse=forestry" too).  If there are other tags (e.g. "leaf_type") 
it'll use the same colour as for "natural=wood".


Best Regards,

Andy



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

Re: [Tagging] Homogenize diplomatic tags

[Andy Townsend]

ll end up as a
mechnical-turk-driven "search and replace".

After your feedback, I've done some extra testing. Here's my feedback:
- diplomatic=ambassadors_residence : the challenge is ready to publish
- diplomatic=delegation : the challenge is ready to publish
- diplomatic=high_commission : the challenge is ready to publish
- diplomatic=permanent_mission : most of the cases are in New-York : 
the challenge is ready to publish or we could also consider a 
mechanical edit
- diplomatic=permanent_mission : I found several wrongly tags 
examples, this should be handled only be experienced mappers

- non_diplomatic : should be managed by experienced mappers only

Deal?

Le sam. 29 janv. 2022 à 07:17, Mateusz Konieczny via Tagging 
 a écrit :





Jan 28, 2022, 23:37 by graemefi...@gmail.com:



On Sat, 29 Jan 2022 at 04:57, Andy Townsend
 wrote:

* An OSMer with considerable experience of this area has
written about this in the past:
https://www.openstreetmap.org/user/apm-wa/diary/45200


Nice clear explanation, from somebody who well & truly knows
the subject!

Is it permitted to link to that diary entry from the wiki?

Yes, it is 100% fine, welcome, desirable and useful to link relevant
diary entries, mailing list threads and other materials.

(as citation in citation or in external links section
are the
most typical)

Feel free to improve wiki, this is very useful!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



--

*Florian Lainez*

@overflorian <http://twitter.com/overflorian>

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

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Andy Townsend]

On 15/12/2022 23:34, Graeme Fitzpatrick wrote:


& it's also a shame that they couldn't have been mentioned as 
unresolved when I said twice that it was ready to go to voting!



I think that any "reading of the room" yesterday (when it was moved to 
voting) would suggest that the issues raised 6/12 on the mailing list 
hadn't really been resolved.


The answer to "what are we mapping" of "The land-based location of 
emergency groups dedicated to the saving of lives at sea" doesn't 
explain why "amenity=lifeboat" is "deprecated".  Like it or not, this is 
used exactly how you'd expect:


https://map.atownsend.org.uk/maps/map/map.html#20/54.48811/-0.61310

I actually only added that rendering when I discovered that the data was 
there, because of this proposal, but given that it /is /there any 
attempt to deprecate it without a replacement is going to get a no from me.


Best Regards,

Andy

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

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Andy Townsend]

On 16/12/2022 01:51, Graeme Fitzpatrick wrote:





On Fri, 16 Dec 2022 at 10:59, Andy Townsend  wrote:

doesn't explain why "amenity=lifeboat" is "deprecated".  Like it
or not, this is used exactly how you'd expect:

https://map.atownsend.org.uk/maps/map/map.html#20/54.48811/-0.61310

But as I've pointed out a couple of times before, by policy, OSM 
doesn't map mobile items


... and that discussion veered off (on IRC) into "things that can move 
but usually don't" as I recall.



Yes, that (totally undocumented & undiscussed) tag could be either 
written up to specify it's the location where a lifeboat is moored, or 
it could be changed to amenity=lifeboat_mooring, but, is it 
verifiable? Can anybody walk up to that spot 24/7/365 & say Ah yes, 
that's the /George//& Mary Webb/? Sorry, but no they can't, as it may 
be elsewhere at that moment.


Most of the time, yes they can* - 8000 launches per year between 400 
lifeboats is on average 20 per year.  If we take a guess at 8 hours per 
launch, it's there 98% of the time.


Best Regards,

Andy


* source 
https://rnli.org/what-we-do/lifeboats-and-stations/our-lifeboat-fleet 
and 
https://rnli.org/what-we-do/lifeboats-and-stations/latest-lifeboat-launches


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

Re: [Tagging] Homogenize diplomatic tags

[Andy Townsend]

On 16/12/2022 07:33, Mateusz Konieczny via Tagging wrote:

If this edit was in violation of
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
then I would recommend notifying DWG

(for the avoidance of any doubt) I am a member of the DWG, but this was 
not raised with the DWG as an issue.  I just encountered it as an 
ordinary mapper, albeit one with rather more experience of this sort of 
thing than most people.


Essentially, "I gave myself the advice that I would have given had it 
been reported to the DWG" - look at the data that has changed and the 
time that has passed, and figure out the best way forward.  As I said 
yesterday "Normally I'd suggest just reverting your undiscussed 
mechanical edits ... but this far on from the change I'm not convinced 
that would be the best approach". However I do believe that the people 
responsible for this mess tidy up the data in the wiki and fix the 
broken links.


As an aside, the code required to handle these objects has grown by 50% 
(from 33 lines to 50), partly because "diplomatic" sort of is a primary 
tag and sort of isn't ("office=diplomatic" is still a thing), and now 
includes comedy "no=yes" checks like '( keyvalues["diplomatic"] == 
"non_diplomatic")' 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1885 
, but I suspect that that ship has sailed a long time ago.


There hasn't yet been an acceptance that the approach used to change 
these tags was wrong (see 
https://www.openstreetmap.org/changeset/117329397 ).  To be clear - tag 
consolidation (where many tags really do mean the same thing) is a good 
idea, provided that the new schema isn't completely bonkers and 
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct is 
followed to the letter.  Plenty of people do that (including you!) 
without causing any complaints.


Best Regards,

Andy

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

Re: [Tagging] Homogenize diplomatic tags

[Andy Townsend]

On 17/12/2022 11:03, Georges Dutreix via Tagging wrote:

Hello,
As proposed, I continue here our discussion started on 
https://www.openstreetmap.org/changeset/117329397



Thanks

You suggest to modify something in the wiki, I am ready to 
participate, but please I will need a guidance since I don't see 
exactly what you are expecting.




The wiki's supposed to document how tags are used in OpenStreetMap.  
Currently https://wiki.openstreetmap.org/wiki/Key:diplomatic covers both 
what you changed things _from_ and what you changed things _to_.


It also suggests that "diplomatic" isn't a top-level tag ("In 
conjunction with office 
=diplomatic 
, this key 
helps...), whereas 
https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic 
says "Elevation of diplomatic 
=* to primary tag 
status".


https://wiki.openstreetmap.org/wiki/Key:diplomatic contains lots of tags 
listed as "in_use" where "This tag does not appear in the OSM database".


An example of an "old" page is 
https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Dhigh_commission .  
It reads like proper documentation.  An example of a new page is 
https://wiki.openstreetmap.org/wiki/Tag:embassy%3Dhigh_commission , 
which does not.  If someone unfamiliar with the history was to look at 
the wiki, they may well pick the "old" scheme because it looks better 
documented.


https://wiki.openstreetmap.org/wiki/Key:consulate suggests "Requires 
office=diplomatic and diplomatic=consulate on a node". I don't know if 
you think that that is supposed to be true or not, but it's not how I 
read the proposal.


The dead link to honorary_consulate seems to have been fixed - thanks to 
whoever did that.


Best Regards,

Andy

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

Re: [Tagging] Private ambulance / patient transport service

[Andy Townsend]

On 03/01/2023 22:42, Illia Marchenko wrote:

Graeme Fitzpatrick :

A suggestion on the forum of amenity=training for the first-air
training side of things + a description of everything else.


Note that the proposal for  amenity
=training was rejected.
wiki.openstreetmap.org/wiki/Proposed_features/training 



To be clear, what was rejected was the wiki page at 
https://wiki.openstreetmap.org/wiki/Proposed_features/training because 
it suggested deprecating a bunch of other tags.  There are still 3k 
https://taginfo.openstreetmap.org/tags/amenity=training in use, and it 
still may be the best fit for "training" if there is an outward-facing 
training facility that doesn't really fit anywhere else.


"office=company" would surely work for the main office though.

Best Regards,

Andy

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

Re: [Tagging] Change emergency=lifeboat-station to water-rescue

[Andy Townsend]

On 04/01/2023 06:16, Graeme Fitzpatrick wrote:


With Christmas over, & the start of a new month, thought it must be 
time to revisit 
https://wiki.openstreetmap.org/wiki/Proposed_features/emergency%3Dlifeboat_station 



...
Could I please ask for your feedback on the basic idea?

I suspect that any proposal that attempts to deprecate in-use tags 
without suggesting a replacement is likely to be rejected.


Best Regards,

Andy



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

Re: [Tagging] Change emergency=lifeboat-station to water-rescue

[Andy Townsend]

On 11/01/2023 23:10, Graeme Fitzpatrick wrote:


On Fri, 6 Jan 2023 at 14:19, Graeme Fitzpatrick 
 wrote:


New proposal done:

https://wiki.openstreetmap.org/wiki/Proposed_features/emergency%3Dwater_rescue


Everything is quiet! :-)

Does that mean that people are happy with how it looks?

No, it probably just means that, based on previous conversations, people 
think that replying will have little effect, and will just vote "no" 
when the time comes :)


Bluntly:

 * This proposal seems to add no value.  There's literally nothing at
   
https://wiki.openstreetmap.org/wiki/Proposed_features/emergency%3Dwater_rescue
   that says why this new tagging is an improvement on what we have now.
 * The proposal to create a "new" tag "emergency=marine_rescue" ignores
   that that tag is already in-use for something else (see e.g.
   https://www.openstreetmap.org/node/8321217532 ).  It just gives the
   impression that things haven't been thought through at all.

Best Regards,

Andy

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

Re: [Tagging] caravans en-de inconsistency

[Andy Townsend]

On 18/01/2023 23:15, Graeme Fitzpatrick wrote:
When I created https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcaravan, 
I defined them as:


"recreational vehicles such as towed caravans (a.k.a travel trailers, 
pop-tops, camper trailers, tent trailers, 5th wheelers etc); powered, 
self-propelled motorhomes (camper vans, expedition vehicles, truck 
trailers / slide-ons etc); & similar types of vehicle.


For ease, on this page they are all referred to as caravans", together 
with example photos of them all.


Maybe that should be copied across to 
https://wiki.openstreetmap.org/wiki/Key:caravan?



Not if it affects use of that tag as an access tag.  In the UK (and I'm 
sure elsewhere) there are plenty of cases were caravans are prohibited 
but motorhomes are not.


Currently:

https://overpass-turbo.eu/s/1qjp

1087 examples worldwide combined with "highway" tag where it can be 
assumed to be an access tag


confusingly there is also "caravans", which isn't supposed to be an 
access tag, but:


https://overpass-turbo.eu/s/1qjq

437 examples worldwide combined with "highway" tag where it can be 
assumed to be an access tag


Best Regards,

Andy


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

Re: [Tagging] leisure=practice_pitch a bad idea because too overspecific for a main tag ?

[Andy Townsend]

On 31/01/2023 22:05, Graeme Fitzpatrick wrote:



But iD, at least, when tagging basketball "pitches" asks for the 
number of hoops, with 1 as an option.


Does that info then go anywhere downstream?


Apparently:

https://master.apis.dev.openstreetmap.org/way/4305950698

hoops    1
leisure  
pitch 
sport  
basketball 



Best Regards,

Andy

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

Re: [Tagging] [RFC] Feature Proposal - Replace `*:signed` suffix key with `signed:*` prefix key

[Andy Townsend]

On 01/02/2023 16:08, Marc_marc wrote:

you can obviously just set unsigned=A;B


I've got to admit, I didn't see that one coming!

"unsigned=yes" is way ahead of all other "unsigned=" uses (see 
https://taginfo.openstreetmap.org/keys/unsigned#values ). However, 24 
people have used "unsigned=name", so it's not entirely unknown.  No 
"unsigned=A;B" combinations have more that a single usage, though.


Best Regards,

Andy



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

Re: [Tagging] [Talk-us] New MapRoulette Challenge - Add Surface to Highways

[Andy Townsend]

On 2/3/23 09:16, Walker Kosmidou-Bradley wrote:

I use routing to measure accessibility to schools and health clinics 
here in west Africa. I have to make sure that my models also work in 
South Asia. Having the surface tag attributed makes processing 
infinitely easier because I don’t have to adjust my default values 
based on country.


(veering off from TomTom's MapRoulette challenge somewhat, but)

Unfortunately, you will have to adjust your default values based on 
country.  There are enough differences even between mapping approaches 
in nearby western European countries that a router will produce 
nonsensical results if it makes assumptions valid only in place A in 
place B as well.


Also, even if someone filled in all the values for an "obvious" tag 
(perhaps in response to a MapRoulette challenge such as this one), 
there's no guarantee that new motorways would have the same tag added in 
the future, or that the tag would remain as more detail is added.


That said - sometimes values that are "obvious" in one place aren't 
"obvious" in another, so it's definitely worth having the discussion 
about that if it's relevant (which as numerous people have said 
previously, it isn't for this challenge in the US.


Best Regards,

Andy



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

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

[Andy Townsend]

> By the way, I saw some changes leading to x10 contribution rates and 
be criticized as disrupting longstanding practices or established tagging.


An actual example would be really useful here.

> Establishment nor longstanding practices shouldn't be valid reasons 
on their own to justify decision making about tagging.


Indeed - if a proposal (even a reorganisation of existing usage) allows 
better information to be collected then it makes sense to do it.  The 
"diplomatic" reorganisation was one such (though the implementation was 
botched).  In this case, I'm not convinced that this proposal has any 
benefit.  We have edge cases now; after this proposal we will still have 
a whole bunch of slightly different edge cases.


> How about considering tagging as an independent valuable thing we 
should take care of as well?


Because it isn't?  It's literally just describing how things are stored 
within OSM.  Anyone coming to OpenStreetMap as a mapper for the first 
time won't see tags at all - their editor will look after that for 
them.  A data consumer will have a simplified view of the world and will 
have to map OSM concepts into the ones that they are interested in.


As a concrete example, here:

https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L6003

is where I take a bunch of things from OSM and map them into a concept 
that is displayed on a map ("Variety Stores", shown with a "£" 
symbol**).  A map for a different platform, here:


https://github.com/SomeoneElseOSM/mkgmap_style_ajt/blob/master/transform_03.lua#L1760

has a mapping onto a different category, "General Stores".  This is 
because this map is for Garmin devices which (by default) have a 
hardcoded series of categories that the search menus know about, and 
"Variety Stores" isn't one of them, but "General Stores" is.


Almost no-one in the outside world is going to want to distinguish 
between the actual OSM values here; they're only interested in their own 
real-world concepts.  In many cases this may be much broader-brush, 
perhaps "shops that sell food" vs "shows that primarily sell non-food", 
or even just "shops".


Anyone suggesting widespread changes such as this needs to explain how 
this proposal will help with at least one of the following:


 * Allowing new mappers to contribute to OSM easier than they currently can
 * Allowing some nuance to be captured that can't be captured now
 * Make life easier for data consumers in some way

and the benefit needs to be proportional to the necessary upheaval 
(which in this case would be significant).  Note that "satisfying the 
data normalisation urges of people familiar with working with databases" 
isn't on that list.


Best Regards,

Andy

** apologies to anyone with a pocketful of € instead of £


On 13/02/2023 12:21, François Lacombe wrote:

Hello

Le ven. 10 févr. 2023 à 19:29, Mateusz Konieczny via Tagging 
 a écrit :


Or to be more specific solved problems, if any, are much smaller
than size
of change of longstanding tagging practices.


To me, it's a return of experience matter and a debate we should 
provide with facts.
OSM has been created to question longstanding practices, how the same 
can be raised to prevent its own evolution nowadays?


Many attempts to change longstanding practices in the past had 
unleashed contribution and bring more visibility on covered topics.
I made a presentation at SOTM France last year about what benefits 
tagging development brings to OSM.
Studying chronology tabs on taginfo learn us a lot about how the 
community reacts with such changing, despite changes may be slow or 
significant.


The methodology and efforts deployed to achieve the rollout of new 
tagging should be adapted in regard of amounts of features to retag, 
yes (and we will never be perfect from that perspective).
By the way, I saw some changes leading to x10 contribution rates and 
be criticized as disrupting longstanding practices or established tagging.
Establishment nor longstanding practices shoudn't be valid reasons on 
their own to justify decision making about tagging.


How about considering tagging as an independent valuable thing we 
should take care of as well?


Best regards

François

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

Re: [Tagging] Combining "locked=yes" with various access tags

[Andy Townsend]

On 21/02/2023 14:34, Mateusz Konieczny via Tagging wrote:




Feb 21, 2023, 15:24 by zeev.stad...@gmail.com:


 1. As far as non-emergency routing, the "locked" tag should be
ignored.
 2. A "locked=no" tag indicates that a legal access restriction is
not enforced by a lock and therefore could be overcome in case
of an emergency.
 3. A "locked=yes" tag indicates that the legal access restriction
is enforced by a lock and therefore cannot be overcome in case
of an emergency.

I'd actually suggest that "locked=yes" just means "there is a lock".  It 
_might_ be there to enforce a restriction, or it might be an "illegal 
lock".  There are unfortunately some examples of the latter on rights of 
way in England, Wales and especially Scotland.




This is not the interpretation of other people, as seen in a
discussion on a GraphHopper routing issue

https://github.com/graphhopper/graphhopper/issues/2757#issuecomment-1434806229
There you could also find a picture of such a barrier.
Please help us resolve the differences

That is better mapped by mapping path around barrier, at least in my 
opinion.



Agreed - if you can walk around a locked gate, ensure that the OSM data 
reflects that.


Best Regards,

Andy

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

Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

[Andy Townsend]

On 30/03/2023 09:25, NKA mapper wrote:
The definition of amenity 
=charging_station 
 will 
change slightly and will represent both locations with a single charge 
point and locations with a group of chargers.


How do I know if an "amenity=charging_station" in the OSM data is a 
"single charge point" or a "group of chargers"?


Best Regards,

Andy

PS:  I have read 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/EV_Charging_Station_Mapping 
and 
https://community.openstreetmap.org/t/charging-stations-sites-or-individual-chargers/96810 
(and asked the question before there too) and the answer to this 
question is still not clear to me.  This might be me, or it might be the 
proposal, but I'd love to know the answer.


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

Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

[Andy Townsend]

On 30/03/2023 18:13, NKA mapper wrote:

tor. 30. mar. 2023 kl. 18:14 skrev Andy Townsend :

How do I know if an "amenity=charging_station" in the OSM data is
a "single charge point" or a "group of chargers"?

The intention is to not have a difference. Both a single charger 
location and a multi-charger location is a place where you could 
charge your vehicle, and the proposal is to map them the same way. 
This is similar to a fuel station, where I would tag one single pump, 
typically at a rural location, as amenity=fuel.


That would be a problem, as trying to use the same tag for different 
physical objects always is in OSM.  If I


gis=> select count(*) from [some database table] where amenity = 
'charging_station';

 count
---
   267
(1 row)

How do I know what I am counting?  How do I count just "single charge 
points"?  How do I count "groups of chargers"





Of course tags like capacity and socket would give indications.


If tagged, but plenty exist without those: https://overpass-turbo.eu/s/1ta8


And if amenity=charging_station is tagged as an area around a number 
of charge points, that would be a group.


That'd need to be a spatially-aware query, and I wouldn't assume that 
data consumers can easily do that.  At the place where I detect charging 
stations I don't have that capability: 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1492 
.


If the same tag must be used for both, the only way to tell "single 
charge point" from "group of chargers" is to have a tag that is set to 
indicate which is which.  If "newtag=single" it means it's a single 
charge point, if "newtag=group" it's a group, and if "newtag" is not 
set, we don't yet know, and need to encourage local mappers to add the tag.


Recycling centres are similar, and I handle them like this: 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1648 
, though in this case the extra tag ("recycling_type=centre" ), if 
unset, suggests that we're just talking about a recycling bin not a 
recycling centre.


Best Regards,

Andy


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

Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

[Andy Townsend]

On 31/03/2023 07:18, Mateusz Konieczny via Tagging wrote:


How you distinguish "marks group of chargers" and "marks single 
charger" within

group of chargers" now?

I don't, because currently it either marks "some chargers" (where there 
is no more detail) or "individual chargers" (where there is).  I'm not 
aware of anywhere where there are both a group of chargers AND single 
chargers are mapped in UK or IE (I'm sure there is one, but aren't aware 
of it).  I can show essentially "at least one charger", and it has more 
or less detail, but it is "at least one charger".



Is it "ideally proposal would introduce this ability" or "proposal 
breaks existing ability"?


As these things become more mapped, the proposal will lead to both 
individual chargers (that are already mapped in detail) and newly mapped 
charging areas being tagged in exactly the same way. We don't have to do 
this to ourselves - just suggest a tag that indicates that a charging 
area is a charging area!


Best Regards,

Andy



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

Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

[Andy Townsend]

On 31/03/2023 07:10, Mateusz Konieczny via Tagging wrote:
I guess that in such cases it may be possible to tag it both as 
charging station and

a charge point at the same time?


That'd work - it makes it clear that this is a "new" 
amenity=charging_station (e.g. a "group of chargers", even if there is 
only one), not the previous "probably a single charger but we don't 
really know".


No https://taginfo.openstreetmap.org/tags/man_made=charge_point#overview 
are yet mapped, so any with that tag must be the "new" schema.


Best Regards,

Andy



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

Re: [Tagging] Status of clothes=motorcycle

[Andy Townsend]

On 06/04/2023 09:46, Illia Marchenko wrote:
One of the wiki editors (Rtfm) insists that the clothes=motorcycle tag 
has been deprecated in favor of motorcycle:clothes=yes. For me it's not.

https://wiki.openstreetmap.org/wiki/Special:MobileDiff/2499835

See also 
https://community.openstreetmap.org/t/currently-ongoing-automated-edit-for-service-vehicle/97737 
.  https://www.openstreetmap.org/user/ti-lo/history and 
https://wiki.openstreetmap.org/w/index.php?title=User:Rtfm&action=view 
are the same person.


Best Regards,

Andy



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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Andy Townsend]

On 18/04/2023 17:26, Mateusz Konieczny via Tagging wrote:



Apr 18, 2023, 17:39 by p...@trigpoint.me.uk:

I have come across a few cases where a mapper has has blindly
answered no to a list of octane ratings that do not exist in the
country they are mapping in.

In the UK it is safe to assume every filling station sells Euro
95/E10 and diesel.

Are there also LPG-only stations in UK?



I think that it is safe to say that there is something of everything 
somewhere - even if not currently mapped.  A few years ago a local 
petrol station hit on the interesting combination of "red diesel* + 
leaded".  After working down this list


https://taginfo.geofabrik.de/europe/britain-and-ireland/search?q=fuel

and looking at combinations, I currently use this logic:

https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1499

to decide whether something should be displayed on a map as "regular 
fuel", "electricity", "waterway fuel", "regular fuel and electricity", 
"LPG" or "hydrogen" (in UK/IE).  Note that consideration of aviation and 
water usage means looking at vending too - but you may want to just 
ignore those.


Best Regards,

Andy

* See https://en.wikipedia.org/wiki/Fuel_dye#United_Kingdom . "Green 
diesel" in Ireland.




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

Re: [Tagging] Feature Proposal - Approved - EV Charging Station Mapping

[Andy Townsend]

On 03/05/2023 08:28, Marc_marc wrote:
I don't see how an algo will detect that 2 objects 
amenity=charging_station represent 2 sites on the same parking

(and are therefore valid in the new schema) and not 2 charging
stations on the same site (which would have to be changed to 
man_made=charging_station).


Agreed - i tried to explain the problem at 
https://community.openstreetmap.org/t/charging-stations-sites-or-individual-chargers/96810/198 
.  That resulted in this change 
https://wiki.openstreetmap.org/w/index.php?title=Proposal%3AEV_Charging_Station_Mapping&type=revision&diff=2504680&oldid=2498183 
, but beyond that communication didn't really occur (the people 
promoting the proposal thought that there wasn't a problem).


It's less of an issue here than it might me with other proposals because 
the infrastructure being mapped is getting expanded rapidly, so the "old 
ones already mapped" will be a small, shrinking subset of the total.


What might become an issue is that I doubt that the paradigm chosen here 
that mirrors existing petrol / diesel infrastructure actually matches 
what we will end up with - I suspect that we'll get "almost every 
parking space has a charge point" instead, although that's obviously 
some way off currently.


Best Regards,

Andy



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

[Tagging] Edits to "names" page following last year's discussion (was: Re: I am reverting an edit to the "Names" page on the Wiki)

[Andy Townsend]

Sorry to dredge this up again, but what seems to have happened is:

Some edits to https://wiki.openstreetmap.org/wiki/Names by 
https://wiki.openstreetmap.org/wiki/User:Bgo_eiu were reverted 
https://wiki.openstreetmap.org/w/index.php?title=Names&type=revision&diff=2368644&oldid=2351644 
and there was discussion on this list at 
https://lists.openstreetmap.org/pipermail/tagging/2022-August/065130.html 
.  Before the discussion went off-topic, there was broad agreement with 
the revert.


They then made essentially the same edit again.  In particular 
https://wiki.openstreetmap.org/w/index.php?title=Names&type=revision&diff=2371288&oldid=2368814 
changes "Avoid Transliteration" (which is the OSM norm) to 
"Transliteration" (which is not).


It would of course be entirely reasonable to note that when a particular 
language has multiple orthographies that that should to be taken into 
account (see for example the ongoing discussion at 
https://community.openstreetmap.org/t/multilingual-names-in-bulgaria/98762 
about how names should be handled in Bulgaria).  However, most languages 
only have one form of writing in very wide use, so this should at best 
be a footnote or a bracketed comment on the main page.


A new OSM editor should not be confused by the content of something as 
basic as the "names" page in the OSM wiki. Currently, they probably will be.


I believe that what needs to happen is essentially a revert of the 
changes at 
https://wiki.openstreetmap.org/w/index.php?title=Names&type=revision&diff=2371288&oldid=2368814 
, whilst ensuring that the "some countries" paragraph at the end covers 
those rarer cases where transliteration is the norm.


It'd be great if someone who is invested in the value of the OSM wiki 
would make the relevant edit*, rather than me, who thinks that it is 
(following edits such as this) quite often unhelpful and unfortunately 
sometimes best ignored.  However, I'll do it if no one else will.


Best Regards,

Andy

(for the avoidance of any doubt, writing in an entirely personal capacity)

* like Harry Wood did with this section, after significant consultation, 
back in 2014



On 12/08/2022 12:44, Clay Smalley wrote:
Regardless of the topic, personal attacks are not necessary. You don't 
build consensus by publicly shaming other contributors.


-Clay

On Fri, Aug 12, 2022, 4:15 AM bgo_eiu (OSM mailing list email) via 
Tagging  wrote:


The topic at hand is an update I made to the wiki. Anyone is free
to discuss this on the Wiki, where this discussion belongs.

--
https://www.openstreetmap.org/user/bgo_eiu
https://wiki.openstreetmap.org/wiki/User:Bgo_eiu

Sent with Proton Mail  secure email.

--- Original Message ---
On Thursday, August 11th, 2022 at 5:08 PM, Richard Fairhurst
 wrote:


bgo_eiu wrote:
> I don't think many people have ever agreed with your whining
> on here. I notice people complain about your Wiki edits on
> Slack regularly.

This is not how we conduct ourselves on here. Please desist.

Richard
sporadic tagging@ list admin


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


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

Re: [Tagging] office=healthcare deprecated or bad documentation ?

[Andy Townsend]

On 12/05/2023 21:16, Marc_marc wrote:

Hello,

in 2020, the wiki was changed [|] for this tag (I don't remeber
that we talk about it, no link in the comment of the change)

[1] 
https://wiki.openstreetmap.org/w/index.php?title=Tag:office%3Dhealthcare&diff=prev&oldid=2062630


See also discussion at 
https://community.openstreetmap.org/t/deprecated-features-reason/99048


It's been changed back, and I asked why someone thought that the tag was 
"discouraged" (which might have been part of the original problem).


Best Regards,

Andy



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

Re: [Tagging] tag templates in the wiki

[Andy Townsend]

On 12/08/2019 00:05, Martin Koppenhoefer wrote:
Is it now unavoidable that the info box content on tag definition 
pages in the wiki comes from the database? Is there consensus that the 
higher complexity to edit it is less important than the features we 
gain from it



I don't think it's unavoidable - presumably you can just ignore the 
wikidata stuff and carry on as before?


For example, https://wiki.openstreetmap.org/wiki/Key:verge is an in-use 
tag that has not wikidata entry, does not need one and that page is 
useful despite that.


I'm concerned that some wikidata entries are just plain wrong - 
especially in places where OSM's use of a word doesn't match the normal 
English (any English - English, American, Hiberno-, etc.) usage of that 
word.  Examples include 
https://wiki.openstreetmap.org/wiki/Tag:place%3Dcity (though there 
wikidata's English description at https://www.wikidata.org/wiki/Q515 
"large and permanent human settlement by size of its inhabitants" adds 
extra comedy), https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood 
and https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dforest which both 
link to https://www.wikidata.org/wiki/Q4421 .  In each of these cases 
all nuance of the usage of the OSM tag is lost.


Best Regards,

Andy



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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

[Andy Townsend]

On 15/08/2019 10:56, Peter Elderson wrote:

... So the lowest level always contains only ways, the higher level contains 
only relations.


Please don't make things more complicated than they need to be. Most 
hiking routes are just a single relation and are best left that way.





The ways in the main relation should form one continuous sorted (sortable) 
route,


No.  Don't assume that route ways are sorted in OSM as they usually aren't.



which data users can extract or link to for navigation or planner software.


Pretty much irrelevant.  As long as the data's there, software can 
figure it out.





Note that rendering routes is not that critical,


This depends entirely on the use case.  As an example, it is for me.

Best Regards,

Andy



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

[Tagging] Route sorting (was: Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes)

[Andy Townsend]

On 15/08/2019 16:18, Peter Elderson wrote:

Still most problems arise because ID edits damage routes.


An unsorted route in OSM is not damaged.  If your software cannot deal 
with unsorted routes then it cannot deal with many routes currently in OSM.


Please don't try and propagate the madness that some people have tried 
to impose onto public transport route tagging (e.g. multiple relations 
per route) elsewhere in OSM.  If something is not broken, please do not 
attempt to fix it.


(apologies for continuing offtopic diversion; not sure what this has to 
do with tagging)


Best Regards,

Andy




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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Andy Townsend]

On 15/08/2019 14:26, Joseph Eisenberg wrote:

How about "craft=artist" then? The tag "craft=atelier" was described
as for any type of artist: "workshop of a ...professional artist in
the fine or decorative arts"


"craft=artist" is much better in my view - people are far more likely to 
know what it means.


(whether this should be somehow be embedded in the map features page is 
an entirely different question though).


Best Regards,

Andy



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

Re: [Tagging] Route sorting

[Andy Townsend]

On 15/08/2019 17:04, Peter Elderson wrote:


Not talking about simple unsorted, but made unsortable. Enter a 
roundabout of pedestrian area into a route, extend a road, shift 
another - and you can'sort it. any more. I'm talking daily experience 
here.


Presumably you're talking about some software that you're using that 
can't sort a route that has some roads, a roundabout, and then some more 
roads in it?


What software is this?

It's entirely normal that some routes are "not sortable" in the sense of 
"being made into one linear list", but something like 
http://ra.osmsurround.org/index ought to still be able to analyse them 
OK I would have thought?  I've just tried it on a bus route containing a 
roundabout locally and it coped OK.


Best Regards,

Andy

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Andy Townsend]

On 16/08/2019 08:50, Peter Elderson wrote:

Josm of course. Is there another relation editor that can handle large nested 
route relations spanning up to say 4000 Km?


P2 can, at least.  Other people seem to suggest that iD does a 
reasonable job now too.


The more interesting question, though, is "why do you want walking route 
relations to be sorted".  The point that's already been made about 
routes that use the same way twice is a valid one, but almost never 
applies to walking route relations.  What are you trying to do with e.g. 
https://www.openstreetmap.org/relation/1976184 (the part of E2* that 
runs through Yorkshire) if it's not sorted?


Best Regards,

Andy

* There are actually many other things wrong with that relation. It's 
not signed, so in a since here it "does not exist" but at the very least 
it should be tagged as such.  Also it's actually defined here in terms 
of the Wolds Way (which is signed), not in terms of individual paths.  I 
also doubt that the LDWA is in any sense an "operator".




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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

[Andy Townsend]

On 16/08/2019 20:00, Paul Allen wrote:
On Fri, 16 Aug 2019 at 19:43, s8evq > wrote:



[1] [make it more clear that the walking route has to be signed in
order to map it. As it is stated now, you could read it that a
named hiking route is sufficient to be mapped]


Does it have to be signposted as a walking route?


I've tended to use that as a criterion for inclusion, though there are 
some exceptions already in OSM (Wainright's Coast to Coast is in, for 
example)


Of course, signposted doesn't always mean "signposted very well" :)

Best Regards,

Andy

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Andy Townsend]

On 17/08/2019 07:28, Peter Elderson wrote:


Gpx gaps in some software do show up as straight lines. If it's just a 
missing piece and the rest is in order, no problem. In the case of the 
E2 in Yorkshire, lots of straight lines. Feed that to a navigation 
device and it will have you start in Muston, take you around and 
across the entire region multiple times, and end up near Barnetby Ie 
Wold. You wil actually have followed the E2 as well, I'll give you that!


"Following in the E2 in Yorkshire" would be an odd thing to do as there 
are two parallel legs of it (see 
https://hiking.waymarkedtrails.org/#?map=8!54.1195!-1.3988 ). From the 
Humber bridge one side follows the Wolds Way / Cleveland Way etc. to 
just west of Darlington, and on the other side of the county it runs 
from the Tan Hill Inn down the Pennine Way.  The problem here isn't the 
mapping in OSM, but the decision by whoever created the route to have 
two parallel routes called the same thing.


What you'd logically actually do on the ground, of course is ignore the 
E2 altogether (it's not signed here) and either follow the Pennine Way 
signage or the Wolds Way / Cleveland Way etc. signage.


Best Regards,

Andy




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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Andy Townsend]

> but I would like to see one make a plausible navigation route out of the E2 
> Yorkshire relation as it is now.

Where are you going from and where are you going to?  Without that information 
"make a plausible navigation route out of the E2 Yorkshire relation" makes no 
sense.  

You could certainly argue that splitting the legs of the route rather than the 
"parts geographically in Yorkshire" would make more sense, but making use of 
whole sections of the Wolds Way, Cleveland Way etc. would be better still.  
That's one for you to resolve though, since you're the one who seems to have 
the issue here.

Best Regards,

Andy


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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Andy Townsend]

 You haven't answered the question - I asked "Where are you going from and where are you going to?" in order to try and understand what real-life problem you're trying to solve. "I would like the ways of a relation to be sorted" is not a real-life problem.  What navigation software are you using and (in this example) where are you going from and where are you going to? I'm assuming that (on this imaginary hike through Yorkshire) you're not lugging a PC around running JOSM, trying to shade the screen from the sun on every hilltop so that you can see it, and wrapping it up whenever it starts raining.   Best Regards,Andy   ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Andy Townsend]

> apps like OsmAnd, Garmin devices, and planner applicationsI can answer the Garmin bit of that, as it's something that I do all the time.Firstly, the ability to "follow a GPX" isn't something that most Garmin devices support.  None of the eTrex or GPSMap (walking) or Nuvi (car) models that I've had support it.  I believe that some models designed for cycling do, but let's be honest - you're not going to be cycling along most of the Wolds Way or Cleveland way.  It not just not allowed in places it'd be close to physically impossible.What Garmins do offer is navigation by a series of waypoints, and they'll navigate between those either "as the crow flies" or allow a route that is appropriate for your current travel method.  Although the UI for walking- and car-focused devices are different, the principle is the same.  You'd typically add waypoints along the route manually - either on the device or in something like Garmin's PC software before loading to the device. "waypoints" and "routes" can fit into the same XML file as any GPX tracks you move to and from a Garmin device.When creating maps from OSM data you can also include route membership information on the on-screen map - I usually put the route names in brackets after any way name.  I create different Garmin maps for walking and driving to remove some paths you don't want to drive on or roads you don't want to walk on (or aren't allowed to, based on access tags).As an aside I do tend to create Garmin routes composed of waypoints for guideposts / route markers where I've got that info - it helps to find missing ones, and having guideposts and route markers in OSM helps other people see which bits of route are well signposted and which not.  You may notice that the Wolds Way has a few of these mapped as relation members ("role=marker"); other nearby routes are more complete.To summarise then, I've never found a need to sort the ways in a walking route before being able to navigate it using a Garmin handheld.Best Regards,Andy   ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Andy Townsend]

> You want to do the routing. I want to avoid that, because the routing has already been done. To be clear, I want to navigate from where I currently am to where I want to go.  If a route is blocked (or, heaven forfend, wrong in OSM) I still want to get where I'm going, even if I am not exactly where I thought I should be.> OsmAnd and Garmin should take the route itself, not waypoints to route to. It is odd that OsmAnd cannot navigate me along an ÒSM route that's shown on the map and is readily available from OSM. I'm not sure what the current situation is with OsmAnd, but do know that it's been discussed within the last few months in the OsmAnd Google GeoupWith regard to Garmin, it sounds like you should be submitting a feature request to them - it is unlikely that they monitor OSM's tagging list for those.It does sound, however, that you don't have a concrete use-case at all - you have a view of how things "should" be, but this doesn't seem to be driven by a real-world requirement.  That's why I've been asking for specifics throughout this thread (and Richard has too).Best Regards,Andy   ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Andy Townsend]

On 19/08/2019 17:21, Peter Elderson wrote:
 the only way for the likes of me is to use detection tools and 
maintenance tools to order data by hand at the mapping level, so 
ordinary people can use waymarkedtrails to get usable linear gpx-s for 
their basecamps, route editors, trip planners, navigation apps and 
devices.


You keep perpetrating this myth - you're suggesting again that ways in 
routes need to be sorted before they can be used in Garmin software and 
navigation devices.  It simply isn't true.  For about 11 years now I've 
been creating Garmin maps based on OSM data, and I've been walking along 
local and national trails in the UK for far longer.  Never have I needed 
to "follow a GPX" - it seems a very alien thing to want to do, and (as 
mentioned previously) isn't actually supported by any of the various 
Garmin hiking GPSs that I've used.  If you want to do that - fine - but 
not everyone does.


I suspect that "Ordinary people" will just download OSM maps from 
http://garmin.openstreetmap.nl/or one of the alternatives - they'll see 
the route on-screen and they will navigate using that.  Sometimes 
they'll stray from it because they've arranged somewhere to eat or stay; 
they're not limited to "only walking along the actual ways that form the 
official route" which you seem to be.


If you have a different requirement then that's very much a personal 
requirement for you; please don't try and dissuade "ordinary people" 
from contributing to mapping hiking routes.  If you want to manually 
sort and rearrange hiking route data in a way that doesn't prevent 
everyone else from contributing that's also fine, but please don't raise 
the bar to contributions so high that people can't contribute at all. 
You'd essentially be filling the role that Kevin Kenny identified above 
as "Someone in the community who can handle relations will then have the 
geometry already established, so tidying the topology becomes a clerical 
task".


The people we want adding hiking routes to OSM are people who've just 
taken their boots off, know where routes have been diverted, and know 
what the surface tags etc. should be, not people who've never emerged 
from behind a PC.


Best Regards,

Andy

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

Re: [Tagging] Signposts in Roles of route members

[Andy Townsend]

On 19/08/2019 09:50, Volker Schmidt wrote:
Let me also introduce a further complication in the "sorting" 
discussion for hiking and cycling route relations.
Some mappers like the idea to keep signposts in the same route 
relation as the ways making up the route.


By way of example, here's one near me:

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

The method for mapping the signposts is not quite the same as the CAI 
page.  Signposts are mapped as either guidepost (see e.g. 
https://www.openstreetmap.org/node/5894712185 ) or route_marker ( 
https://www.openstreetmap.org/node/5734015420 ) depending on what form 
the route marker takes.  Each has the role "marker" within the relation.


Best Regards,

Andy


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

[Tagging] Garmin waypoints and routes (was: "Roles of route members" and before that "Merging tagging scheme on wiki pages of Hiking")

[Andy Townsend]

On 19/08/2019 19:04, Peter Elderson wrote:


Ok, I accept I just don't know how it's done. So how is that done? How 
do I tell my Garmin to guide me along, say, the Limes trail through 
the Netherlands?


Essentially, you'd just look at the screen and follow that!  I tend to 
use waypoints for an idea of things like "how long will it be until I 
get to where I'm going to stop for lunch", not for "turn left here 
because route XYZ turns left here", because you can see on the screen 
that route XYZ "turns left here".


If you want to add a series of waypoints and route along those then you 
can, but want you can't typically do with one of the hiking-oriented 
Garmins is follow a particular feature.  You could create an OSM-based 
Garmin map that forced a device to route along a trail at the expense of 
any other paths, but I certainly wouldn't want to do that as it would 
stop me from leaving the trail to eat in a nearby town.


Creating a Garmin route from a GPX file is possible, but probably 
impractical, as you'd need to restrict the number of points. Apparently 
my GPSMap 64 supports 200 routes with 250 points per route, and up to 
5000 waypoints in total.


Where Garmin on-device routing is really useful is for when you need to 
get to somewhere but don't have an on-screen route to follow - for 
example if the weather's turned and you need to abort a previously 
planned route and get another route to your destination from where you 
currently are.  It's also useful where there are natural obstacles like 
rivers, where the distance on foot may be significantly more than the 
as-the-crow-flies distance.


Best Regards,

Andy


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

Re: [Tagging] bear box in campground ?

[Andy Townsend]

On 21/08/2019 19:03, Mark Wagner wrote:

On Wed, 21 Aug 2019 11:44:41 -0600
Rob Savoye  wrote:


   Many western state campgrounds have metal bear proof food storage
boxes in each campsite, but not all of them. At certain times of the
year this can be important. :-) Around here the bears will destroy
your car if there is food left inside. I see zero instances of this
type of data, at least not in Colorado. My guess would
'amenity='bear_box' ? (looking at amenity=bbq as an example)

That's how I've mapped the five I've added to the map.


A quick search of taginfo suggests that as the best option - try 
https://taginfo.openstreetmap.org/tags/amenity=bear_box and variations.


Best Regards,

Andy



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

Re: [Tagging] [OSM-talk] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

[Andy Townsend]

On 25/08/2019 23:18, Joseph Eisenberg wrote:

What should we do with a page like Tag:landcover=dunes? I already
tried adding a mention that natural=dune was more common and mentioned
on the Talk page that "dune" is a landform, not a landcover, but this
was reverted.


I'd be tempted to set a redirect to the key that people actually do use 
for mapping that feature.  That's what seems to have happened wih 
https://wiki.openstreetmap.org/w/index.php?title=Landcover%3Dhedge&action=history 
.


In this case, with literally 0 uses of the tag that this page allegedly 
documents, it seems like the best option.


Best Regards,

Andy



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

Re: [Tagging] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[Andy Townsend]

On 29/08/2019 15:52, Peter Elderson wrote:

LS
With the arrival of cycling node networks, the Dutch, German and 
Belgian mappers decided to claim (hijack)  the network value rcn for 
those node networks. This exception was copied with the claim of 
network=rwn for the walking node networks.


Would it be possible to try and describe in a bit more detail what has 
happened, without using judgmental terms such as "hijack"?  I'd start 
with a link helping people understand what a "cycling node network" is.


Can you give an example of a "normal" rcn and a "node network" that 
someone has tagged as an rcn and explain what the problem is with this 
tagging?


Best Regards,

Andy




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

Re: [Tagging] Draft proposal for Key:aerodrome

[Andy Townsend]

On 10/09/2019 08:35, Joseph Eisenberg wrote:

It would deprecate aeroway=airstrip and aerodrome:type=*


That seems like a bad idea because aerodrome:type is one of the ways 
that mappers distinguish between military and non-military airfields.


That, combined with whether the object has an iata code or note is 
useful for deciding whether something is what a normal person would 
describe as an "airport" or not:


https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L4812

Best Regards,

Andy



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

Re: [Tagging] Draft proposal for Key:aerodrome

[Andy Townsend]

On 10/09/2019 11:28, Joseph Eisenberg wrote:

That seems like a bad idea because aerodrome:type is one of the ways
that mappers distinguish between military and non-military airfields.

military=airfield + landuse=military is the standard way to do this.


I wasn't making any comment about what may or may not be the "standard" 
way to do this; just saying that aerodrome:type is one of the ways that 
mappers distinguish between military and non-military airfields.


Compare:

https://overpass-turbo.eu/s/McF

https://overpass-turbo.eu/s/McE

https://overpass-turbo.eu/s/McG

You'll notice that in that area (and I'm sure elsewhere) that there are 
edge cases - "military=airfield + landuse=military" won't exclude 
Cambeltown, which has the old IATA code in OSM but isn't currently 
landuse=military.


You didn't mention military at all in your initial email, which seems 
like an omission.


Best Regards,

Andy



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

Re: [Tagging] [Key:phone] - Suggesting wiki page changing

[Andy Townsend]

On 22/09/2019 11:20, Andy Mabbett wrote:

On Sat, 21 Sep 2019 at 19:49, Valor Naram via Tagging
 wrote:


I want to change the wiki page
https://wiki.openstreetmap.org/wiki/Key:phone throw a Proposal process
to do certain things:
   - Protecting the wiki page against "wild changes"

We generally do not protect Wiki pages unless they are the target of
persistent or egregious vandalism.


Well, sort-of - what tends to happen is that pages that "really 
shouldn't be modified" tend to get moved elsewhere. 
https://wiki.openstreetmap.org/wiki/Tile_usage_policy is an example of 
that.  There are some things that OSM's wiki really isn't the 
appropriate place for.


Best Regards,

Andy

PS: For the avoidance of doubt I'm not suggesting that such a move would 
make sense here.




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

Re: [Tagging] Default values for surface by road category and country

[Andy Townsend]

On 23/09/2019 09:14, Volker Schmidt wrote:




every mapper can set his own, as you doe and I do, but this
means that a router has to second guess what people think is
standard use in different countries.

That is exactly how it works.
In general, tagging surface is almost
always good idea or at least nice to do.

But this very unsatisfactory for routing. Two examples:
If I hire a rental car in the US, the contract ays, that I cannot use 
unpaved roads.
If I use  bicycle anywhere I would like to be able to instruct my 
router to avoid unpaved roads.


Ultimately, where information is missing, you as a data consumer will 
need to make a decision about whether or not a road is likely to be 
paved or not.


Adding a default (even per-country) won't magically make all 
non-surface-tagged roads paved or unpaved, and where data has come from 
import (e.g. TIGER in the US) or imagery (e.g. many places in Africa, 
Australia, etc.*) it isn't always possible to tell what the surface is 
when first adding to OSM.


Best Regards,

Andy

* and also some areas in the UK, where data was taken from OS OpenData 
before imagery/surveys were available - 
https://www.openstreetmap.org/#map=15/53.8724/-1.1287 being one such 
example.


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

Re: [Tagging] Was there every a proposal for the disused:key=* / abandoned:key=* lifecycle prefixes?

[Andy Townsend]

On 26/09/2019 16:48, Richard Fairhurst wrote:

Paul Allen wrote:

BTW, that's on national cycle route 82, so whether or not it really is
a pub would be of interest to some mappers.

Oh, has that closed? That's a shame. (I stayed in St Dogmaels a few years
ago, thought the Castle Inn looked wonderfully old-fashioned, and was
planning to go but was diverted by some other excellent pubs nearby. Not
least the one in St Dogmaels itself which served Gwynt y Ddraig Black
Dragon. I'd hoped to return one day... ah well.)


Mapping it as amenity=pub + disused=yes would (if carto
is consistent with other times I've tried disused=yes) render it as a pub
where disused:amenity=pub does not render it as a pub.

Sure, but OSM isn't just about rendering, let alone just osm-carto
rendering. A "find a pint of beer near me" app which does a proximity search
for amenity=pub won't work very well if some of those pubs... aren't pubs.

amenity=pub means "actually a pub", not "thing that looks like a pub".


https://map.atownsend.org.uk/maps/map/map.html#zoom=20&lat=52.0802094&lon=-4.660442

Works for me.  I might be tempted to keep the "name" set (or perhaps 
"old_name") if there's still a sign outside, since I think it's 
reasonable to think of that as the building or old pub name.


Cheers,

Andy



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

Re: [Tagging] Was there every a proposal for the disused:key=* / abandoned:key=* lifecycle prefixes?

[Andy Townsend]

On 26/09/2019 17:09, Markus wrote:


Thus, those disused toilets could be tagged:

disused:building=toilets

No, it's still a building.  "building=toilets" means that the type of 
the building was "toilets".  It doesn't say anything about whether it 
was a usable amenity or not.



and separately

was:amenity=toilets

Well, "disused:amenity=toilets" is > 10 times more popular. See 
https://taginfo.openstreetmap.org/search?q=disused%3Aamenity%3Dtoilets 
and https://taginfo.openstreetmap.org/search?q=was%3Aamenity%3Dtoilets .


Best Regards,

Andy




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

Re: [Tagging] Cycling relation misuse

[Andy Townsend]

On 11/10/2019 12:51, Mateusz Konieczny wrote:


11 Oct 2019, 12:37 by rich...@systemed.net

(I have a fair few lines of code in cycle.travel's rendering and
routing
codes to blacklist certain routes in OSM which are made up or
otherwise
unsuitable.)

Can you list made-up lines that pollute OSM?

(I'm not Richard and these aren't cycle routes but) I've recently set a 
couple of walking routes to "name:signed=no" based on walking 
significant portions of them and never seeing a sign:


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

Incomplete "The Inn Way"; appears to be from an out of print book.

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

"Three Feathers Walk (Kilburn)", original source unclear but listed at LDWA.

I did wonder whether it was worth asking on talk-gb whether they should 
be deleted, but didn't bother in the end.



A couple of other examples that I have not seen signage for are:

https://www.openstreetmap.org/relation/7336319 (Wainwright's Coast to Coast)

https://www.openstreetmap.org/relation/1996318 (Lyke Wake Walk)

I was the last editor of both of those (editing path changes around Chop 
Gate), but only saw waymarks for the Cleveland Way. The second of these 
predates many of the national trails, the first is as well established 
as and probably walked more than many national trails.  Both are now 
much more than just "a favourite walk" or "something somebody created to 
sell a book".


Best Regards,

Andy


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

Re: [Tagging] How to tag pedestrian lanes?

[Andy Townsend]

On 21/10/2019 14:14, Paul Allen wrote:


(for the kerb separated way, no idea about the marking separated way)


Me neither.  I'm not sure we have them.



They do exist - I believe that 
https://www.openstreetmap.org/way/172228211 (or one of the sections to 
the north) is or was like that.  Haven't been there for a while though.


Best Regards,

Andy


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

Re: [Tagging] Hunting stands, bird and wildlife hides

[Andy Townsend]

On 22/10/2019 15:36, Ilya Zverev wrote:
For some reason people don’t write its purpose on a side. And again, 
images in three of these pages are the same.


This probably varies around the world, but I suspect in many places the 
intended use is pretty obvious (if not actually written on the side, 
which it would be in the UK).  Like with many other tags, you need to 
map to the best of your knowledge.  If you pick the wrong one someone 
can always correct it later.


Best Regards,

Andy



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

Re: [Tagging] amenity=hospital on things that are not hospitals - is it a good idea?

[Andy Townsend]

On 28/10/2019 10:11, marc marc wrote:

Le 28.10.19 à 09:44, Mateusz Konieczny a écrit :

"sign having a hospital icon and no name can simply be tagged
type=destination_sign + amenity=hospital"
https://wiki.openstreetmap.org/wiki/Relation:destination_sign

Yes it's horrible

the next line said destination:symbol=hospital
it's better.


There are only 12 in the database (Germany / Italy / Denmark):

https://overpass-turbo.eu/s/Nuz

so removing the offending line from the wiki and changing the data 
shouldn't be too difficult to do manually.  There are 69 if you include 
other amenities such as "school".


Best Regards,




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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Andy Townsend]

On 05/11/2019 13:00, Mateusz Konieczny wrote:

I just created https://wiki.openstreetmap.org/wiki/Tag:bicycle%3Ddismount
to document why it is used and why it is anyway duplicate of bicycle=no.

On the page I claim that
"In some places it is illegal to both ride and push bicycle,
there is no good tagging scheme to indicate it."
and I want to check is it correct.


... "where it is legal to go on foot" is an important proviso.

https://www.openstreetmap.org/way/65663472 (Meir Tunnel, dry even on a 
wet Wednesday in Stoke*) bans foot and bicycle traffic, so you can 
neither walk nor cycle through it.  A cycle router would have to 
flat-out avoid it, whereas it may choose not to avoid a short 
bicycle=dismount section if it saves a long detour.


Best Regards,

Andy

* in English football, a "wet Wednesday in Stoke" is thought of as an 
occasion when a top team's star players may struggle in adverse 
conditions that the home side are used to.



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

[Tagging] Traffic Signs (was: Re: Is there a good way to indicate "pushing bicycle not allowed here"?)

[Andy Townsend]

On 07/11/2019 10:26, marc marc wrote:

Hello,

Le 06.11.19 à 19:55, Mark Wagner a écrit :

There are places like federal Wilderness Areas in the United States
where possession of a bicycle is forbidden

can you share the a picture of this traffic sign ?

As an aside, it's worth mentioning that the idea that you can uniquely 
identify a type of access by the traffic sign for it is something that 
isn't universal outside continental Europe.  For example, in the case 
that Richard referred to earlier in England and Wales where a local 
council has an interpretation of the legal rules on public footpaths, 
you won't see a unique sign that identifies "you can't cycle here".  You 
will usually see signage of the legal "public footpath" status (but not 
always, and what there is varies around the country) and you also do 
have paths around the country with that legal status where it is 
positively encouraged to ride a bike.


Essentially, there may be a sign, but you can't infer that cycling is 
prohibited there, you can only infer that you can't assume that it is 
legal.


My experience of the US is much less, but what I would say is that 
signage there is more likely to be just text, and that text may be 
complicated.  Parking signs are an example of this (and a bit of a trope 
there - see e.g. 
http://www.mikeontraffic.com/wp-content/uploads/2014/04/parking_regs.gif ).


Best Regards,

Andy



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

Re: [Tagging] Traffic Signs "pushing bicycle not allowed here"

[Andy Townsend]

On 07/11/2019 13:39, marc marc wrote:

Le 07.11.19 à 14:01, Andy Townsend a écrit :

you won't see a unique sign that identifies "you can't cycle here"

an good practice rule is "don't map the legislation", isn't it ??


If you can infer defaults from legislation, sure, but as has previously 
been said you explicitly can't do that here.




no sign ? thus no tag on the way


Er, no.  As I was trying to say, you can't rely on (official) traffic 
signs  everywhere in the world.  Sometimes you need to infer access 
rules.  If I see a locked gate and a picture of a rottweiler, I'll map 
the driveway behind it as "access=private". You may disagree, but I'll 
let you deal with the rottweiler.




at most a default value in the wiki or on the boundary.


That may be technically correct in some cases, but isn't always a good 
idea.  To take an example I recently mapped, strictly speaking the 
access tags on https://www.openstreetmap.org/way/263486696 really apply 
to https://www.openstreetmap.org/way/738985023 (the full extent of which 
remains unmapped), but having access tags on a surrounding area isn't 
where any data consumer is going to expect to find them.  They do of 
course apply to the track (so what is mapped is not wrong - just not 
complete).


Best Regards,

Andy



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

Re: [Tagging] How to tag Seveso sites ?

[Andy Townsend]

On 08/11/2019 09:44, Shawn K. Quinn wrote:


My first guess is it's at least roughly analogous to a Superfund site in
the US.


That's what I thought at first reading too, but perhaps its meant more 
to describe somewhere where a disaster might happen rather than one 
where one already has?


The local regulations in the UK for that are known as COMAH (see 
https://www.hse.gov.uk/comah/ ).


I didn't use any specific COMAH tagging for my local site 
https://www.openstreetmap.org/way/334238388 , but would be happy to add 
something if a consensus emerges.


Best Regards,

Andy



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