Re: [Tagging] Rio de la Plata edit war

2020-08-06 Thread David Groom
I've so far stayed out of this discussion because my final thoughts on 
the matter will I am sure be contentious.


In no order of importance my thoughts are:

1) the idea of basing a the limit on coastline on levels of salinity or 
average water flows makes as little sense as trying to specify that the 
"landuse = forest" tag can only be used when there are a specific number 
of trees growing in a particular area.


2)  yes the wiki says coastline should be based on the Mean High Water 
Spring, but I've long argued that for instance no one in London would 
say they lived on the coast even though the River Thames is tidal 
upstream of the city.  Hence the border between coastline and water body 
should be downstream of the tidal influence and is based on "a 
reasonable estimation of where an observer might suggest the river ends, 
and the sea begins".  Such an estimation is imprecise, not subject to 
verification, and different observers will have different opinions - get 
over it.  As in point (1)  different observers will have different 
opinions on where a "forest" ends and "scrubland" starts.


3) Due to the needs of the rendering process we have long established 
that ways tagged "natural = coastline"  are a special case.


4) We have existing tags for "tidal = yes" and "estuary=yes", 
"admin_level = ?" which means it is unnecessary for the coastline tag to 
be used as a proxy for these.


5)  The discussion on what the tag "natural = coastline" actually means 
has been discussed for so long that it appears almost insolvable.


Given the above.

A) In view of all the points above it is not possible to write a concise 
definition of what the tag natural = coastline" represents.


B) Until January 2020 we had a reasonably broad agreement on where the 
coastline should be.  Though I recognise, perhaps more than most who 
have contributed to this thread, that there are still are large number 
of ways ( particularly in the more sparsely populated areas of the 
world, or where the OSM community is not large)  that are unchanged from 
the position they were placed in by the PGS imports in 2006.


After much thought my, probably contentious, view  is:

1) We should establish an agreed "OSM Coastline position", which I 
suggest would approximate to the position of the coastline on 1 January 
2020.


2) Any edit which moved the position of the coastline by more than 20Km 
from the established position should be classed as vandalism, unless 
such movement had previously been agreed by the community.


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


Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-06 Thread Martin Koppenhoefer


sent from a phone

> On 6. Aug 2020, at 22:54, Matthew Woehlke  wrote:
> 
> - To codify / make official the de-facto parking_space=disabled


that’s almost 22k uses, it is already established and voting yes or no will not 
change it


> - To allow mapping motorcycle parking as part of a unified parking lot, by 
> introducing parking_space=motorcycle and capacity:motorcycle


amenity=parking  is defined for single parking spaces, adding capacity to what 
seems to be a subtag, would create confusion 

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


Re: [Tagging] customer_service=yes/no - Feature proposal RFC

2020-08-06 Thread Martin Koppenhoefer


sent from a phone

> On 6. Aug 2020, at 23:18, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Using access tags access=yes/access=customers/access=private - it is
> not entirely clear. And in many cases place clearly offers customer
> service but nearly all office is still closed to outsiders. Still, it
> is a viable alternative


+1, customer_service only describes part of the possibilities for which an 
office might be welcoming to walk in clients, customer service is for 
(existing) customers typically.

access=private should be sufficient to describe that you could normally not go 
there (unless you have an appointment). Access=yes on the other hand is not 
very clear, maybe access=public would be clearer


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


[Tagging] customer_service=yes/no - Feature proposal RFC

2020-08-06 Thread Mateusz Konieczny via Tagging
https://wiki.openstreetmap.org/wiki/Proposed_features/Customer_service
again

Main difference is witching to customer_service=yes/no
from amenity=customer_service

Thanks for all feedback and thanks for edits and comments.

Rationale:

Distinguishing closed office spaces and offices with client service
locations has no standard solution.

Both are currently tagged as office=company, but it seems to me that
there is a clear need to distinguish between:

    a company office where I can walk in and handle issues with
    existing products or services (or maybe buy them)

    a company office closed to outsiders, where workers do not interact
    with walk-ins; people attempting to get inside would be escorted
    out by security

This tag is also likely to be useful for office=government - some are
primarily or partially contact points with public, some are internal
and closed to outsiders.

Current alternative:

Using access tags access=yes/access=customers/access=private - it is
not entirely clear. And in many cases place clearly offers customer
service but nearly all office is still closed to outsiders. Still, it
is a viable alternative.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature Proposal - RFC - more parking types

2020-08-06 Thread Matthew Woehlke
Please see 
https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking.


To summarize: I am proposing the following:

- To codify / make official the de-facto parking_space=disabled
- To allow mapping motorcycle parking as part of a unified parking lot, 
by introducing parking_space=motorcycle and capacity:motorcycle

- To add the additional parking space types 'compact' and 'takeaway'

See https://www.openstreetmap.org/way/830096097 for an example of 
parking_space=motorcycle being used in anger. See also 
https://www.openstreetmap.org/?mlat=38.51676=-77.29554 (open in an 
editor and check the Mapbox imagery) for another, even better example of 
where splitting what most people would almost surely call a single lot 
into separate amenity=parking and amenity=motorcycle_parking would be 
silly. The same lot also has an example of a space that is obviously 
compact-cars-only (by virtue of being not quite 15' long, vs. a more 
typical 18'+).


See https://goo.gl/maps/ePTDv7U4LnieFoor7 for an example of takeaway 
parking.


Question: should we also overload parking_space=takeaway for "parking" 
spaces reserved for curbside pickup? Should we also add a different type 
for those? Or should we simply not map those, or map them in some manner 
totally different from how parking spaces are mapped?


--
Matthew

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


Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-06 Thread Philip Barnes
On Wed, 2020-08-05 at 13:58 -0700, Tod Fitch wrote:
> My reading of the wiki [1] indicates that the more specific tag
> overrides the less specific tag. And the transport mode section [2]
> of that has examples very much like those in your question.
> And:
> access=yes
> bicycle=no
> 
> Means you can walk, drive or ride a horse, etc. but you can’t
> bicycle.
> 
Although I would question that combination if I found it in use, it
would be a very strange situation.

Phil (trigpoint)


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


Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-06 Thread Mateusz Konieczny via Tagging



Aug 6, 2020, 09:12 by graemefi...@gmail.com:

> OK, now you've all got me confused!
>
> I always thought that access=yes means that it is open to the general public, 
> while access=no means that it's not open to the public?
>
Yes, and it may be overriden by more specific tags.

Note that access=yes on say leisure=playground will be interpreted differently 
than on highway=residential.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rio de la Plata edit war

2020-08-06 Thread Christoph Hormann

Muralito,

it would be very useful if you could address the request i have made 
several times now.  I will not engage in a discussion on the other 
lines you mean to open here because it is non-productive from my 
perspective.  It could take us hours to determine the smallest common 
denominator on cultural and cartographic subjects and it would still be 
highly doubtful if a discussion on that fields would lead to any 
productive outcome.  So if you are interested in establishing a 
consensus on this matter please try to follow my request.

If there is anyone else from the local community who would be willing to 
formulate a generic set of rules based on physical geography criteria 
about the natural=coastline placement that reflects your local view as 
i have explained please do so - even if you do so in Spanish that would 
be very helpful.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-06 Thread Graeme Fitzpatrick
OK, now you've all got me confused!

I always thought that access=yes means that it is open to the general
public, while access=no means that it's not open to the public?

Thanks

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