[Tagging] Tagging parade_ground?
Hi, I have come across a parade ground for Police - thus not military ... There are a few instances of military=parade_ground ... but this is not military.. Would landuse=parade_ground be suitable.. or is there any other idea? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging parade_ground?
sent from a phone > Am 26.03.2016 um 08:40 schrieb Warin <61sundow...@gmail.com>: > > Would landuse=parade_ground be suitable.. or is there any other idea? can you describe a bit more what this looks like, and how it is exactly used? Is this a piece of city where parades will occasionally take place (but which otherwise is just an accessible open space), an area where they exercise their parades, an area where people go to see a parade, or ... cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] setting proposals to abandoned
I wonder what others think about changing the status of proposals in draft mode to abandoned in the wiki. Is this something we want everyone to do after a certain time, or should this be reserved to the original proponent? Would the situation be different if the status wasn't draft but proposed? If you think everybody should be able to abandon other people's proposals, what would be a reasonable timespan? Does it depend on the actual usage of the proposed tags, and if yes, what would be a reasonable threshold? FWIW, the actual reason for this mail now is this edit, but I'm more interested to learn about your general considerations: http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/childcare2.0&diff=next&oldid=1128997 cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] setting proposals to abandoned
On Sat, 26 Mar 2016 11:06:34 +0100 Martin Koppenhoefer wrote: > I wonder what others think about changing the status of proposals in > draft mode to abandoned in the wiki. Is this something we want > everyone to do after a certain time, or should this be reserved to > the original proponent? Would the situation be different if the > status wasn't draft but proposed? If you think everybody should be > able to abandon other people's proposals, what would be a reasonable > timespan? Does it depend on the actual usage of the proposed tags, > and if yes, what would be a reasonable threshold? > > FWIW, the actual reason for this mail now is this edit, but I'm more > interested to learn about your general considerations: > http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/childcare2.0&diff=next&oldid=1128997 > > > cheers, > Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging Some time ago I set some obviously abandoned proposals to abandoned, I see no reason for "reserved to the original proponent" "what would be a reasonable threshold" - no edits in this or previous year is my typical method to recognise something on internet as dead. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] setting proposals to abandoned
sent from a phone > Am 26.03.2016 um 11:49 schrieb Mateusz Konieczny : > > "what would be a reasonable threshold" - no edits in this or previous > year is my typical method to recognise something on internet as dead. but wouldn't it be necessary to look at actual map edits rather than on a wiki page (i.e. has the tag been applied to objects in the last year)? If the definition is settled there is maybe no need to make changes to the wiki, you can just use the tag. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Alan, Am 25.03.2016 um 23:54 schrieb Alan McConchie: > I’d like to solicit comments on the following proposal, to create a > new tag called "highway=social_path" > > Wiki page is here: > https://wiki.openstreetmap.org/wiki/Proposed_features/Social_path I vehemently oppose introducing this tag for the reasons given by Tekim, Gdt and Stevea at the Talk page of your proposal. https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Social_path It replaces a very old, very often used value by another new one and its only intend seems to hide features from renderers/data users who have not added support for your tag. OSM maps what's on the ground. If there is a path, it is mapped as path. If there is a sign/information board which prohibites using unmarked trails, people add access=no to "unofficial" pathes. > Note: As an experiment, we tagged 17 features in Marin County, > California, as highway=social_path, but these have subsequently > been re-tagged as highway=path, access=no. To my knowledge there > are now no currently-existing examples of highway=social_path in > the main database. See the discussion on the talk-us list for more > information. Thread begins here: > https://lists.openstreetmap.org/pipermail/talk-us/2016-March/016031.ht ml Some > people would call this just vandalism. There is already a discussion about this tag at German forum. Proposals usually get discussed there when voting starts. Usually people who hang out there only get notified if the proposal is bad. Your proposal has been mentioned there today. http://forum.openstreetmap.org/viewtopic.php?id=54139 Best regards Michael - -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJW9oMAAAoJEB87G9rMCMyIrdwP/3dMkTmGrkjMkxn2g2pWfv5U gtE9spMqHgKh5qL7FrjyQ+wDZ7ZrjUji1Gl6qID12sOYTRJgGyIMox+aJzm3SGlD USThM11VHCfQG0EA8qX/sj4wUeqMD1YoNm+snIxEJzGgqm4MX3mtEY/5y4LYFaK8 ymAL40DLNoCVzpbCSCEW2rhEBBhG//sg3yjVbQZu2lmLcLxvQluNaI/XamnagZtp HQcWzfmrD1Af4ifcWMGQ53cc9JzPJEnzJZBC+jN4aZiJiAR8lNQ0FKYtketiT9Ad 4KmYrDrZUBzufo0KIX7xVcCzQtQ9IvaybtqveSuDsn4hQA5KPDNG0ykwlet80iqb 2S36xiE4v5k6zpGvHtwIN/91mQ4/9241q9BrxcFaiC4j38lepehV1oj2pFetwHh5 Q7qmCRUDE/AHuBDtOddEh0owbXiHAPr+QHVpT7UY/wwrPwmzK9CggfGm9Qd8J4FM Q/YwD/fAA/WcYrBc9rs5/SvwKkH1wG9MG06RurC6t+pGsp/Y0Dfn0g93uLoM+NBS w5HE7JiEZTZ+36H+YXGCL0q5823CYxxdNl+dMXJZ+zYwJjbLorbHXmnYrNxuJ1IM 4y8qo8x6FlFmiE2FSW5hhmWAoIxlmuM+iY1xb7ZcmZ3428phxxCdxBCFhsfWMEbx b0x6kEnWrGeSvXOCzEUJ =YZIO -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path
Alan McConchie wrote:
> Some commenters have suggested using the existing highway=path tag,
> with supplemental tags such as access=no or informal=yes, or a new
> supplemental tag path=social_trail, or adding an operator tag. However,
> these supplemental tags are too easily ignored by data consumers and
> renderers, which is problematic given the destructive and hazardous
> nature of social trails in many areas.
First, big thanks for bringing this to the list.
I do think, however, you are mistaken with the above rationale, which
appears to be the sole rationale for the proposal.
access=no is absolutely a core tag within OSM, dating back to the very first
iteration of Map Features. It isn't "easily ignored". Any router which
ignores it is unambiguously bugged. Any renderer intended for walkers'
consumption which shows it as a walkable path is unambiguously bugged.
It is not, however, documented or safe to assume that renderers and routers
will always fall back to "no". There have been renderers which will render
the name for an unknown highway value, so 'highway=social_path;
name=Shortcut' would show on the map as a label saying 'Shortcut'. There are
routers which will assume a default speed for unknown highway values. That
isn't always daft: you can envisage a single typo in one two-node way
('highway=mptorway, maxspeed=70mph, surface=paved, access=yes...') which
would otherwise break routing across a continent if the router was entirely
fault-intolerant.
To widen the discussion, introducing new core path values is bad OSM
citizenship.
Path tagging in OSM is notoriously complex, for one reason: people keep
reworking the core model to deal with their edge-cases.
We began with highway=footway/bridleway/cycleway/track, surface=*, and
access/foot/bicycle/horse/motor_vehicle=*. With these values, you can model
the essential characteristic of 95% of paths (conservative estimate).
Some people identified edge cases which they felt were not adequately
captured by this scheme, and therefore introduced a new, more complex
scheme, highway=path.
Later, others identified still further edge cases and introduced yet more
values: access/foot/bicycle/etc.=designated. Later later, others identified
still further edge cases, and we got access/foot/bicycle/etc.=official.
And so on. Every such change has made the system more impenetrable for
mappers and consumers, and we have, I believe, a collective responsibility
to keep OSM usable. I won't bore you with the details of the Lua tag parsers
I use for cycle.travel's path routing and rendering, but they are insanely
complex - hashes upon hashes upon hashes, special cases upon special cases -
and yet there are still bugs and edge cases. How anyone who doesn't have
years of experience in OSM is meant to cope with this, I don't know.
The best way to map these, without adding further burdens to mappers or
consumers, is to use broad-brush, well-established tags such as:
highway=footway
access=no
and then, if you feel this doesn't fully capture your particular edge case,
some sort of _additional_ tag:
social_path=yes
(The classic example of this is motorroad=yes, which the German community
introduced as a refinement on highway=trunk/primary, and which has since
become a successful and widely-adopted tag without breaking highway routing
or rendering.)
But please don't extend existing core tagging, such as highway=, in new and
exciting ways. It doesn't necessarily solve the problem in the way you think
it will, and it makes it harder for everyone to use OSM.
cheers
Richard
--
View this message in context:
http://gis.19327.n5.nabble.com/Subject-Feature-Proposal-RFC-highway-social-path-tp5870639p5870698.html
Sent from the Tagging mailing list archive at Nabble.com.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path
On Sat, Mar 26, 2016 at 06:17:52AM -0700, Richard Fairhurst wrote: > Alan McConchie wrote: > > access=no is absolutely a core tag within OSM, dating back to the very first > iteration of Map Features. It isn't "easily ignored". Any router which > ignores it is unambiguously bugged. Any renderer intended for walkers' > consumption which shows it as a walkable path is unambiguously bugged. > > We began with highway=footway/bridleway/cycleway/track, surface=*, and > access/foot/bicycle/horse/motor_vehicle=*. With these values, you can model > the essential characteristic of 95% of paths (conservative estimate). > > The best way to map these, without adding further burdens to mappers or > consumers, is to use broad-brush, well-established tags such as: > > highway=footway > access=no > > and then, if you feel this doesn't fully capture your particular edge case, > some sort of _additional_ tag: > > social_path=yes > +1 ael ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] setting proposals to abandoned
Martin Koppenhoefer wrote on 2016/03/26 12:49: Am 26.03.2016 um 11:49 schrieb Mateusz Konieczny : "what would be a reasonable threshold" - no edits in this or previous year is my typical method to recognise something on internet as dead. but wouldn't it be necessary to look at actual map edits rather than on a wiki page > (i.e. has the tag been applied to objects in the last year)? If the definition is > settled there is maybe no need to make changes to the wiki, you can just use the tag. Yes but one thing is the proposal, the other is the actual usage of tags. While the actual map usage should be documented on the tag page, still the proposal can be considered abandoned. The typical thing about Abandoning is that the proposer has "ceased to support or look after" [Oxford], the active role of the proposer would be Cancelling. There is a wiki page about the proposal process, which recommends abandoning after 3 month, which I think is too tight. In the specific case, the proposal was to fully replace 'kindergarten' with 'childcare', which was proposed 28 months ago, and has also not happened in practical tagging. This is quite in contrast to successful changing schemes, such as nursing_home to social_facility + sub-tagging. The unfortunate issue with 'childcare' was the insufficient differentiation from other tags in the first proposal, and the unnecessary attempt to replace an established tag in the second. The tag page is extremely vague, so at the end of the day nobody knows what an object such tagged is in reality. tom ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] setting proposals to abandoned
The status should in some way make it clear to people who use the wiki as a tagging reference whether the contents of the page should be taken into account or not. If the proposal has been "abandoned" but what is suggests has nonetheless entered wider usage, then it is de facto accepted by the community, and you could not easily make a case to say it should not be followed. If the main wiki has not (yet) been updated following the proposal, then labelling the proposal as "accepted de facto" would be a simple way of confirming that it is still relevant. //colin On 2016-03-26 15:18, Tom Pfeifer wrote: > Martin Koppenhoefer wrote on 2016/03/26 12:49: Am 26.03.2016 um 11:49 schrieb > Mateusz Konieczny : > > "what would be a reasonable threshold" - no edits in this or previous > year is my typical method to recognise something on internet as dead. > but wouldn't it be necessary to look at actual map edits rather than on a > wiki page > (i.e. has the tag been applied to objects in the last year)? If the > definition is > settled there is maybe no need to make changes to the wiki, you can just use > the tag. Yes but one thing is the proposal, the other is the actual usage of tags. While the actual map usage should be documented on the tag page, still the proposal can be considered abandoned. The typical thing about Abandoning is that the proposer has "ceased to support or look after" [Oxford], the active role of the proposer would be Cancelling. There is a wiki page about the proposal process, which recommends abandoning after 3 month, which I think is too tight. In the specific case, the proposal was to fully replace 'kindergarten' with 'childcare', which was proposed 28 months ago, and has also not happened in practical tagging. This is quite in contrast to successful changing schemes, such as nursing_home to social_facility + sub-tagging. The unfortunate issue with 'childcare' was the insufficient differentiation from other tags in the first proposal, and the unnecessary attempt to replace an established tag in the second. The tag page is extremely vague, so at the end of the day nobody knows what an object such tagged is in reality. tom ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] setting proposals to abandoned
Colin Smale wrote on 2016/03/26 15:45: The status should in some way make it clear to people who use the wiki as a tagging reference whether the contents of the page should be taken into account or not. If the proposal has been "abandoned" but what is suggests has nonetheless entered wider usage, then it is de facto accepted by the community, and you could not easily make a case to say it should not be followed. If the main wiki has not (yet) been updated following the proposal, then labelling the proposal as "accepted de facto" would be a simple way of confirming that it is still relevant. This is fine when there is one clear proposal and people just started following it. In the specific case cited, it is unclear which of the two proposals the users of the tag follow. The tag page is there however, and the users can document what they do. tom ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] service = parking_access for main ways on a parking lot
The qualifier service=parking_aisle was originally introduced [1] to structure car parks with a few main access ways and lots of small aisles, to avoid clutter in lower zoom levels. It is highly successful with over 2 Mio uses. The description says that, however "The main way(s) on the parking lot, for entering and connecting multiple parking_aisle, should be mapped with highway=service, only." Apparently, mappers feel a void in tagging highway=service only, without a qualifier, and add parking_aisle to all ways related to parking, thus losing the structure. Thus I would like to use a different qualifier for those ways entering the lot and connecting the aisles, e.g. service=parking_access. This does not break any consumer, is not used so far (ok, once, exactly for the purpose), and also solves a recent question in the wiki for a related problem, a separate parking road parallel to a main road. Opinions? tom [1] https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/service%3Dparking_aisle&oldid=391287 [2] https://wiki.openstreetmap.org/wiki/Talk:Key:service#parking_but_no_aisle ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] service = parking_access for main ways on a parking lot
sent from a phone > Am 26.03.2016 um 17:15 schrieb Tom Pfeifer : > > Thus I would like to use a different qualifier for those ways entering > the lot and connecting the aisles, e.g. service=parking_access. > > This does not break any consumer, is not used so far (ok, once, exactly for > the purpose), and also solves a recent question in the wiki for a related > problem, a separate parking road parallel to a main road. > > Opinions? I agree with the intention to have 2 different classes of service. sometimes, not too rarely, those ways are not only for access to the parking but also to pass through, to go to the main entrance (e.g. for the boss, for honorable guests, for disabled, etc.) or to go to another site. Would we have different tags for all those possibilities? I think I prefer service without additional qualifier for the second class, but if you come up with something more neutral that still bears the hierarchy connotation, I could support it. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] service = parking_access for main ways on a parking lot
Gets my vote. On 2016-03-26 17:15, Tom Pfeifer wrote: > The qualifier service=parking_aisle was originally introduced [1 [1]] to > structure car parks with a few main access ways and lots of small aisles, > to avoid clutter in lower zoom levels. > > It is highly successful with over 2 Mio uses. > > The description says that, however "The main way(s) on the parking lot, > for entering and connecting multiple parking_aisle, should be mapped with > highway=service, only." > > Apparently, mappers feel a void in tagging highway=service only, without > a qualifier, and add parking_aisle to all ways related to parking, thus > losing the structure. > > Thus I would like to use a different qualifier for those ways entering > the lot and connecting the aisles, e.g. service=parking_access. > > This does not break any consumer, is not used so far (ok, once, exactly for > the purpose), and also solves a recent question in the wiki for a related > problem, a separate parking road parallel to a main road. > > Opinions? > > tom > > [1] > https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/service%3Dparking_aisle&oldid=391287 > [2] https://wiki.openstreetmap.org/wiki/Talk:Key:service#parking_but_no_aisle > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging Links: -- [1] https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/service%3Dparking_aisle&oldid=391287___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] service = parking_access for main ways on a parking lot
Am 26.03.2016 um 17:15 schrieb Tom Pfeifer :
Thus I would like to use a different qualifier for those ways entering
the lot and connecting the aisles, e.g. service=parking_access.
This does not break any consumer, is not used so far (ok, once, exactly for
the purpose), and also solves a recent question in the wiki for a related
problem, a separate parking road parallel to a main road.
Martin Koppenhoefer wrote on 2016/03/26 17:59:
I agree with the intention to have 2 different classes of service.
sometimes, not too rarely, those ways are not only for access to the parking
but also to pass through, to go to the main entrance (e.g. for the boss, for
honorable guests, for disabled, etc.) or to go to another site. Would we have
different tags for all those possibilities? I think I prefer service without
additional qualifier for the second class, but if you come up with something
more neutral that still bears the hierarchy connotation, I could support it.
Interesting perspective. So we have currently
('parking_aisle', 'drive-through', 'driveway')
which are treated as the minor class in Carto.
'alley' is another minor value not considered there.
So what would be a good value to be wider than just parking?
- access is more general than parking_access, but
not very self-explanatory. Used 500 times,
predominantly with highway=service
- main implies some importance, is used 450 times in
the railway context.
tom
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
[Tagging] How to tag a natural, man-organised feature?
Hello, there. I'm wondering: there are tons of natural features that have been modified or organized by humans, like springs which emerge in man-made ponds. Is there a tag used to model this organization, like organised=yes? Awaiting your answers, Regards. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging parade_ground?
On 26/03/2016 7:48 PM, Martin Koppenhoefer wrote: sent from a phone Am 26.03.2016 um 08:40 schrieb Warin <61sundow...@gmail.com>: Would landuse=parade_ground be suitable.. or is there any other idea? can you describe a bit more what this looks like, and how it is exactly used? Is this a piece of city where parades will occasionally take place (but which otherwise is just an accessible open space), an area where they exercise their parades, an area where people go to see a parade, or ... This one example is a dedicated space for Police parades "A beautiful summers morning in Goulburn" https://www.facebook.com/nswpoliceacademy/photos/pcb.884817434965564/884815968299044/?type=3&theater:-) Photos and videos http://www.goulburnpost.com.au/story/3553700/police-attestation-december-11-2015-photos-videos/?cs=181 In OSM currently http://www.openstreetmap.org/way/121391269 --- If you do a google on police parade ground you get a few hits... though some look to be used for other purposes too. Humm the first pages are Indian ... http://wikimapia.org/5066552/Naigon-police-parade-ground https://en.wikipedia.org/wiki/Rajarathinam_Stadium One from Vietnam https://www.flickr.com/photos/aodcurator/4297473600 One from the UK http://www.britishpathe.com/video/police-passing-out-parade cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] service = parking_access for main ways on a parking lot
Tom Pfeifer writes: > The qualifier service=parking_aisle was originally introduced [1] to > structure car parks with a few main access ways and lots of small aisles, > to avoid clutter in lower zoom levels. > > It is highly successful with over 2 Mio uses. > > The description says that, however "The main way(s) on the parking lot, > for entering and connecting multiple parking_aisle, should be mapped with > highway=service, only." I had no idea that it said that. What I do is * highway=service service=parking_aisle ways that are basically only to get to parking spaces * highway=service service=driveway ways connecting to the real roads and sort of going near where you are trying to go when you want to park in the parking lot (carpark), just enough to be connected, and trying to pick the places that are more important/through roads The latter is more or less what your service=parking_access is trying to do. But if for example you want to pick someone up at the front door of a supermarket, and not park, you'd use them. So parking_access really isn't quite right for most of these ways. signature.asc Description: PGP signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] service = parking_access for main ways on a parking lot
> On Mar 26, 2016, at 4:56 PM, Greg Troxel wrote: > > > Tom Pfeifer writes: > >> The qualifier service=parking_aisle was originally introduced [1] to >> structure car parks with a few main access ways and lots of small aisles, >> to avoid clutter in lower zoom levels. >> >> It is highly successful with over 2 Mio uses. >> >> The description says that, however "The main way(s) on the parking lot, >> for entering and connecting multiple parking_aisle, should be mapped with >> highway=service, only." > > I had no idea that it said that. > > What I do is > > * highway=service service=parking_aisle >ways that are basically only to get to parking spaces > > * highway=service service=driveway >ways connecting to the real roads and sort of going near where you >are trying to go when you want to park in the parking lot (carpark), >just enough to be connected, and trying to pick the places that are >more important/through roads > > The latter is more or less what your service=parking_access is trying to > do. But if for example you want to pick someone up at the front door > of a supermarket, and not park, you'd use them. So parking_access > really isn't quite right for most of these ways. I too have been using service=driveway for the non-parking highway=service roads found in parking areas. It wasn’t until this discussion came up that I realized the wiki said there should be no service=* tag for those. It seems to me that any highway=service ought to have a service=* tag. Whether the specific case being discussed needs a new service=parking_access tag or if service=driveway is okay would be the discussion I’m interested in. To Tom’s point, I think a roads for many commercial areas would have a big grey area in deciding between driveway and parking_access as often the route to the main entrance and/or loading docks is indistinguishable from the other roads in the area that simply service parking. smime.p7s Description: S/MIME cryptographic signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
