Re: [Tagging] Apparent conflicting/redundant access tags
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
Re: [Tagging] Rio de la Plata edit war
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
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] Apparent conflicting/redundant access tags
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
[Tagging] Feature Proposal - RFC - more parking types
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&mlon=-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
[Tagging] customer_service=yes/no - Feature proposal RFC
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
Re: [Tagging] customer_service=yes/no - Feature proposal RFC
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
Re: [Tagging] Feature Proposal - RFC - more parking types
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] Rio de la Plata edit war
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] Apparent conflicting/redundant access tags
On Thu, 6 Aug 2020 17:12:48 +1000 Graeme Fitzpatrick wrote: >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? The issue is that it becomes the default for all other transport mode access. I once had OsmAnd direct me to turn my car right on a very tiny path. It was tagged as highway=foot,access=yes ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
