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] 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] 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] 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] 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=prev=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

[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=revision=2368644=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=revision=2371288=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=revision=2371288=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] 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=revision=2504680=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

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] 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=view 
are the same person.


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] [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 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 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] 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 - 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] [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 - 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] Homogenize diplomatic tags

[Andy Townsend]

riven "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] 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] 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] 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] 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 - 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] coastline v. water

[Andy Townsend]

Hi,

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

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

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

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

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

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

Opponents of the change have said, among other things:

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

The possible solutions to this issue are:

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

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

* the polygons that have been created will not be removed

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

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

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

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

Best Regards,

Andy Townsend, on behalf of the Data Working Group

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

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

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

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

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] 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] 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] 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 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] 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] 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=54.051964=-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] 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] 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

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

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

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] 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 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] 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] 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] 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] [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] 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] Reviving the path discussion - the increasing importance of trails in OSM

[Andy Townsend]

On 22/05/2020 15:55, Daniel Westergren wrote:
And there actually seems to be a pull request finally solving the 
paved/unpaved rendering that was opened 7 years ago?!? 
https://github.com/gravitystorm/openstreetmap-carto/pull/4137


If that makes it to the default map it will certainly help people to 
tag surface, because they will see that it makes sense.



I'm sure you didn't mean it to sound like it, but this does read 
somewhat as if rendering "surface" on paths is somehow "obvious" and 
"easy", and it's an "oversight" that the OSM Carto folks haven't been 
doing it since basically forever.


It's not - I think that pnorman's comment of 
https://github.com/gravitystorm/openstreetmap-carto/pull/3399#issuecomment-596656115 
still applies:


> I'm of the opinion that the only way we can get the cartographic 
"space" to render unpaved surfaces is to drop something else, like 
access restriction rendering.


I think that there's another problem with the standard style as well - 
aside from surface rendering it's hugely biased towards urban centres.  
Looking at https://www.openstreetmap.org/#map=13/53.9023/-0.8856 you 
can't see any paths at all at that zoom level due to the "Central 
European Graveyard problem" - compare with 
https://map.atownsend.org.uk/maps/map/map.html#zoom=13=53.9006=-0.8795 
to see what you're missing.


What we need are concrete suggestions of how to get there from here, 
(and Ture Pålsson's mail of 
https://lists.openstreetmap.org/pipermail/tagging/2020-May/052747.html 
is exactly the sort of thing I'm looking for).


Adding a sane surface rendering in addition to everything else is hard - 
I've not managed it across the board at https://map.atownsend.org.uk 
although that is influenced by sac_scale, trail_visibility and width.  
All suggestions gratefully received, but what's needed some code that 
people can play with and see what the effect is on various areas and 
different zoom levels - not just emails to the tagging list*.


Best Regards,

Andy

* yes, I do realise the irony of "yet another email to the tagging list"!

 75  Tag:amenity=motorcycle_taxi not approved
 58  Remove non-prefixed versions of 'contact:' scheme
 49  RFC ele:regional
 42  relations & paths
 35  Doorzone bicycle lanes
 34  Permanent ID/URI --- off topic email
 28  Feature Proposal - RFC - Recreational route relation roles
 27  Reviving the path discussion - the increasing importance of 
trails in OSM




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

Re: [Tagging] Feature Proposal - RFC - Recreational route relation roles

[Andy Townsend]

On 21/05/2020 13:48, Mateusz Konieczny via Tagging wrote:




May 21, 2020, 14:17 by kevin.b.ke...@gmail.com:

It's still tricky. Around here, few trails are actually signposted;
some don't have a sign anywhere! They're marked with paint blazes in
the woods, guideposts in the fields, and cairns above the tree line.

Not a native speaker, but I thought that paint blazes,
guideposts, cairns, signs, surface markings, special traffic signs,
information boards, markings by cutting on trees, ribbons,
wooden poles etc all may be used to signpost a trail.


My 2p from England:

I suspect it'd vary around the world but I'd certainly say "that trail 
is signposted" if all there was was a characteristic paint blaze that 
"everyone recognises" as matching a particular trail.


Best Regards,

Andy



___
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 21/05/2020 10:50, Mateusz Konieczny via Tagging wrote:



Similarly anyone creating
highway=footway + danger="you will be shot" + "access=no" + foot=yes"
should probably switch to pickpocketing, telemarketing or other less 
harmful activity.


While "danger" isn't a much used tag (and I'm sure wasn't a serious 
suggestion here - https://taginfo.openstreetmap.org/keys/danger#values 
), sometimes "foot=yes" is correct and other tags need to be taken into 
account.  I've used the area around 
https://www.openstreetmap.org/way/431056034 as an example of that 
before.  Here "foot=yes" is correct - there is a legal right of access.  
"sac_scale =demanding_alpine_hiking" also makes sense here I think.


I take Frederik's reference to Andy Allan's point about "a 
multi-billion-dollar-revenue organisation that were rendering anything 
with a highway tag the same as their most minor road style" but frankly 
there's simply no solution to that - presumably "highway=dangerouspath" 
(to make up a nonsensical value) or 
https://taginfo.openstreetmap.org/tags/highway=via%20ferrata would still 
get shown as a "road".


Map styles need to be clear about what they're showing and what they're 
not showing and people using maps need to be able to read maps so that 
they understand what they're being told.  This isn't really a tagging 
issue, unless OSM mappers aren't using appropriate other tags when they 
should (sac_scale, trail_visibility, surface, etc.)


Best Regards,

Andy


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

Re: [Tagging] relations & paths

[Andy Townsend]

On 15/05/2020 12:28, Paul Allen wrote:
On Fri, 15 May 2020 at 03:21, Mateusz Konieczny via Tagging 
mailto:tagging@openstreetmap.org>> wrote:



Any signed route may be mapped as a route relation.


Depends how broadly or narrowly you define "signed route."


And sometimes signed route will be signed with paint markings on
trees,
or by piles of rocks or by some other method rather than be a sign.


That's a pretty broad definition.  Which is fine by me, because it 
definitely

includes footpaths, bridleways, restricted byways, and BOATs in the UK.
England and Wales have specific signs for such things:
https://www.simplyhike.co.uk/blogs/blog/a-guide-to-footpath-signs-in-england-and-wales
Scotland and Northern Ireland also have signs for these things, but 
they're different

from the ones in England and Wales.

It's probably worth an explanation of "BOATs etc."* for a non-local 
audience.


A "public footpath" is a particular legal designation in England and 
Wales.  It means that, in addition to any other legal rights you might 
have, you're allowed to go from A to B on foot.  These have reference 
numbers (that may actually vary from parish to parish).  An example that 
I'm familiar with is "Ilkeston FP 81" https://overpass-turbo.eu/s/U2f .  
That's made up of 22 different ways on the ground (different surfaces, 
bridges, that sort of thing). It's not in itself a "route" of any sort - 
it's just an attribute of the underlying ways.  There is no 
on-the-ground signage of "Ilkeston FP 81".


That approach to tagging works in the UK because, generally speaking, we 
don't have overlaps of either prow_refs or FWIW highway refs.  In the US 
and countries where route numbers can overlap it would make sense to map 
these as relations in OSM, but here it doesn't, because they don't.


Those 22 ways in OSM are also part of "Erewash Valley Trail" 
https://www.openstreetmap.org/relation/1458963 .  That is a route, and 
it's signed on the ground as such.  Data consumers are then able to use 
that data and present it to users in an appropriate format.  As an 
example, 
https://map.atownsend.org.uk/maps/map/map.html#zoom=17=52.997594=-1.30515 
:


 * Has the prow_ref in black in brackets because they're not typically
   signed
 * Has purple dots for the walking route relation
 * Has the walking route relation name not in brackets because it is signed

Best Regards,

Andy

* "byway open to all traffic"


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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Andy Townsend]

On 08/05/2020 14:04, s8evq wrote:
And then some people in this very thread suggest to just ignore a 
rejection and start using it anyway. What's the use of the whole 
voting system then? 


Frankly, not much.


Why even bother writing a proposal in the first place? I'll just do 
whatever.


"I'll just do whatever" is why OSM succeeded and other approaches 
failed.  "I'll just do whatever" allows people to just add stuff to 
their neighbourhood _right now_, which they can't if they have to 
consult a committee beforehand.*


That said, it _does_ make sense to discuss what is the best way of 
tagging a particular real-world object - and it also helps if the people 
discussing it have actually seen one of those in the real world (as was 
previously suggested, I doubt some of the "no-voters" have).


In this case clearly not all the people in favour of adding a subtag to 
"amenity=taxi" could be persuaded that it was a bad idea, but since they 
are never likely to encounter such a feature in their everyday lives 
their data is not likely to matter.  OSM should be built be people who 
are familiar with the objects that they are mapping, not people guessing 
from afar.


Best Regards,

Andy

* OSM vs (say) wikimapia isn't the only example of this - wikipedia / 
nupedia is another more famous one.  Elsewhere way back in the 1980s and 
1990s the company I was working for was telling people that a 
statistical approach to fault diagnosis was a better approach to trying 
to diagnose and fix electronic stuff than an "Expert Systems" approach - 
essentially having someone coming in and trying to design some rules 
based on a few hours "sitting with Nellie".  The statistical approach 
won out, allowing you to read this message easily in your inbox, with 
the Bayesian spamfilter having moved all the undesirable stuff into 
"junk"**.


** but not in electronics, unfortunately, as no-one repairs that any 
more - it's (currently ) cheaper to buy more stuff from 
$low_wage_economy elsewhere.




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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Andy Townsend]

On 03/05/2020 17:13, Joseph Eisenberg wrote:
The deprecation was not discussed, and it was not done by anyone at 
OpenStreetMap Carto, BTW.


Er - wasn't that 
https://github.com/gravitystorm/openstreetmap-carto/pull/3619 ? You 
commented in the discussion there...


Best Regards,

Andy



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

Re: [Tagging] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Andy Townsend]

On 03/05/2020 16:12, Jean-Marc Liotier wrote:


So, this discussion gravitates towards using landuse=common for those 
African urban freely accessible multipurpose open spaces, which I 
fully support.


Just to be clear you've said "landuse=common" above but "leisure=common" 
below?




Implementing this change requires the following actions:

- Editing the leisure=common wiki page, in French and in English (I'll 
do that)


- Reinstating the rendering of leisure=common in downstream 
cartographic styles, would be even better if the color matched the 
surface=* so that sandy surfaces don't appear green.


Each cartographic style will have its own sorts of things that it wants 
to show, and I can fully understand some of them thinking that 
"leisure=common" isn't something that they want to show. You'll be able 
to submit pull requests to those that are in github, but there's no 
"automatic right of feature X to be shown".


With regard to the second bit, I'd be happy to accept a pull request at 
https://github.com/SomeoneElseOSM/SomeoneElse-style that did that (it'd 
be about half a dozen lines of lua).  Setting up a map server based on 
that is pretty straightforward - it's set out in 
https://wiki.openstreetmap.org/wiki/User:SomeoneElse/Ubuntu_1804_tileserver_load 
which in turn is very similar to 
https://switch2osm.org/serving-tiles/manually-building-a-tile-server-18-04-lts/ 
.  Server costs would be significant on an average salary in Mali (a 
day's wages per month or so?) but much less so on an a European or North 
American one (perhaps a cup of coffee-shop coffee every few days).



- Reinstating the rendering of leisure=common in JOSM's default style 
(it recently changed to grey to mark deprecation). (I'll open a JOSM 
ticket


- Altering QA rules (JOSM Validator and Osmose) so that the 
leisure=common deprecation only applies to the United Kingdom of Great 
Britain, where commons have a legal definition and designation=common 
must be used for them. (I'll open a JOSM ticket but if someone has 
prior experience interacting with the Osmose people, that would be nice)


Actually, I'd suggest that "leisure=common" was perfectly valid in the 
UK too.  Back in 2017 it was misused as a tag in the UK but now it 
mostly isn't; I added it back in to the style that I maintain for 
UK/Ireland this year.  Obviously "designation", if known, makes sense too.


Best Regards,

Andy



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

Re: [Tagging] natural=water inside natural=wetland

[Andy Townsend]

On 30/04/2020 19:09, Paul Allen wrote:
On Thu, 30 Apr 2020 at 18:45, Andy Townsend via Tagging 
mailto:tagging@openstreetmap.org>> wrote:


There are always going to be edge cases that aren't easy to
categorise.  There's an area just up the road from where I am
currently that started out as
https://www.openstreetmap.org/way/13866095


That's coming up as deleted 6 years ago by Yorvik Prestigitator.  Typo?

No - follow the history forward and you'll get to 
https://www.openstreetmap.org/way/796675406 .  I was doing some tidying 
up of the fence, woodland and ditches at 
https://www.openstreetmap.org/changeset/84161134#map=19/54.02644/-0.99852 
a few days ago and the object "moved" to a new ID.  For convenience it 
would have made sense to link to that as well, obviously :)


Best Regards,

Andy


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

Re: [Tagging] natural=water inside natural=wetland

[Andy Townsend via Tagging]

On 30/04/2020 16:29, Joseph Eisenberg wrote:

> wetland area within a forest where trees are growing also within the wetland 
area

That’s a “swamp”: natural=wetland + wetland=swamp

https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dswamp


... or it might be seasonal or intermittent, depending on the weather.

There are always going to be edge cases that aren't easy to categorise.  
There's an area just up the road from where I am currently that started 
out as https://www.openstreetmap.org/way/13866095 in 2007 and has been 
continuously refined ever since.  The main area's mapped as 
natural=heath now (and that's probably as good a bet as any for what 
"most of it" is), but there are areas that are wetter than others and 
areas that are drier; and areas with more trees and areas with fewer 
trees.  There are some permanent ponds but many more "it'll only be wet 
here N months of the year", where N might be anything between 2 and 11.


Any attempt to draw lines between "wood", "wetland" and "water" is a 
compromise, and to me it's perfectly understandably to sometimes have 
those overlapping (though in the example above it is something I've 
tried to avoid).


Best Regards,

Andy


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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Andy Townsend]

On 30/04/2020 12:10, Peter Elderson wrote:
Seems to me that a "common" is an adequate word for such a place, so 
=common would be right.



That makes sense to me as well.


What key to use? I think it's a use of the land. Actual use can vary, 
may be leisure, may be commerce, may be parking, maybe events.

Size may vary. Surface may vary.

landuse=common makes most sense to me.
name, surface, access etc could be added when applicable.

That's currently one of the keys used at 
https://taginfo.openstreetmap.org/search?q=common#values but far from 
the most popular.


How about "leisure=common"?

Best Regards,

Andy



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

Re: [Tagging] Implied default access tags for barrier=stile?

[Andy Townsend]

On 26/04/2020 22:15, Philip Barnes wrote:

On Sunday, 26 April 2020, s8evq wrote:

Hello everyone,

Are any default access tags implied with barrier=stile?
Similar to barrier=bollard 
(https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dbollard mentions
"By default access=no, foot=yes, and bicycle=yes is implied")


That wiki page seems to be considering an access tag as controlling 
_physical_ access rather than _legal_ access.  With the exception of 
"wheelchair", access tags in OSM mostly describe legal access, I believe.


Obviously in most cases the two match ("people aren't allowed to drive 
here so I'll stick a bollard in the road to stop them").




If it's on highway=footway, is foot=yes still needed on the barrier?

What if the barrier is on a highway=footway + bicycle=yes? Should the barrier 
itself have foot=yes, bicycle=no or bicycle=dismount ?


A stile should not exist on a way on which it is legal to ride a bike, unless 
as often happens on bridleways there is a stile beside a gate to save walkers 
having to open and close the gate.


I suspect that a bit of context is needed here, and the answer would 
depend on which country we were talking about (and, in the case of at 
least the UK and Germany, which region of that country).


Taking England and Wales as an example, when Phil says "bridleway" I 
suspect he's referring to the England-and-Wales concept of a "public 
bridleway" where people using certain modes of transport (foot, horse, 
bicycle) have a legal right of access, rather than the OSM tag 
"bridleway" ("a way intended for use by horse riders") .  They're 
historical legal rights, and for whatever reason often the path can 
degrade so that they're no longer usable by cyclists (or horse riders or 
pedestrians for that matter).  Any of that happening doesn't mean that 
cyclists aren't legally allowed to use them.


Back to the original question, I'd assume (as Paul humorously replied) 
that barrier=stile implies "bicycle=dismount" from a practical if not a 
legal point of view.  It might be worth having a look at stiles where 
you are to see if any other tags would be useful (the "stile" and 
"step_count" tags might be helpful in thinking whether you physically 
can't get a bike across there, or you'd be able to lift it over).



It would certainly make me question the validity of the bicycle=yes.


I've certainly seen examples from long ago in OSM (in England) where 
people were using bicycle=yes where there was no legal access, but I 
suspect that it's less common nowadays.  I can think of quite a few 
places that are "bicycle=permissive" (tolerated, but no legal access), 
where you'd need to negotiate any barriers on your own terms with no 
guarantee of physical access.


Best Regards,

Andy



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

Re: [Tagging] Feature Proposal - RFC - Urgent Care

[Andy Townsend]

On 05/04/2020 16:36, Joseph Eisenberg wrote:

Can someone confirm if "urgent_care" makes sense in British English,
rather than "walk-in" or something else?

I'm English, and I would not know what "urgent_care" meant. After 
reading the wiki page, it is unclear whether refers to designated 
walk-in centres, or the "accident" end of "accident and emergency", or 
any other healthcare providers that offer non-appointment access?


Best Regards,

Andy


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

Re: [Tagging] iD semi automatic adding public_transport to aerialway=station

[Andy Townsend]

On 31/03/2020 15:08, Gegorian Hauser via Tagging wrote:
I also opened yesterday a issue on the github site from iD but this 
was closed imediatly because of "there is nothing written in the Wiki"



https://github.com/openstreetmap/iD/issues/7491 I guess?

If the consensus here is that the approach that iD is taking isn't 
ideal, then I'd suggest updating the wiki to match the consensus here 
(cross-referencing the mailing list discussion), then suggesting that 
the iD issue be looked at again in the light of the discussion here and 
the (newly updated) wiki.


Best Regards,

Andy


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

Re: [Tagging] Route names that aren’t names

[Andy Townsend]

On 28/03/2020 19:16, Cascafico Giovanni wrote:


Well, if somebody takes care of rendering [1] OSM data structure, 
situation doesn't look so bad.


[1] https://cycling.waymarkedtrails.org/#routelist?map=10!54.7983!-1.3075

 Not really - that's just ignoring names on the main map and showing 
superrelation names on the right in a separate legend. Try figuring out 
from 
https://cycling.waymarkedtrails.org/#routelist?map=11!53.1028!-0.8416 
which "NB" is which without using the mouseover highlight.


I ended up having to code specifically for the data (something you 
couldn't do internationally). 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L6170 
means that at 
https://map.atownsend.org.uk/maps/map/map.html#zoom=14=53.09613=-0.9523 
route 645 just gets a ref but "National Byway (Southwell Loop)" gets a 
name, so that you can see at 
https://map.atownsend.org.uk/maps/map/map.html#zoom=15=53.13343=-0.84475 
which one is which.


Interestingly I'd say that 
https://www.openstreetmap.org/relation/1425019 is actually named 
correctly. although a quick look at the route suggests that the "phantom 
mergers" have been at it again. :(


Best Regards,

Andy





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

Re: [Tagging] Number of route relation errors very much reduced

[Andy Townsend]

On 23/03/2020 10:38, Peter Elderson wrote:


I am very happy to report that my current check finds very few 
integrity errors, and the few I see are not caused by using a specific 
editing tool. Compliments to the "ID-people", you have done it!




Great!


This does not mean ID is now a good route editor. Sorry guys, 
but for serious route maintenance JOSM still is the only option!



Er, what?  This seems completely at variance with what you just said 
above!  Also, I'm not sure what those of us who mainly use neither iD 
nor JOSM* are supposed to think - maybe we don't exist...


Best Regards (not entirely seriously),

Andy

* Potlatch and Vespucci, for info


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

Re: [Tagging] Ponds are not observable on the ground

[Andy Townsend]

On 19/03/2020 13:15, pangoSE wrote:


Hi

IMO pond should not be mapped because it is not observable on the 
ground. How do you determine if it is

"artificially created"/"man made"?


Most ponds that I add are as a result of survey, so "should not be 
mapped because it is not observable on the ground" doesn't make a lot of 
sense to me.  To be honest, I usually just leave them as natural=water, 
but that's just my laziness.



As it stands right now in the wiki I suggest we either deprecate the 
tag completely or change the definition to something that is 
observable on the ground.


If you're sat there looking at a pond, it's usually pretty obvious 
whether it's man-made or not.  Has it got a man-made dam at one side and 
is it fed by obviously man-made ditches?  Then it's probably man-made.  
Is it just in a natural dip in the ground with none of those features?  
Then it probably isn't.


Even if you're looking at imagery some of those features will still be 
visible - mill ponds show up pretty clearly, as do the waterways created 
to feed them.


Best Regards,

Andy


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

Re: [Tagging] Annual Shows

[Andy Townsend]

On 25/02/2020 22:16, Graeme Fitzpatrick wrote:


But I have seen a few places on the map where a street motor race is 
held once a year, but they are mapped as a motor racing track, with a 
description "whatever race held the first weekend of October".



The more normal mapping approach is like in Singapore I think:

https://www.openstreetmap.org/relation/421263#map=16/1.2906/103.8580

is a relation that makes sense whenever in the year it is.

Some parts of that are highway=raceway:

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

and as far as I can see that's correct - certainly the pit lane approach 
_looks_ like a raceway even when there are no cars on it.


Best Regards,

Andy



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

Re: [Tagging] URL tracking parameters

[Andy Townsend]

On 25/02/2020 10:16, Frederik Ramm wrote:

Hi,

On 25.02.20 11:08, Richard Fairhurst wrote:

Frederik Ramm wrote:

Since OSM is not the place for marketing, I would in these
situations remove the whole POI, and not just the tracking
parameters.

¿Que? You'd remove an entire hotel from the map because... ok, I'm having
trouble finishing that sentence: because what exactly?

I'd remove things from OSM that have been clearly added as part of an
advertising campaign, because that means the information is not
trustworthy. The purpose of an advertising campaign is not to provide
unbiased, factual information, hence OSM cannot be the vehicle for an
advertising campaign.

Having communicated with "Hilton Hotels" in the past, I get the 
impression that they're just trying to "keep OSM up to date". They're 
not adding "marketing crap" in fields such as "description".  I also 
don't get the impression that there are a huge army of people updating 
OSM from their end either - it appeared to me like there was essentially 
just one person.


Using "website:" rather than "website" just looks like cockup rather 
than conspiracy.  I have no idea where the "?" parameter came from, but 
given that they don't similar tag links from twitter (that just goes to 
https://doubletree3.hilton.com/en/hotels/united-kingdom/doubletree-by-hilton-hotel-london-kingston-up 
) that might just be cockup also - copying a link from an internal URL 
that had that appended.


Best Regards,

Andy



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

[Tagging] Service road surface edits in the UK (was: Re: implied surface values?)

[Andy Townsend]

On 12/02/2020 11:51, ael wrote:


+1. Some of the Amazon people do seem to be adding unnecessary and
unsurveyed surface=asphalt tags to many roads in the UK which I find
quite irritating.


If anyone's adding surface=asphalt when it isn't I'd definitely raise 
that via a changeset discussion comment.


If that doesn't work, raise via the usual channels (e.g. email to 
d...@osmfoundation.org).


Best Regards,

Andy



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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Andy Townsend]

On 05/02/2020 19:17, Christoph Hormann wrote:

- in other words: Special casing exactly the situation in question to
be treated as an exception.


Hedges historically were treated as areas if appropriate, whereas other 
barriers were not.


https://github.com/gravitystorm/openstreetmap-carto/blob/0fac157a650b25844806f3f49fc65432751da38d/landcover.mss#L710

is from a couple of years ago.  I'm not sure when OSM Carto changed its 
mind on them - I must have missed the memo.


You could perhaps ask "why were hedges special-cased in the first 
place", but the answer's pretty obvious - a hedge more often has a 
significant mappable width than a fence.


What would help make the data clearer (regardless of this discussion).  
For example, https://overpass-turbo.eu/s/QqU is where the same object is 
used to represent both an amenity and a hedge in most of England and 
Wales.  There are only 12 polygons in that list - not beyond the bounds 
of manual fixing.  A similar query covering most of The Netherlands 
https://overpass-turbo.eu/s/QqV gets only 2 polygons.  Looking for 
combinations of "landuse" will get more, but not that many more: 44  
https://overpass-turbo.eu/s/QqW .


Once the small amount of double-tagged data is fixed, OSM Carto will be 
free to represent hedges as mappers had always intended.


Best Regards,

Andy




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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Andy Townsend]

On 05/02/2020 17:24, Christoph Hormann wrote:

With "only feasible alternative" i means the only alternative that has
even a remote chance for consensus among the maintainers.


Ah! OK - that's much more understandable.

About the "removing tags where they may clash" point, here's an example:

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

(that's in lua, which may not be appropriate for OSM Carto, but I'm sure 
that something similar could be done as a regular SQL Select)


Basically it's saying "if something is mapped as a brewery and also as 
tourist attraction, remove the tourist attraction tags prior to 
rendering so the renderer renders it as a brewery, not a tourist 
attraction".


Obviously a decision has to be made which of the two tags to render if 
either potentially could - either by layer order or by explicitly 
ensuring that one does and one doesn't, which I've done here.


Best Regards,

Andy





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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Andy Townsend]

On 05/02/2020 14:46, Christoph Hormann wrote:

On Wednesday 05 February 2020, Andy Townsend wrote:

It doesn't sound like a tagging issue to me; I'd suggest that the
renderer that made this change did so in error.  Is using a different
renderer an option until it is fixed (perhaps the Humanitarian tiles
linked from openstreetmap.org)?

The change in rendering is intentional.  Is has been explained in:

https://github.com/gravitystorm/openstreetmap-carto/pull/3844

As explained there the only feasible alternative would be to stop
rendering barrier tags on polygon features universally.


No, it's not the only alternative - another would be "where there are 
conflicting tags, decide which one to render".  There may be good 
reasons for not doing that, but to claim this is the "only feasible 
alternative" doesn't seem correct to me.


I'm fully aware of the issue having dealt with it myself (and agree that 
area=yes per se is something of a red herring), but it does seem odd 
that of the examples at 
https://github.com/gravitystorm/openstreetmap-carto/pull/3844 3 of the 5 
are clearly rendered incorrectly _after_ the PR but were correct _before_.


Obviously the people developing the style are the ones putting the time 
in and can take it in any direction they choose, but sometimes the 
reason for the direction taken is a bit unclear.


Best Regards,

Andy



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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Andy Townsend]

On 05/02/2020 13:02, Jeroen Hoek wrote:

This update has the unfortunate side-effect of breaking the rendering of
over 1 hedges in the Netherlands.



This means that hedges are often mapped as areas, using the documented
tag pair of `barrier=hedge` plus `area=yes`:


In this case sounds like the renderer has broken the "principle of least 
surprise".


It doesn't sound like a tagging issue to me; I'd suggest that the 
renderer that made this change did so in error.  Is using a different 
renderer an option until it is fixed (perhaps the Humanitarian tiles 
linked from openstreetmap.org)?


(for the avoidance of doubt - I appreciate that this this conversation 
started on one mailing list, then replies moved it elsewhere, so this 
isn't intended to be a criticism of which list you posted to!)


Best Regards,

Andy



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

Re: [Tagging] Active volcanoes

[Andy Townsend]

On 29/01/2020 20:47, Eugene Alvin Villar wrote:
Wikidata already has the GVP property: 
https://www.wikidata.org/wiki/Property:P1886


So it's just a matter of ensuring that all volcanoes tracked by the 
GVP is present in Wikidata and has the correct P1886 value.



To a regular human being rather than a wikipedian, that might as well 
have been written in Klingon. :)


I suspect that trying to rely on wikidata/wikipedia for this link will 
fail for a different reason though - the things that we tag in OSM won't 
necessarily map 1 to 1 onto wikipedia pages. Sometimes an OSMer will 
want to indicate that a wider area than is indicated in 
GVP/wikipedia/wikidata, but much more often an OSMer will be tagging an 
individual volcano that might not match where a historical eruption took 
place (think Thera / Santorini, where a famous eruption left a big hole, 
now surrounded by numerous modern features).


It does make sense to use (and document) GVP's "active" definition in 
OSM, but there will be places in OSM where it's not a good fit, because 
what was there that erupted earlier in the last few thousand years isn't 
there now.


Best Regards,

Andy



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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Andy Townsend]

On 28/01/2020 22:44, Dave F via Tagging wrote:

On 28/01/2020 21:23, Tomas Straupis wrote:


   Yet for ten years ...


I think your mistaken ...



If it helps, someone on anther OSM list went through the previous times 
this has been discussed and came up with 
https://lists.openstreetmap.org/pipermail/talk-au/2019-October/013031.html 
.  The links from there, especially the thread that starts 
https://lists.openstreetmap.org/pipermail/tagging/2014-November/thread.html#19949 
are worth reading.


Of course if you want to venture even further back: 
https://lists.openstreetmap.org/pipermail/talk/2007-August/thread.html#17030 
:)


Best Regards,

Andy



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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Andy Townsend]

On 27/01/2020 17:19, Dave F via Tagging wrote:



On 27/01/2020 16:41, Mike Thompson wrote:


I have never understood the use of tags like "cycleway", "bridleway", 
and
"footway."  To me these mix two different concepts (physical form and 
legal

access) in a single tag.


These values do not indicate a way's form. That is achieved with 
secondary, adjective tags such as segregated/width/surface/smoothness 
etc.



Sure they do - by inference at least.

If a "cyclebridlefootpath"* was constructed "mainly for cycle traffic" 
than it'll tend to have a certain form.  It'll probably not have a 
surface of lumpy rocks.  Something constructed "mainly for horse 
traffic" won't have stiles (other than horse stiles) on it.  Of course, 
it absolutely makes sense to add secondary tags such as surface etc. as 
well.  It's not guaranteed that "everywhere in the world a cycleway will 
have this physical form" but if you know what the norm is for things 
constructed for cycle traffic in whatever country you're in, you've got 
an idea what to expect, even without extra tags.


Re access, in England, I'd also always add access tags where possible 
too, since unlike some other places, there's nothing like 
"allemansrätten" here, and it's quite possible for access to be 
"permissive" or "no" rather than "yes", and where access is "yes" it's 
useful to know why (here usually some other legal designation that 
confers that access).


To get back to the main question, the advice I'd give to people mapping 
cyclebridlefootpaths in their local country is "do whatever other people 
in your country do".  That might vary between "use highway=path for 
almost everything**" and "use duck tagging - pick what something most 
resembles", but if someone follows the local herd at least other people 
locally should understand what they mean.


Best Regards,

Andy

* one of any of what anyone might tag as highway=cycleway, 
highway=bridleway, highway=footway, highway=path.


** obviously highway=path with no other tags is pretty useless - there 
are no clues about either access or form there at all.




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

Re: [Tagging] Deleting template parameters copied to data items

[Andy Townsend]

On 15/01/2020 12:03, Mateusz Konieczny wrote:


15 Jan 2020, 12:57 by marc_marc_...@hotmail.com:

I'm very unhappy with that.

Please, please comment on the OSM Wiki if you want to comment.


What would be useful is a separate discussion about what wiki "data 
items" are and why there are a good (or bad) idea.  That doesn't really 
belong in 
https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information 
because that seems tied up in the specifics of one particular tag (and 
lets be honest, wiki pages aren't good at threaded discussion).


Maybe someone who thinks this particular change is a good (or bad) idea 
should write a diary entry or create a thread here explaining what the 
point of the change is and what the benefits are, and what the impact on 
people who use the wiki for reference and on people who edit it is?


There is a page https://wiki.openstreetmap.org/wiki/Data_items but that 
fails to communicate much of that to me (someone whose first language is 
English and has been reading technical documentation for 40 years).  
Until that happens the rest of us are just going to assume that the OSM 
wiki is a series of pages that we can just edit to document things in 
OSM to help other mappers (which presumably was the original point) and 
ignore anything else.


Best Regards,

Andy


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

Re: [Tagging] How to revive a tag proposal?

[Andy Townsend]

On 14/01/2020 17:33, António Madeira via Tagging wrote:

What can I do to revive this proposal and implement this tag?


Just use the tag?

You can see existing values for "man_made" at 
https://taginfo.openstreetmap.org/keys/man_made#values , and you can 
search in there for "mill" or "olive". "man_made=olive_oil_mill" is 
actually relatively popular among "mill" values.


This won't get it automatically included on any map rendering, but if I 
was doing one for Southern Europe I'd definitely consider including 
something.


Best Regards,

Andy



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

Re: [Tagging] recreational vs functional routes

[Andy Townsend]

On 09/01/2020 23:14, Peter Elderson wrote:

Warin <61sundow...@gmail.com> het volgende geschreven


I think;
Those who bicycle know why there needs to be these classes.
Those who don't ride a bicycle regularly see no need for these classes.

I wonder which of these groups you think I am in...

Hint: Nederland.


Ahem.  How can I put this tactfully - the Netherlands doesn't exactly 
have the widest variety of cycling terrain in the world, and has a 
generally good network of separated cycleways.  That isn't true 
everywhere - regularly when I'm out walking I'm asking myself "how do I 
tag this so that a poor mistaken cyclist doesn't think it'd be a good 
shortcut".  An example is https://www.openstreetmap.org/way/353193650 , 
where I was on Monday - is an example.  It's a public bridleway in the 
UK, so as well as walkers, horse riders and cyclists can legally use it 
too - but any horse bigger than a small pony wouldn't fit (not without 
the rider being impaled on a tree branch), and the 45 degree angle of 
the hill, and the slippery mess on the ground, make it challenging for 
walkers never mind cyclists.


Not so far away is 
https://www.openstreetmap.org/relation/9487#map=13/54.3595/-1.2685 which 
is actually part of a cycle route.  The worst of that section is 
probably "only" mtb:scale=1, but I certainly wouldn't recommend it to a 
normal road bike user (or someone used to comfort as they're riding along).


Outside of "small" countries like the Netherlands or England other 
factors such as sheer scale come into play - for example the 
https://en.wikipedia.org/wiki/Munda_Biddi_Trail that has opened between 
Perth and Albany in Australia (see 
https://www.openstreetmap.org/relation/5810814 ), or one of the long US 
routes.


Best Regards,

Andy




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

Re: [Tagging] amenity=tourist_bus_parking

[Andy Townsend]

On 08/01/2020 10:14, Volker Schmidt wrote:
What about going back to the wiki and make use of the fact that 
amenity=parking_space 
 can 
be used for this.
Make separate parking space areas for different vehicle types. Add 
parking entrances 
 
(at present restricted fto underground and multi-level car parks, but 
I acan see no reason ot to us ita lso for surface parking). Tie it 
together with a relation 
. 




... and if anyone wants to look at the usage of that around the world, 
try here:


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

(move the map to where you're interested in and hit "run").

Best Regards,

Andy


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

Re: [Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

[Andy Townsend]

On 31/12/2019 15:27, Volker Schmidt wrote:
What's the difference between "metal" and "scrap metal". I would have 
thought any metal can be recycled (if the rightful owner is OK with that).

What am I missing?

It depends on the context I suspect.  If we're describing bins at the 
local tip, then the terms may well be pretty much synonymous. If you 
move a bit further up the value chain though there's definitely a 
difference - a company that is a steel stockholder may well be involved 
with recycling metals but will probably bristle at being described as a 
"scrap metal merchant"!


Any attempt to deprecate values is probably a bad idea.  If you look at 
https://taginfo.openstreetmap.org/search?q=recycling etc. you can see 
that there's quite a lot of overlap between values, but I wouldn't worry 
about it.


Best Regards,

Andy



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

Re: [Tagging] [Talk-us] Trunk VS primary

[Andy Townsend]

On 21/12/2019 11:40, Mateusz Konieczny wrote:


21 Dec 2019, 12:00 by wolfg...@lyxys.ka.sub.org:

I suggest to keep the road classification consistent at least within
a country and try to solve the problem of roads in low-zoom maps at
the rendering level, by modifying the list of displayed road classes
until a target density of displayed roads is reached. That might
become easier to do when we move to vector tiles.

Seems not doable with OSM data - this
would require far more road classes
than we use.

lane and surface data is also almost
certainly not helpful here even with full
coverage

Renderers can certainly use tags other than "highway" when deciding what 
road class to render things as (I do that in a couple places in maps for 
UK/IE but not for trunk/primary, but if I was creating maps for the US I 
suspect I'd definitely try and use other tags along with the highway tag 
to influence road class at motorway/trunk/primary as well).


Specifically, if a tertiary is particular narrow it gets rendered as 
unclassified, and if an unclassified or residential is a gravel track it 
gets rendered as a track with public access. Specifically:


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

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

The "invented highway tags" set there are then used by

https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT/blob/master/roads.mss

Best Regards,

Andy


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

Re: [Tagging] pavement placed plaque

[Andy Townsend]

On 20/12/2019 20:41, ael wrote:

On Fri, Dec 20, 2019 at 06:02:50PM +, Dave F via Tagging wrote:

Hi

I've a carved stone plaque(?) that's fixed flush into the pavement. it's to
indicate the start/finish point of a long distance walk.
https://whatsdavedoing.com/cotswold-way-guide/#start

Two questions:

1 Is plaque the best name? Our Wiki quotes Wikipedia as it being vertical,
but that seems a bit restrictive to me.
https://wiki.openstreetmap.org/wiki/Tag:memorial%3Dplaque
  
  It seems to be a sort of waymark to me. As far as I can see, we don't

  have a generic tag for waymarks, although there are lots of special
  cases like milestons. Perhaps we should have a waymark tag with subtags
  for material and orientation?


Here's one I made earlier:

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

I went with "tourism=information; information=stone" to parallel 
"information=guidepost" and "information=route_marker" which are more 
commonly used as route markers.


Another example (tagged slightly differently, that probably wouldn't 
work for the Cotswold Way one) is:


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

Another one (not part of a route this time) is

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

That one is a stone flush with the pavement nd sounds a bit like yours 
but perhaps a bit more arty.


Best Regards,

Andy



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

Re: [Tagging] Public WLAN boxes

[Andy Townsend]

On 18/12/2019 15:22, Tod Fitch wrote:

In the U.S. it would be called wifi or wi-fi rather than wlan. Anyone know what 
the British English is?

In the UK it's also "wifi" or "wi-fi", but wlan is understood and has 
considerable establishment in OSM:


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

(183k)

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

(649)

https://taginfo.openstreetmap.org/search?q=wi-fi#values

(about 70)

Best Regards,

Andy


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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Andy Townsend]

> Cannot be legal for a pedestrian route, I think

Statements like this suffer from an effect a bit like "Betteridge's law of 
headlines", in this case "any absolute statement that something that is true in 
one place is also true everywhere else in the world is false".

I can certainly think of places where oneway pedestrian access is enforced in 
the UK (one is a narrow ledge half way up a cliff). It's unusual, but not 
unheard of.

Best Regards,
Andy

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

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Andy Townsend]

On 06/12/2019 23:30, Warin wrote:



Start and finish points will be at the end of the main route ways .. 
should be obvious? No?


It depends - as Sarah's already pointed out, routes that are more 
complicated than "one start and one end" are very common.  One of the 
more famous examples is the Camino de Santiago, which has one end but 
many different start points.


Best Regards,

Andy



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