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

2020-12-23 Thread 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?

2020-12-21 Thread 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

2020-12-10 Thread 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 ?

2020-12-03 Thread 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

2020-11-27 Thread 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

2020-11-25 Thread 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

2020-11-25 Thread 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)

2020-10-02 Thread 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

2020-09-19 Thread 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

2020-09-19 Thread 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

2020-09-19 Thread 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

2020-08-27 Thread 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

2020-08-23 Thread 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

2020-08-23 Thread 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

2020-08-14 Thread 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

2020-08-07 Thread 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

2020-07-31 Thread 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.

2020-07-25 Thread 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.

2020-07-25 Thread 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

2020-07-25 Thread 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.

2020-07-22 Thread 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.

2020-07-21 Thread 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.

2020-07-21 Thread 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?

2020-07-18 Thread 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?

2020-07-12 Thread 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?

2020-07-01 Thread 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?

2020-06-06 Thread 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

2020-06-02 Thread 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

2020-05-22 Thread 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

2020-05-21 Thread 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

2020-05-21 Thread 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

2020-05-15 Thread 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

2020-05-08 Thread 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

2020-05-03 Thread 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

2020-05-03 Thread 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

2020-04-30 Thread 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

2020-04-30 Thread 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

2020-04-30 Thread 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?

2020-04-27 Thread 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

2020-04-05 Thread 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

2020-03-31 Thread 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

2020-03-28 Thread 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

2020-03-23 Thread 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

2020-03-19 Thread 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

2020-02-25 Thread 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

2020-02-25 Thread 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?)

2020-02-12 Thread 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

2020-02-05 Thread 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

2020-02-05 Thread 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

2020-02-05 Thread 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

2020-02-05 Thread 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

2020-01-29 Thread 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?

2020-01-28 Thread 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?

2020-01-27 Thread 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

2020-01-15 Thread 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?

2020-01-14 Thread 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

2020-01-09 Thread 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

2020-01-08 Thread 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

2020-01-02 Thread 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

2019-12-21 Thread 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

2019-12-20 Thread 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

2019-12-18 Thread 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

2019-12-08 Thread Andy Townsend

On 08/12/2019 17:01, Mateusz Konieczny wrote:


8 Dec 2019, 15:25 by mfbehren...@gmail.com :
> This diagram should help to better visualise the structure

At least in my case diagram was lost
and not displayed

It was a link to 
https://wiki.openstreetmap.org/wiki/File:Proposed_hierarchic_structure_of_hiking_relation_.jpg 
in the wiki.


My email client also didn't show it by default (many won't show external 
image links by default)


Best Regards,

Andy


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


Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

2019-12-07 Thread 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

2019-12-06 Thread 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


Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

2019-12-06 Thread Andy Townsend

On 06/12/2019 10:15, Michael Behrens wrote:


There is no unique way to tag roles in hiking route relations

I'd suggest making it clear that that table is currently for way members 
only - it doesn't mention node members (start, end, marker, etc.).  This 
may be deliberate, or you just haven't expanded it yet, but I'd 
definitely mention node members.


Best Regards,

Andy


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


Re: [Tagging] Feature Proposal - RFC - (contact:phone)

2019-12-04 Thread Andy Townsend

On 04/12/2019 12:01, Richard Fairhurst wrote:

Sören Reinecke wrote:

This proposal tends to make Key:contact:phone the official tag
for tagging phone numbers and to deprecate Key:phone which is
not fitting in the idea of grouping keys. Anyway it's bad to have
two keys for the exact same purpose in use.

Please just kill me now.


Ahem.

Perhaps, Sören, it would help if you explained in a bit more detail why 
you think it's a good idea to have yet another vote on this? 
https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone 
is largely content-free, apart from the "how we format phone numbers" 
part (which is I believe largely agreed and common to both).


If you could explain why it is "bad to have two keys for the exact same 
purpose in use" in that proposal it would stand much more chance of not 
being rejected or (more likely) just ignored.


Historically OpenStreetMap, with free-form tagging, has succeeded where 
other more codified approaches have failed.  That isn't unique - think 
Wikipedia vs Nupedia.  Historically also OSM has tried to make life easy 
for mappers rather than data consumers - the idea being that 1000 mapped 
items (some with tags that may need a bit of correction or merging 
later) is better than 100 perfectly tagged ones with 900 unmapped.


It'd also be good to see an explanation of why it's worth the time even 
going through this again - haven't we all got better things to do?


Surely we know from previous discussions that

 * some people prefer using "phone" as a key,
 * some people prefer "contact:phone"
 * in the absence of other information they mean exactly the same thing
 * it's trivial for renderers and other data consumers to treat them
   exactly the same

Best Regards,

Andy



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


Re: [Tagging] Use of a site relation for grouping parking spaces

2019-12-03 Thread Andy Townsend

On 03/12/2019 18:59, Alessandro Sarretta wrote:
Should we maybe rephrase the sentence "Parking spaces *always have to* 
be grouped together in a site relation tagged with type=site + 
site=parking." in something like "Parking spaces *can* be grouped 
together in a site relation tagged with type=site + site=parking."?



The last time this came up on this list I asked anyone if they could 
come up with anyone who manages to use site relation data for anything.  
I don't believe that anyone was able to suggest anything.  I've 
certainly tried and failed to do something useful with site relations 
(for rendering).


Your suggestion sounds like an improvement to me.

Best Regards,

Andy


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


Re: [Tagging] Barrier=berm

2019-11-28 Thread Andy Townsend

On 28/11/2019 13:03, Paul Allen wrote:
On Thu, 28 Nov 2019 at 12:45, Andy Townsend <mailto:ajt1...@gmail.com>> wrote:


Tagging 2 things to represent 1 physical feature just makes it
extra-hard for anyone consuming the data.


Yet we have a very similar problem with "two things, two objects."  We 
make a tennis court
surrounded by a fence two objects for good reasons.  But it is very 
difficult to subsequently
edit those objects in some editors.  Not only may you not realize 
there are two objects, but
there is no way (in some editors) of cycling through objects having 
all ways in common.
The only way I've found is to split a node so I can move the node of 
one object away in
order to be able to select between them, then put that node back when 
I've finished.


It's a problem that shouldn't exist.  Fixable in the tool chain.

Please do explain how at rendering I can change what's in the data at 
https://www.openstreetmap.org/#map=19/53.22594/-0.48389 to something 
more like https://www.openstreetmap.org/way/359607456 so that at 
anything less than z16 you don't just get a mess.  A rendering of the 
latter one (with "emabankment=yes" in this case) can be seen at 
https://map.atownsend.org.uk/maps/map/map.html#zoom=14=53.27001=-0.77707 
.


If you say "this is fixable in the tool chain" without actually being 
able to explain how, then we'll have to assume that you actually don't 
know how, and therefore don't know that it is actually "fixable" at 
all.  That doesn't mean that it isn't, but it likely means that no-one 
yet knows how without a lot of spatial stuff in the stylesheet (which 
would be a bit of a nightmare).


And to pick up one other point:

On 28/11/2019 13:29, Volker Schmidt wrote:
I have used in past a way with only one tag: embankment=yes to map 
small earth walls with nothing on top. I admit that I have not checked 
the rendering, but this seems to me a simple solution.


yes, these is one of the most common ways that people do this sort of 
thing.  When I looked into this a while back (mostly in Ireland and the 
UK) I came up with the list at 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L3086 
.


Best Regards,

Andy



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


Re: [Tagging] Barrier=berm

2019-11-28 Thread Andy Townsend


On 28/11/2019 11:42, Paul Allen wrote:
On Thu, 28 Nov 2019 at 10:56, Andy Townsend <mailto:ajt1...@gmail.com>> wrote:


OSM Carto, as far as I'm aware

  * Doesn't have a concept of 2-sided embankments or a rendering
for them

Does it need such a concept?  I haven't tried it when the embankment 
resembles an
arete, but for an embankment with a plateau all that is needed is two 
embankments

delineating the plateau.


Tagging 2 things to represent 1 physical feature just makes it 
extra-hard for anyone consuming the data.  They'd have to say "OK, I've 
got a man_made=embankment here; now, before I decide what to do with it, 
I have to see if there is another parallel one facing the other way that 
tells me that what I've really got is a raised flood bank or similar"


We represent other linear features (e.g. roads) as lines; it makes sense 
to do the same here.


Best Regards,

Andy

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


Re: [Tagging] Barrier=berm

2019-11-28 Thread Andy Townsend

On 28/11/2019 09:59, Paul Allen wrote:



On Thu, 28 Nov 2019 at 00:23, Graeme Fitzpatrick 
mailto:graemefi...@gmail.com>> wrote:



Question of my own - is there any particular reason that a berm
couldn't just be rendered the same as a wall?


That question prompts another question.

Why render it as a wall?  Since a berm is a type of embankment, why 
not render it as an

embankment?


I've rendered "2-sided embankments" at e.g. 
https://map.atownsend.org.uk/maps/map/map.html#zoom=17=54.024306=-1.02141 
as _their own thing_ for a while now.  That example is at the end of a 
firing range, 
https://map.atownsend.org.uk/maps/map/map.html#zoom=15=53.87324=-1.23959 
shows some for flood defences.  In that second image to the northwest 
you can see an embankment with a path on it.


OSM Carto, as far as I'm aware

 * Doesn't have a concept of 2-sided embankments or a rendering for them
 * Doesn't have the concept of "on an embankment" being a modifier for
   highways / railways in a similar way to "bridge" and "tunnel"


Either way, if you render it the same as an existing object, and it 
serves the
same purpose as an existing object, the carto people are likely to 
veto it under their "no

synonyms" rule.


I wouldn't argue that a new tag for berm is "needed", because people 
have found ways to tag these features already (such as "embankment=yes" 
and various flood defence tags), but it could be argued that using one 
tag for these features makes things clearer.  Separately to that, even 
if you say "render X like Y" it doesn't mean that X is a synonym of Y.  
There are plenty of those in all renderings already.



Even if you persuade the carto people to render berms, it will go on 
their long to-do list and

may take a long time to appear.


The usual answer here is "pull requests welcome"...

Sometimes people might not want to do that because they know it wouldn't 
be accepted (if it makes more use of lua processing than the OSM Carto 
folks are happy with, for example).  I suspect that wouldn't make sense 
to submit a pull request to OSM Carto for bus guideway handling to match 
the way I do it because it'd depend on lua changing a bus guideway to be 
a type of railway.  That "busway as railway" handling is why


https://map.atownsend.org.uk/maps/map/map.html#zoom=17=52.315008=-0.05611

show a bridge but

https://www.openstreetmap.org/#map=18/52.31481/-0.05622

does not.




You also have the problem of having to inspect a lot of existing 
embankments to see
if some of them should be retagged as berms.  And the problem of 
mappers, perhaps

newbies, wondering what the difference between the two is.

Others have proposed a berm=* subtag to differentiate types of 
berms.   Why not, instead,

use a subtag for embankments?


A two-sided embankment is fundamentally different to a one-sided one.  
The renderer would need to split them out into a different feature 
anyway to render them, so it's fairly irrelevant to it how they are 
tagged (other than the extra complication in "select" statements if 
people insist on sub-tagging features that mean something else).


Best Regards,

Andy


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


Re: [Tagging] Business which sells static caravans / mobile homes: shop=mobile_home or shop=static_caravan?

2019-11-19 Thread Andy Townsend

On 19/11/2019 11:03, Joseph Eisenberg wrote:

A search of "static caravans" and "for sale" finds many
previously-owned static caravans but does not show results for a
specialty retailer of these residential caravans.


The places that I've seen these advertised for sale in the UK have all I 
think been existing static caravan sites, so an extra "shop" may be 
considered a bit unnecessary.


The same applies for "park homes" (the more permanent variety - though 
I'm not convinced what the best tag is for those).


Best Regards,

Andy



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


Re: [Tagging] Additional detail of Levee mapping via embankments

2019-11-16 Thread Andy Townsend

On 11/16/19 9:21 AM, John Willis via Tagging wrote:


Still looking for feedback on the idea, Specifically:

- lower base way or area sharing nodes with the top line in embankment / 
cutting, etc?

- relation or no relation needed?

- map levee with embankment pairs, or map with two pairs of levee specific tags 
in a relation with the =dyke way?

Javbw


To be honest, I'd be worried about overcomplicating things.  A 
complicated scheme dreamt up here isn't going to get taken up by 
anyone.  Additionally I suspect that quite a lot of people thinking 
about mapping these features are doing so from imagery, and while 
embankments are visible from imagery once you've been to an area and 
seen what they look like, other features may not be.


One thing that might help would be to edit an area on the dev server 
https://master.apis.dev.openstreetmap.org (perhaps several areas, in 
different ways) and invite people to comment on that.


Best Regards,

Andy



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


Re: [Tagging] emergency=ambulance_station vs amenity=fire_station

2019-11-12 Thread Andy Townsend

On 12/11/2019 11:20, Martin Koppenhoefer wrote:
Am Di., 12. Nov. 2019 um 11:49 Uhr schrieb Dave F via Tagging 
mailto:tagging@openstreetmap.org>>:



Is OSM-Carto fit to be promoted as OSM's flagship, de-facto rendering?



Dave, I find it extremely unfair to write this explicitly to Joseph, 
because he is one of the very active contributors to OSM-carto at the 
moment and has tackled a lot of issues.


Agreed - as has been said many times before, you can't have one map 
style that "looks nice", "shows everything" and "works everywhere".


OSM Carto is one map style that by definition is a compromise. Other map 
styles are available, at least one of which that I can think of (mine) 
addresses the issues that you have raised - but does so by making 
different compromses - it fails elsewhere in the world and for other 
target usage, so it simply isn't suitable as an "everywhere in the 
world" style.


Best Regards,

Andy


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


Re: [Tagging] How to tag Seveso sites ?

2019-11-10 Thread Andy Townsend

On 10/11/2019 09:53, Jan Michel wrote:
This seems like there are varying definitions in different countries, 
but all aim at basically the same thing - potential hazards to the 
environment. How about this scheme?


hazard_class = comah:XYZ
hazard_class = seveso:XYZ

For completeness the UK appears to have to classes - "upper tier" and 
"lower tier" - see http://www.hse.gov.uk/comah/comah-establishments.htm 
, and that's determined based "on the quantity of dangerous substances 
they hold" (already noted elsewhere in the thread as relevant).


Best Regards,

Andy




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


Re: [Tagging] How to tag Seveso sites ?

2019-11-08 Thread Andy Townsend

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


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


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


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


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


Best Regards,

Andy



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


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

2019-11-07 Thread Andy Townsend

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

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

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

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


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




no sign ? thus no tag on the way


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




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


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


Best Regards,

Andy



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


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

2019-11-07 Thread Andy Townsend

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

Hello,

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

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

can you share the a picture of this traffic sign ?

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


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


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


Best Regards,

Andy



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


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

2019-11-05 Thread Andy Townsend

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

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

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


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

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


Best Regards,

Andy

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



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


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

2019-10-28 Thread Andy Townsend

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

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

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

Yes it's horrible

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


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

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

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


Best Regards,




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


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

2019-10-22 Thread Andy Townsend

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


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


Best Regards,

Andy



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


Re: [Tagging] How to tag pedestrian lanes?

2019-10-21 Thread Andy Townsend


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


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


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



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


Best Regards,

Andy


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


Re: [Tagging] Cycling relation misuse

2019-10-11 Thread Andy Townsend

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


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

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

Can you list made-up lines that pollute OSM?

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


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

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

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

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

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



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

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

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

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


Best Regards,

Andy


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


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

2019-09-26 Thread Andy Townsend

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


Thus, those disused toilets could be tagged:

disused:building=toilets

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



and separately

was:amenity=toilets

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


Best Regards,

Andy




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


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

2019-09-26 Thread Andy Townsend

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

Paul Allen wrote:

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

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


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

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

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


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

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


Cheers,

Andy



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


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

2019-09-23 Thread Andy Townsend

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




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

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

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


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


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


Best Regards,

Andy

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


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


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

2019-09-22 Thread Andy Townsend

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

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


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

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


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


Best Regards,

Andy

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




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


Re: [Tagging] Draft proposal for Key:aerodrome

2019-09-10 Thread Andy Townsend

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

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

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


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


Compare:

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

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

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

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


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


Best Regards,

Andy



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


Re: [Tagging] Draft proposal for Key:aerodrome

2019-09-10 Thread Andy Townsend

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

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


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


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


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

Best Regards,

Andy



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


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

2019-09-01 Thread Andy Townsend

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

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


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


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


Best Regards,

Andy




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


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

2019-08-25 Thread Andy Townsend

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

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


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


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


Best Regards,

Andy



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


Re: [Tagging] bear box in campground ?

2019-08-21 Thread Andy Townsend

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

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


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

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


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


Best Regards,

Andy



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


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

2019-08-20 Thread Andy Townsend

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


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


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


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


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


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


Best Regards,

Andy


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


Re: [Tagging] Signposts in Roles of route members

2019-08-19 Thread Andy Townsend

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


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

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

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


Best Regards,

Andy


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


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

2019-08-19 Thread Andy Townsend

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


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


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


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


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


Best Regards,

Andy

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


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

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


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

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


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

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


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

2019-08-17 Thread Andy Townsend
> but I would like to see one make a plausible navigation route out of the E2 
> Yorkshire relation as it is now.

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

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

Best Regards,

Andy


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


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

2019-08-17 Thread Andy Townsend

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


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


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


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


Best Regards,

Andy




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


  1   2   3   4   >