Re: [Tagging] Deprecate water=pond?

[Alessandro Sarretta]

On 11/11/20 14:10, Brian M. Sperlongano wrote:
Is it actually desirable to distinguish a "lake" from a "pond"?  If 
so, what is the difference?  Is it just that a body of water is named 
"XYZ Pond" versus "XYZ Lake"?  If so, isn't water=pond versus 
water=lake derived from and redundant with name?


Is there a conceivable scenario where a data consumer or renderer 
would care about the distinction between these two tags?


When I go walking in the mountains, I like do follow tracks that are 
close to ponds (in this case, small (~10m) body of water where animals 
can go to drink) and I can find many of them in a few kilometres. Lakes 
are very different from that :-)


Ale


--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com <http://ilsarrett.wordpress.com>

Research information:

 * Google scholar profile
   <http://scholar.google.it/citations?user=IsyXargJ&hl=it>
 * ORCID <http://orcid.org/-0002-1475-8686>
 * Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta>
 * Impactstory <https://impactstory.org/AlessandroSarretta>

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

Re: [Tagging] Deprecate water=pond?

[Alessandro Sarretta]

Hi,

I don't agree with the deprecation of water=pond. I find it perfect for 
small body of water like the ones you can see here for cows watering: 
https://www.openstreetmap.org/way/301144562


Ale

On 10/11/20 06:26, Joseph Eisenberg wrote:
The tag water=pond was added with a large number of other types of 
"water=*" in 2011, but it has a poorly defined description.


"A pond <https://en.wikipedia.org/wiki/Pond>: a body of standing 
water, man-made in most cases, that is usually smaller than a lake. 
Salt evaporation ponds should be tagged with landuse 
<https://wiki.openstreetmap.org/wiki/Key:landuse>=salt_pond 
<https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dsalt_pond>, 
open-air swimming pools — with leisure 
<https://wiki.openstreetmap.org/wiki/Key:leisure>=swimming_pool 
<https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dswimming_pool>."


So it might be artificial, like a landuse=reservoir or 
water=reservoir, but smallish. Or it might be natural like a 
water=lake, but smallish. However, nothing on the water=lake page 
defines a lower limit for the size of a lake.


This is a shame, because all the other values of water=* are clearly 
defined as only natural, or only artificial, and waterway=* features 
are also clearly divided. Furthermore, the original lags 
landuse=reservoir and landuse=basin were also clearly artificial, 
while lakes were natural.


But the biggest problem is that there is no way to define a lower size 
for a lake or reservoir, or an upper size for a pond. And the size of 
the area is easier available from the geometry of the feature, so it 
doesn't need to be mentioned in the tag.


I think the best option is to deprecate water=pond and suggest using 
water=lake for natural lakes, even small ones, and use water=reservoir 
or water=basin (or landuse=reservoir or =basin if you prefer) for the 
artificial ones.


-- Joseph Eisenberg

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

--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com <http://ilsarrett.wordpress.com>

Research information:

 * Google scholar profile
   <http://scholar.google.it/citations?user=IsyXargJ&hl=it>
 * ORCID <http://orcid.org/-0002-1475-8686>
 * Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta>
 * Impactstory <https://impactstory.org/AlessandroSarretta>

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

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

[Alessandro Sarretta]

Hi Graeme,

On 09/08/20 01:12, Graeme Fitzpatrick wrote:
On Sun, 9 Aug 2020 at 03:39, Matthew Woehlke > wrote:


We already have capacity and capacity=disabled, what's the problem
with adding more
capacity:*?


But what number do we show for "capacity"?

I started wondering about this after one of the carparks you mentioned 
in Quantico recently showed capacity 15, with 11 car spaces + 4 
motorbike spaces. Should that be =15, or =11 + 4?


So, do we have a shopping centre parking lot with capacity=100, or 
should we have capacity:"vehicle"=60; capacity:motorbike=10; 
capacity:disabled=10; capacity:prams***=6; capacity:ev_charging=4; 
capacity:(temporary/short_term/click'n'collect)=5; capacity:loading=5


the wiki (https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking) 
seems to me quite clear about this, defining "capacity" as "The amount 
of available parking spaces, /including/ all special parking spaces 
(e.g., disabled). Read talk 
 page on 
this."


If one has all the available information, I think that the tag 
capacity=* and tags capacity:*=* can and should stay together.


Ale

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

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

[Alessandro Sarretta]

Dear Matthew,

On 06/08/20 22:52, Matthew Woehlke wrote:
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 


I've always had some doubts in using parking_space=disabled.

When I had to map parking spaces specifically designed for disabled 
people (i.e. only disabled people can park there), I've used 
disabled=designated, because it defines (or that is my interpretation) 
an access condition and it applies it to disabled people.


While parking_space=disabled seems to be more generic.

But if the default use of parking_space=disables means exactly that only 
disabled people can park there, I'm ok to use it (and change my edits), 
but in this case an explicit description in this sense is required in 
the wiki page.


Best,

Ale


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

Re: [Tagging] what is the "temp" tag?

[Alessandro Sarretta]

I'm just guessing, and I try with a sort of placeholder for saying that 
some tag is "temporary"... even if this sounds not really useful :-)


Ale

On 05/08/20 10:41, Frederik Ramm wrote:

Hi,

https://taginfo.openstreetmap.org/keys/temp#values

any guesses as to what this might mean?

I stumbled across it when reverting some vandalism on
https://www.openstreetmap.org/way/784166844 but that street has been
split so many times by people adding turn restrictions that the "person
creating v1 of something" is just the person who split something and if
I asked them what they meant by temp=tag they'll probably just shrug.

Bye
Frederik



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

Re: [Tagging] Amenity=fountain

[Alessandro Sarretta]

Hi Stuart,

On 07/03/20 08:04, European Water Project wrote:

Dear All,

On Feb 4th, we significantly clarified the definition of 
amenity=fountain after numerous discussions. 
https://lists.openstreetmap.org/pipermail/tagging/2020-February/050876.html 



It seems the core of our changes were undoneon Feb 26th
https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dfountain&diff=1962588&oldid=1954415 

 causing more confusion on the subject of what constitutes a 
fountain. 
https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dfountain#Use_for_drinking_water.3F
Maybe you can ask to the user 
https://wiki.openstreetmap.org/wiki/User:MalgiK the reason for this (it 
seems he refers to the original proposal wording).
How does one sign up to received notifications about changes on 
specific pages ?


There's a star on the menu bar on top of the wiki page, just after "View 
history", where you can "Add this page to your watchlist"


Ale

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

Re: [Tagging] Active volcanoes

[Alessandro Sarretta]

On 24/01/20 15:52, Cascafico Giovanni wrote:

How to tag its recent activity, ie for touristic purposes?


Maybe a last_eruption:date=* tag (with a documented source) could be 
enough do define recent activities?


Ale


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

Re: [Tagging] RFC free_water

[Alessandro Sarretta]

Hi,

On 17/01/20 12:08, European Water Project wrote:


 2. Re: RFC free_water (François Lacombe)


I see your point and agree it would be preferable to develop a more 
generalize nomenclature, but also think it is important to choose 
something that is understandable to a newbie.


If we chose charge:water 
=free 
we 
would need to differentiate when the water is free to anyone (yes in 
OSM speak) or just paying customers (customers in OSM speak).


We could use :
charge:water 
=/fee>

access = 
container = 

In the above, European Water Project would only include cafés, bars, 
etc. with
charge:water 
=free 


access = yes
container = bring_own


If you use the tag /access/ alone, it could refer to the "main" feature 
(the bar or restaurant...).


And water is probably too general... I try suggesting to use 
/tap_water/, that should clearly state that is not bottle water :-)


So it could be:

 * tap_water=yes/no/customers
 * tap_water:free=yes/no/customers
 * tap_water:container=*

This way it seems to me you should be able to cover all the 
possibilities clearly.


m2c

Ale

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

Re: [Tagging] Question about capacity:*=* on parking_space

[Alessandro Sarretta]

Hi Lionel,

On 17/01/20 10:52, Lionel Giard wrote:

Alesandro,

The thing is that disabled=designated is an access (so regulated by 
law), and would depend because each country's law vary (not every 
country enforce restriction for disabled parking or other type of 
vehicle...). Thus, it may be wrong to tag an access when it doesn't exist.


If the parking_space with specific symbology is regulated by law and 
only accessible by disabled persons (like in Italy), I think the tag 
disabled=designated express exactly that, and should be used.


If a parking space is not limited to disabled persons, what is the 
purpose to add a capacity:disabled=1? Maybe I'm missing your point... 
Could you please share and example where a parking space should have a 
capacity:disabled=1 but is not access-regulated?


Ale

While a tag that's only an attribute describing what type of parking 
exist, is unambiguous. It may be parking_space=* or access:*=* , both 
are "good" for that as they are unambiguous in their meaning. The only 
advantage of the second is that it is already used for amenity=parking 
and seems coherent to use for the parking_space in my opinion (even if 
it is only 1 place). The wiki page already mention all the different 
type because there are many other than disabled (like parent, women, 
electric charging,...) : https://wiki.openstreetmap.org/wiki/Key:capacity


marc,

The capacity:*=* tag should not be used alone (as described for any 
parking), it is an addition to the capacity=* tag. For example, a 
place marked as "capacity=1" and "capacity:disabled=1" means that the 
1 capacity is disabled. A better example is for an amenity=parking, 
you have a parking with "capacity=12" and "capacity:disabled=3" it 
means 3 of the 12 parking space are disabled.
Theoretically, all parking_space should be capacity=1 (and if 
necessary capacity:*=*) but the advantage (as mentioned above) is that 
it would use the same tagging than for amenity=parking. Thus we 
wouldn't use two different scheme for the same thing.



Le ven. 17 janv. 2020 à 09:52, PanierAvide > a écrit :


Hello Lionel,

I totally agree with that, I never understood this special
treatment of amenity=parking_space, and so I'm using capacity:*=*
with that. My use case is for disabled people parking spaces :
just look for capacity:disabled=* and you're good to go, whatever
it is a parking or parking_space.

Best regards,

Adrien P.

Le 17/01/2020 à 09:36, Lionel Giard a écrit :

Hello everyone,

I saw that on the parking_space wiki page it says that we
shouldn't use capacity:*=* on parking_space, and instead use the
access tag. But why is this the case? It seems logical to use
capacity:disabled=* on a parking_space for disabled people or
capacity:charging=* on a parking_space for electric vehicles that
are charging. And there is not always legal access linked to
these "special" parking spaces (e.g. I don't think there are many
places regulating parking on parents' parking spaces in the law).
It seems strange to forbid this, while promoting the tagging of
"capacity=*". ^_^

I therefore propose to change this description to favour this
tagging (when useful) instead of prohibiting it. What do you
think about this?

Kind Regards,
Lionel

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

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


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

Re: [Tagging] Question about capacity:*=* on parking_space

[Alessandro Sarretta]

Hi Lionel,

from what I've understood, the parking_space tag is meant to identify 
exactly one parking space, so the capacity whould be always 1...


In the specific case of parking spaces for disables persons, 
unfortunately there are many way of tagging it... In this issue related 
to the visibility in the OSMand app there are probably almost all of 
them. https://github.com/osmandapp/Osmand/issues/6805


I'm currently using the one that seems to me the simplest one: 
amenity=parking_space + disabled=designated


m2c

Ale

On 17/01/20 09:36, Lionel Giard wrote:

Hello everyone,

I saw that on the parking_space wiki page it says that we shouldn't 
use capacity:*=* on parking_space, and instead use the access tag. But 
why is this the case? It seems logical to use capacity:disabled=* on a 
parking_space for disabled people or capacity:charging=* on a 
parking_space for electric vehicles that are charging. And there is 
not always legal access linked to these "special" parking spaces (e.g. 
I don't think there are many places regulating parking on parents' 
parking spaces in the law).
It seems strange to forbid this, while promoting the tagging of 
"capacity=*". ^_^


I therefore propose to change this description to favour this tagging 
(when useful) instead of prohibiting it. What do you think about this?


Kind Regards,
Lionel

___
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] Correct use of height with kerb

[Alessandro Sarretta]

Hi Volker,

the values raised and lowered for a kerb (node) are related to the 
vertical gap between sidewalk/crossing and not really to the direction. 
Raised means that there is a (more or less) big transition (in the kerb 
page [1] it says >3 cm), while lowered means a smaller transition, and 
flush no gap at all. All of this regardless of the direction (up or down).


Ale

[1] https://wiki.openstreetmap.org/wiki/Key:kerb

On 11/01/20 11:08, Volker Schmidt wrote:
I do have a related question, regarding the kerb values lowered|raised 
on a node.
Assume you find yourself on a pedestrian crossing across a road that 
has an adjacent sidewalk and cycleway on the same side.
The main carriageway is separated from the (foot-only) sidewalk by a 
kerb and that is separated from the cycleway by another kerb. The 
first kerb is typically raised (as the tag refers to a kerb between 
the road and the sideway, and the latter is always higher than the 
road), but the second kerb (let's assume that the cycle path is 
physically higher than the footway) is it kerb=raised (a step upward 
from the footwalk to the cycleway) or is it kerb=lowered (a step down 
from the cycleway to the sidewalk)? I have come across a number of 
these in the same context that Ale mentioned. I fear my conclusion is 
that  the values "lowered" and "raised" on a node "kerb" need to be 
accompanied by direction=forward|backward (like stop and give-way, for 
example) with respect to the "crossing" way. I don't like my 
conclusion, but it seems inevitable.

(I hope I'm wrong on this last statement)

On Sat, 11 Jan 2020 at 06:49, Alessandro Sarretta 
mailto:alessandro.sarre...@gmail.com>> 
wrote:


Dear all,

I'm doing some work cleaning the edits we've done around Padova
for the local plan for the elimination of architectural barriers
(some references here: https://doi.org/10.5281/zenodo.3370704).

The height of kerbs, in this context defined as the nodes at the
intersection between sidewalks and crossings, is quite an
important element for the evaluation of accessibility of sidewalks
and crossings. I think the agreed tagging system is:

kerb=yes/lowered/raised/flush + kerb:height=

as described here

https://wiki.openstreetmap.org/wiki/Key:kerb#kerb:height.3D.3Cheight.3E.3Cunit.3E

Around Padova I found some inconsistencies that I'm going to
correct, but I see similar ones around the world and I'd like to
ask you if you think they should be corrected, when found.

Here the questions:

  * should the tag barrier=kerb be always avoided in these cases
and deleted when found? (

https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkerb#Possible_Tagging_Mistakes
)
  * is the tag height=* to be always changed into kerb:height=* ?

Thank you,

Ale

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


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

[Tagging] Correct use of height with kerb

[Alessandro Sarretta]

Dear all,

I'm doing some work cleaning the edits we've done around Padova for the 
local plan for the elimination of architectural barriers (some 
references here: https://doi.org/10.5281/zenodo.3370704).


The height of kerbs, in this context defined as the nodes at the 
intersection between sidewalks and crossings, is quite an important 
element for the evaluation of accessibility of sidewalks and crossings. 
I think the agreed tagging system is:


kerb=yes/lowered/raised/flush + kerb:height=

as described here 
https://wiki.openstreetmap.org/wiki/Key:kerb#kerb:height.3D.3Cheight.3E.3Cunit.3E


Around Padova I found some inconsistencies that I'm going to correct, 
but I see similar ones around the world and I'd like to ask you if you 
think they should be corrected, when found.


Here the questions:

 * should the tag barrier=kerb be always avoided in these cases and
   deleted when found? (
   
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkerb#Possible_Tagging_Mistakes
   )
 * is the tag height=* to be always changed into kerb:height=* ?

Thank you,

Ale

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

Re: [Tagging] footway=crossing in detailed tagging

[Alessandro Sarretta]

Hi Mateusz,

On 15/12/19 12:30, Mateusz Konieczny wrote:
Let's say that we have footway mapped separately from the road, road 
has footways on both sides.


Footway has surface=paving_stones, road has surface=asphalt.

There is a crossing, made from three ways:
- (1) highway=footway surface=paving_stones (for a bit from centerline 
of sidewalk to the curb)

- (2) highway=footway surface=asphalt (for part on the carriageway)
- (3) again highway=footway surface=paving_stones for part from curb 
to the centerline


How footway=crossing tag should be applied?

To all three or just carriageway surface - (2) segment?


in my opinion there should be no doubt in assigning only to 2, from kerb 
to kerb.


Ale


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

Re: [Tagging] Feature Proposal - RFC - park_drive

[Alessandro Sarretta]

Hi Martin,

my doubt on your proposal is that I think the only useful value would be 
"designated" (anyway, can you share any example/picture of a sign 
describing a park specificly designated for carpooling?). But in this 
case I'd support


As far as I know, in a general-use parking (without specific access 
conditions) anyone can park, meet with a friend, and then continue the 
journey with only one car... What is the purpose to explicitly add this 
information?


Ale

On 05/12/19 11:08, Martin Scholtes wrote:

Hello,

I would like to inform you that I have made a suggestion about park and
drive. This resulted from a discussion in the OSM DE Telegram Chat.

https://wiki.openstreetmap.org/wiki/Proposed_features/park_drive
Definition: Information that can be taken on this parking lot to form a
carpool.

I would be pleased about suggestions.

Forgive me, but this is my first time on that list.


Greetings

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] Feature Proposal - Voting result - Pedestrian lane

[Alessandro Sarretta]

Thank you Markus for this summary.

I think that the issue of having a good way to describe marked lanes on 
the road dedicated for people to walk is still there. In my opinion it 
needs a more extensive discussion and some tagging and graphic examples 
to show simple and complex application.


As an example, I'm thinking about detailed mapping for pedestrian (or 
even people with disabilities) that might need additional information. 
Information on width could help to understand if that footway is safe 
for wheelchair, or colour could help visually impaired people (or even 
smoothness values that can differ from the main road).


In an example with pedestrian lanes (or let's call them footway lanes, 
or even sidewalk lanes, ...) on both sides of a two-ways road we could 
have on the left side a 1m-wide lane, on the right side a red lane.


How should we map them?

pedestrian_lane=both
pedestrian_lane:left:width=1 m
pedestrian_lane:right:colour=red

or something like

footway=lane
footway:left:width=1 m
footway:right:colour=red

And in case on the left we have a shared cycle/foot lane?

cycleway:left=lane
pedestrian_lane=left
segregated=no

or

cycleway:left=lane
footway:left=lane
segregated=no

I think discussing of specific examples could help us clarifying which 
solution is better (or more usable).


m2c

Ale

On 03/12/19 21:35, Markus wrote:

Dear all,

The voting on the proposal for a new key pedestrian_lane=* for lanes
designated for pedestrians is over. 8 people voted for the proposal, 5
against it and 1 person abstained. This is an approval by 62%, which
is below the required 75% majority. Therefore the proposal has been
rejected.

https://wiki.openstreetmap.org/wiki/Proposed_features/Pedestrian_lane

The following reasons for opposing the proposal were given:

   - footway[:left/right]=lane should be used instead of the proposed
pedestrian_lane=left/right/both. (mentioned twice)

   - More discussion is needed. (mentioned twice)

   - Disagreement with the definition of sidewalk=* being a raised or
otherwise physically separated footpath at the side of a road.
(mentioned once)

In my opinion, footway[:left/right]=lane isn't a good idea for the
following reasons: 1. footway=lane is a contradiction, as a lane (part
of a road/path) isn't a footway (separate path). 2.
sidewalk=left/right/both and footway[:left/right]=lane would have two
different syntaxes, which were confusing. 3. lane would be the only
value which were a departure from the usual tag syntax where the value
is variable and the key remains constant.

Many thanks to the (unfortunately rather few) people who took part in the vote.

Best regards

Markus

___
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] Use of a site relation for grouping parking spaces

[Alessandro Sarretta]

Thank to everybody, the text has been changed (by Mateusz Konieczny) 
accordingly: 
https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dparking_space&diff=1928515&oldid=1890083


Ale

On 03/12/19 23:42, Martin Koppenhoefer wrote:


sent from a phone


On 3. Dec 2019, at 20:32, Joseph Eisenberg  wrote:

I doubt it is useful to use a type=site relation with parking_space features at 
all. But your proposed rewording would be an improvement.


I mostly agree, although one could construct situations where you might want to 
relate e.g. parking ticket machines or surveillance cameras (located outside 
the parking and represented by nodes) to specific parkings. Generally it 
doesn’t seem helpful to require a site relation, in most cases it wouldn’t add 
anything.

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

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

[Alessandro Sarretta]

Dear tagging list,

looking on how to use the tag amenity=parking_space 
(https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space) I've 
always found the requirement that "parking spaces always have to be 
grouped together in a site relation tagged with type=site + 
site=parking" too complex and not really required by a general use case.


I can think about areas with maybe 10 amenity=parking_spaces and a 
surrounding amenity=parking, where I don't see any strong need to 
specify a relation to group the parking spaces together. Here an 
example: https://www.openstreetmap.org/way/658526498


Searching for a reason for this requirement, I haven't found here 
(https://wiki.openstreetmap.org/w/index.php?oldid=629318) a specific one.


Looking here 
(https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site), the 
reason to use the relation seems to be quite lighter: "Parking sites - 
useful for cases where parking entrances are mapped but parking area is 
not yet mapped. Once parking is mapped as an area with service roads 
marked site relation is no longer useful and may be safely deleted."


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."?


Thank you for any comment,

Ale

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

Re: [Tagging] Open Voting on Access Aisle

[Alessandro Sarretta]

Thanks Clifford,

I've tried to use your tagging system in an area close where I live. You 
can find here the way (https://www.openstreetmap.org/way/746061718) and 
here a picture from Google Streetview 
(https://www.google.it/maps/@45.428055,11.791072,3a,25.2y,347.58h,76.17t/data=!3m6!1e1!3m4!1sc04-aTnZlGZiu4i3Pm0Czw!2e0!7i13312!8i6656). 
Is this what you're proposing?


I think a few mapping examples could help in better understanding the 
proposal.


On 16/11/19 17:17, Clifford Snow wrote:



On Fri, Nov 15, 2019 at 11:22 PM Alessandro Sarretta 
mailto:alessandro.sarre...@gmail.com>> 
wrote:



There are a couple of things that are not totally clear to me:

  * in general, might these tags apply also to areas, rather than
only ways?

We already have highway=pedestrian. Are you suggesting that we also 
have highway=pedestrian + pedestrian=access_aisle? I probably wouldn't 
map an access aisle as an area but I'd be interested in hearing more.


No Clifford, I'm wondering if the area of the access_aisle could be 
mapped as an independent area (polygon instead of line), aside of the 
parking_space area.



  * I am a bit confused by /accessible_van/. Does it refer to vans
instead of cars? In this case I think it is not an information
related to the aisle, but to the parking_space. If it is still
for disabled persons, shouldn't it be access_aisle=disabled
anyway?

Vans can be equipped with either ramps or lifts to load and unload 
wheelchairs.  The ramps and lifts require an extra wide space, in the 
US, it's 8 feet, about 2.4 meters. These vans are quite common in the 
US. I haven't seen any cars similarly equipped.


If the aisle is for disabled people, I'd use access_aisle=disabled. 
Maybe we can add some quantitative details as width=* to describe the 
extra space.


Ale

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

Re: [Tagging] Open Voting on Access Aisle

[Alessandro Sarretta]

Thank you Clifford,

I find you proposal quite useful and relevant.

There are a couple of things that are not totally clear to me:

 * in general, might these tags apply also to areas, rather than only ways?
 * I am a bit confused by /accessible_van/. Does it refer to vans
   instead of cars? In this case I think it is not an information
   related to the aisle, but to the parking_space. If it is still for
   disabled persons, shouldn't it be access_aisle=disabled anyway?

Best,

Ale

On 15/11/19 20:24, Clifford Snow wrote:
Since there has been no new discussion and I've modified the proposal 
to accommodate concerns on the original Draft, I'm opening the 
proposal up for voting. Please go to 
https://wiki.openstreetmap.org/wiki/Proposed_features/access_aisle to 
vote on the proposal.


Thanks in advance,
Clifford

--
@osm_washington
www.snowandsnow.us 
OpenStreetMap: Maps with a human touch

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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Alessandro Sarretta]

Hi Clifford,

On 02/11/19 20:35, Clifford Snow wrote:

Markus,
I like your proposal but think it needs to clarify the difference 
between a pedestrian lane and a shoulder [1]. In the US, most (many?) 
states allow pedestrians to walk on shoulders if there is no 
sidewalk/footway, with the exception of motorways. How would a mapper 
know if this is a shoulder or a pedestrian lane?


AFAIK shoulders are, in general, thought for vehicles in case of an 
emergency and present in big highways 
(https://en.wikipedia.org/wiki/Shoulder_(road)), while pedestrian lanes 
are made explicitly for pedestrians, especially in small roads in an 
urban context.


Ale


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

[Tagging] Using Corine Land Cover definitions for land cover in OSM?

[Alessandro Sarretta]

I'm not against natural=badlands for areas that are covered by a non 
vegetated surface in an erosive context with steep slopes (as per 
https://en.wikipedia.org/wiki/Badlands). Anyway they seem to be a more 
specific case than a "simple" bare soil.


I think that, in general, when dealing with land cover things in 
OpenStreetMap, we should really try and use some knowledge from standard 
definitions, e.g. Corine Land Cover CLC). I see that there is already a 
page defining connections between OSM elements and CLC classes [1]


In the case of /badlands/, they are mentioned as one of the examples in 
/3.3.3. Sparsely vegetated areas/ [2].


I'm quite new in discussions about land cover in OSM, but wouldn't it be 
useful to add, in addition to OSM-specific tags like natural=bare_rock, 
natural=shingle,  natural=scree, ... a tag to reference standard land 
cover classification?


I see that a tag /CLC:code /[3] already exists and used more than 30 
times, but it seems to be used only in case of imports and it is 
suggested (with a very weak motivation, IMHO) to be deleted after 
editing those areas after import.


In the example of badlands, would it be useful to have both 
/natural=badlands /(or any other agreed OSM-spefici tag) + /CLC:code=333 
and//or /land_cover=sparsely_vegetated_areas /?


I see many useful uses coming from this.. but I could be wrong...

Any ideas?

Ale

[1] https://wiki.openstreetmap.org/wiki/Corine_Land_Cover

[2] 
https://land.copernicus.eu/user-corner/technical-library/corine-land-cover-nomenclature-guidelines/html/index-clc-333.html


[3] https://wiki.openstreetmap.org/wiki/Key:CLC:code


On 20/10/19 07:31, Joseph Eisenberg wrote:

Perhaps the term “badlands” is only used in a North America. Wikipedia
has a description:

"Badlands are a type of dry terrain where softer sedimentary rocks and
clay-rich soils have been extensively eroded by wind and water. ...
They are characterized by steep slopes, minimal vegetation" and thin
soil - but not exposed bedrock, usually.

Photo examples:

1) Chinle Badlands, Utah: https://en.wikipedia.org/wiki/File:Chinle_Badlands.jpg
2) Badlands near Coober Pedy in central Australia:
https://www.alamy.com/the-badlands-area-near-coober-pedy-in-central-australia-image67285952.html
3) Drum Badlands, Alberta: https://en.wikipedia.org/wiki/File:Drumbadlands.jpg
4) Las Médulas, Spain:
https://en.wikipedia.org/wiki/File:Panorámica_de_Las_Médulas.jpg
5) Valle de la Luna, Argentina:
https://en.wikipedia.org/wiki/File:P1010357_1.JPG
6) Badlands National Park, South Dakota:
https://en.wikipedia.org/wiki/File:Badlands00503.JPG

- Joseph

On Sun, Oct 20, 2019 at 11:14 AM Warin <61sundow...@gmail.com> wrote:

On 20/10/19 11:19, Joseph Eisenberg wrote:

How should areas of bare soil, such as badlands, be tagged?

Currently there are documented tags for dry areas of bedrock, stones and sand:

natural=bare_rock, natural=shingle,  natural=scree, and natural=sand

For tidal areas, beaches and wetlands there's also natural=beach,
natural=shoal and wetland=mud

However, there's no documented, common tag for dry areas of exposed
clay, silt or mixed soil.

natural=badlands has been used 5 times, but this is rather specific
and may not be well-known outside of North America:
https://taginfo.openstreetmap.org/tags/natural=badlands

natural=desert is common, but includes all kinds of vegetated and
unvegetated arid areas; many of these can be tagged with natural=
grassland, heath, scrub, sand, scree etc.

Desert is a climate, not a land cover nor a land form. Some deserts include 
'lakes'.

The key natural has climate, land form and land cover all in the one tagging 
scheme, I don't think is is a good scheme and would be better separated into 
the individual things it is trying to tag.


natural=clay has been used twice:
https://taginfo.openstreetmap.org/tags/natural=clay

natural=earth has been used 20 times:
https://taginfo.openstreetmap.org/tags/natural=earth

natural=bare_earth has 23 uses:
https://taginfo.openstreetmap.org/tags/natural=bare_earth

There's also natural=pebbles with 67 uses
(https://taginfo.openstreetmap.org/tags/natural=pebbles)
and natural=gravel 90 times -
https://taginfo.openstreetmap.org/tags/natural=gravel

But most of those could be scree or shingle, which would be more specific.

Would it be best to describe the type of soil, like natural=clay,
=silt, =earth, =pebbles, =gravel?

Better to tag specific things rather than a group.


Should mappers use surface=* without another top-level tag?

No.


Should natural=bare_earth be used in general for clay and other bare soils?

Or is natural=badlands best to describe the specific feature of an
arid area where the bare soil is exposed due to erosion?

I have no idea of what 'badlands' are .. from your information it is not single 
land cover nor a land form.
So it is a climate? A climate that causes erosion to a bare surface? No 
vegetation?






___
Tagging m

Re: [Tagging] How to tag flood prone points and areas?

[Alessandro Sarretta]

Dear Immaculata,

if you want to describe "things" that are prone to floods, it seems to 
me that the tag /flood_prone=yes/ can be the right one.


I have a few doubts on how this information has been collected: are 
there official maps with areas prone to flood and you have selected 
assets in that area or you interviewed people who told you that some 
specific assets were impacted by floods in the past?


If the second is true, verifiability and return times are important 
issues that have to be tackled and somehow mapped.


Ale

On 31/08/19 05:21, Immaculate Mwanja wrote:

Hi there!

In the summer of 2018, we conducted a project called Assets and 
Threats mapping 
under 
the Ramani Huria project in Dar es Salaam, Tanzania that aims to make 
Dar es Salaam a more flood-resilient city. In this project, we focused 
on the assets/amenities in the city that are important to the 
community and are at risk of flooding or not.


After collecting all the information, we decided we should upload them 
in OSM to be shared with the world since it was a successful project 
to some extent. The challenge came when we could not upload these data 
since there is no specific tag to use for amenities or AoIs affected 
by floods, the only tag that we could find is flood_prone=yes 
but this is 
mostly applicable to “roads/ways" that go underwater after heavy rains.


 1. Is there any other tag that can be used for points under flooding
threat or can we use another tag?
 2. Our initial thought was to create a new tag i.e. asset:risk=yes
and asset:risk=noor we could overcome this challenge by having one
tag that is used by the entire OSM community to identify ways,
areas, or pointsthat are prone to floods

Kind regards,
*Immaculata Mwanja*

___
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] leisure=garden for private front/back gardens

[Alessandro Sarretta]

On 13/07/19 20:44, Florian Lohoff wrote:

The same reason i do not map my kitchen sink as a
natural=water/water=pond

Its not for the public leisure.


I don't know if the issue here is public leisure (in this case it's 
maybe better to change the key "leisure" with something else), but I see 
some many pros in having private garden represented and tagged, e.g. 
being able to map the quantity of green areas in a city (for climate 
change, CO2 emission models, urban heat, ...) and differentiate public 
and private green areas contribution.


Ale


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

Re: [Tagging] How to tag sidewalk slides

[Alessandro Sarretta]

Thanks Nick,

On 17/05/19 01:47, Nick Bolten wrote:
The amount of time someone spent at an incline is important for some 
pedestrians, so I'd use an option that splits the way and sets the 
incline tag.


sidewalk=slide might be related to a tag I've wanted for a while. I 
think I would personally call that a ramp, so maybe a use of a tag 
like ramp=yes would be worth discussing.


There's two big benefits I can name right away:

- It becomes easier to incrementally map l to armchair map these 
features. User A tags ramp=yes on a footways (armchair mappable), User 
B can then use a QA tool and add incline=up/down (armchair mappable), 
user C can add incline=a number (must map on-site).


- It becomes possible to distinguish infrastructure built as a ramp 
(like this slide or a wheelchair ramp) from any other segment of 
footway that just happens to be steep.


Does ramp=yes seem like an appropriate (hypothetical) tag for this 
situation?


I've assumed that ramp should be used only with some steps, but actually 
the definition in the wiki 
(https://wiki.openstreetmap.org/wiki/Key:ramp) it's wider: " It's 
*usually* used on staircases".


To me it seems quite a useful option.

But would it be ok to use it on a node instead of a way segment?

Thanks,

Ale



On Thu, May 16, 2019, 4:02 PM Alessandro Sarretta 
mailto:alessandro.sarre...@gmail.com>> 
wrote:


Hi everybody,

I'm mapping various sidewalks and I'd like to tag the portion of
the sidewalk that slides down from a higher level to the ground,
and then maybe goes up again. This happens usually in
correspondance with driveway entrances (how do you tag them?). You
can see an example here

https://wiki.openstreetmap.org/w/images/thumb/b/b9/Sidewalk_and_zebra-crossing.jpg/240px-Sidewalk_and_zebra-crossing.jpg

For wheelchair accessibility it would be important to characterize
it with an incline tag: when the incline value its e.g. >5% the
accessibility can be considered limited, and so on.

One of course could split the sidewalk for a 1 m section and
assing a specific incline value to it; this might lead to a very
fragmented way and sometimes it would be easier to simply add a
node and assign an incline value to it. Even the simple
information that there's a portion of the sidewalk not horizontal
(without a specific value) can be useful.

I've thought about using a node on a footway=sidewalk with
/sidewalk=slide/ + /incline= /or something similar.

I thought also about using the tag kerb, but in this case it isn't
a real intersection with the road, so it doesn't seem to be
appropriate to me.

Do you have any experience on that or suggestions?

Thank you in advance,

Ale


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


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

Re: [Tagging] How to tag sidewalk slides

[Alessandro Sarretta]

Hi Clifford,

On 17/05/19 01:37, Clifford Snow wrote:
I've run into a bunch of similar issues, where they just use asphalt 
to make an incline to the street level. I've been tagging them as 
kerb=lowered. It probably isn't exactly correct, but it does tell a 
wheelchair users that they can reach the street level. (Assuming the 
incline isn't too steep of course.)
from what I've understood form the wiki, /kerb/ is more related to the 
intersection and, /per se/, it doesn't necessarily have an incline, but 
it can have a null (flush), minor (lowered) or high (raised) step. If we 
map an inclined segment as a way (and not as a node), the kerb should be 
assigned to one of its nodes, shouldn't it?
From the image I couldn't tell what the inclined leads to. Is it just 
a wide shoulder or to another sidewalk? That may make a difference in 
how I'd map it.


When the incliined segment leads to a crossing I'm ok with using 
kerb=lowered. I usually have problems when there are two consecutive 
short ramps along a sidewalk.


Ale

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

[Tagging] How to tag sidewalk slides

[Alessandro Sarretta]

Hi everybody,

I'm mapping various sidewalks and I'd like to tag the portion of the 
sidewalk that slides down from a higher level to the ground, and then 
maybe goes up again. This happens usually in correspondance with 
driveway entrances (how do you tag them?). You can see an example here 
https://wiki.openstreetmap.org/w/images/thumb/b/b9/Sidewalk_and_zebra-crossing.jpg/240px-Sidewalk_and_zebra-crossing.jpg


For wheelchair accessibility it would be important to characterize it 
with an incline tag: when the incline value its e.g. >5% the 
accessibility can be considered limited, and so on.


One of course could split the sidewalk for a 1 m section and assing a 
specific incline value to it; this might lead to a very fragmented way 
and sometimes it would be easier to simply add a node and assign an 
incline value to it. Even the simple information that there's a portion 
of the sidewalk not horizontal (without a specific value) can be useful.


I've thought about using a node on a footway=sidewalk with 
/sidewalk=slide/ + /incline= /or something similar.


I thought also about using the tag kerb, but in this case it isn't a 
real intersection with the road, so it doesn't seem to be appropriate to me.


Do you have any experience on that or suggestions?

Thank you in advance,

Ale


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

Re: [Tagging] Handicap Parking Access Aisles

[Alessandro Sarretta]

Hi,

from what I understood, "access aisle" is an official term only in the 
US, as described in the ADA standards 
(https://www.access-board.gov/guidelines-and-standards/buildings-and-sites/about-the-ada-standards/guide-to-the-ada-standards/chapter-5-parking), 
but it describes clearly (as least for a non native English speaker like 
me) what is it.


For mapping accessibility paths for disabled persons, I think it is 
quite important to have this information, so that its presence and 
accessibility from e.g. the sidewalk, is well represented (with e.g. 
tags describing kerbs). This picture [0] to me describes well the reason 
this can be really useful.


To only have amenity=parking_space mapped wouldn't help in describing 
and understanding the accessibility of the parking place from the 
footpaths/sidewalks.


I'm not sure about the use of the egress areas, that seem to be less 
related to access paths for disabled persons, and more related to areas 
not usable by other cars...


Ale

[0] 
https://www.access-board.gov/images/guidelines_standards/Buildings_Sites/guides/chapter5/5p15a.JPG


On 02/05/19 12:36, Tony Shield wrote:


Hi

[AA] is a Mapillary picture of a typical UK disabled parking bay, the 
hatched area is a what I think you are calling an 'access aisle'.  
Those particular disabled parking bays are legally designated and 
enforced.


I see that tags amenity 
<https://wiki.openstreetmap.org/wiki/Key:amenity>=parking_space and 
parking_space 
<https://wiki.openstreetmap.org/w/index.php?title=Key:parking_space&action=edit&redlink=1>=disabled 
<https://wiki.openstreetmap.org/w/index.php?title=Tag:parking_space%3Ddisabled&action=edit&redlink=1> 



are not described in the wiki but to my mind an entry for 
parking_space = disabled should meet the local space and marking 
scheme so in the UK a parking_space=disabled would without further 
definition include an egress space. If there is a wish to specifically 
mark those hatched areas then I suggest the use of the word 'egress' .


[AA] https://www.mapillary.com/map/im/5PAU747rlUdNrCaDtUNDuA

Regards

TonyS999

On 02/05/2019 10:54, Volker Schmidt wrote:
I would consider what is here described as access aisle (according to 
the photo [1]) part of the parking space. Here in Italy any parking 
space for the disabled has a dedicated "access aisle" similar to the 
photo.
If you want to achieve disabled (wheelchair) routing I would assume 
it to be sufficient to map the disabled parking spaces within the car 
park.


[1] https://mycloud.snowandsnow.us/index.php/s/F2mAATCQ54SzfcT

On Thu, 2 May 2019 at 11:31, Tony Shield <mailto:tony.shield...@gmail.com>> wrote:


Having today downloaded and read SN01360 [2] |I disagree with the
interpretation. In that document there is only one mention of
'aisle' it being an 'access aisle' in Section 5.4 paragraph
marked Off-Street Parking  -" *Off-street parking*: bays should
be a minimum of 4800 mm long
by 2400 mm wide with additional space: (1) where bays are
parallel to the access aisle and access is available from the side an
extra length of at least 180 0mm, or (2) where bays are
perpendicular to the access aisle, an additional width of at least
1200 mm along each side.

I read that as saying the 'access aisle' is that which in OSM is
marked as 'parking _aisle', and it leads to a parking bay
designated for disabled users, the 'access aisle' is not
exclusively for the use of disabled users. I am of the opinion
that 'access' is misinterpreted to refer only to disabled users
which is a very restrictive interpretation of the usual
interpretation of access being for anybody. I think it is
something to be very careful about.
Usage in the UK supports my interpretation - I know of many car
parks where ordinary and disabled spaces are next to each other
and accessed by a single way which has no restrictions.

For parking bays I think that the tag:amenity=parking _space is
clear.

Regards
TonyS999

On 02/05/2019 08:21, Alessandro Sarretta wrote:


Hi Clifford,

On 02/05/19 00:13, Clifford Snow wrote:

Since the off loading area is called an access aisle, both in
the US and UK [2], it seem to me that it would be an
appropriate term to use.  Would using highway=footway +
footway=access_aisle +  wheelchair=yes be a more acceptable
tagging scheme? My concern is that just adding wheelchair=yes
to a footway doesn't get at the requirement for the width of
the access_aisle.


[1]

https://www.access-board.gov/guidelines-and-standards/buildings-and-sites/about-the-ada-standards/guide-to-the-ada-standards/chapter-5-parking
[2]
https://researchbriefings.files.parliament.uk/documents/SN01360/SN01360.pdf


I'm re

Re: [Tagging] Handicap Parking Access Aisles

[Alessandro Sarretta]

Hi Clifford,

On 02/05/19 00:13, Clifford Snow wrote:
Since the off loading area is called an access aisle, both in the US 
and UK [2], it seem to me that it would be an appropriate term to 
use.  Would using highway=footway + footway=access_aisle + 
 wheelchair=yes be a more acceptable tagging scheme? My concern is 
that just adding wheelchair=yes to a footway doesn't get at the 
requirement for the width of the access_aisle.



[1] 
https://www.access-board.gov/guidelines-and-standards/buildings-and-sites/about-the-ada-standards/guide-to-the-ada-standards/chapter-5-parking
[2] 
https://researchbriefings.files.parliament.uk/documents/SN01360/SN01360.pdf


I'm really supporting your proposal for a highway=footway + 
footway=access_aisle.


I would match this with a wheelchair=designated instead of a 
wheelchair=yes, as suggested by Mateusz Konieczny.


Best,

Ale

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

Re: [Tagging] Possibility to draw parking properties as an area

[Alessandro Sarretta]

Hi Paul,

On 09/03/19 17:18, Paul Allen wrote:
On Sat, 9 Mar 2019 at 16:02, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:



On 9. Mar 2019, at 14:03, Paul Allen mailto:pla16...@gmail.com>> wrote:

are we going to connect all roadside parking to the center of the
road ,thereby misrepresenting the extent significantly, because in
some hypothetical rare case there might be a parking between roads
which isn’t accessible from both roads?
Typically there will be access roads for parkings unless they are
not wider than a parking lot. Here’s an example around here for
parking between 2 roads with access from only one side, no issues
encountered so far:

https://www.openstreetmap.org/way/490431306


Until you gave that example, I thought you made some fair points.  Now 
I do not think so.


I couldn't make sense of what was going on.  I couldn't tell how to 
access those parking
spaces or how they connected to the road network.  I had to switch to 
the editor before
any of it made sense to me, and then what I saw from reality didn't 
match up with what

the rendering showed me.

The result of doing it your way is FAR worse than I thought it would 
be.  You're nit-picking
about minor problems that might be faced by autonomous vehicles 
parking slightly in the
road and giving the major problem that many spaces accessible directly 
from the north
carriage of Circonvallazione Ostiense appear to be only indirectly 
accessible from the
south carriage of Circonvallazione Ostiense via a twisted route of 
parking aisles.


From what I see on the map you're totally misunderstanding the reality...

Those parking places in the middle of the two roads are NOT accessible 
from north, but only from south, and the map representation is saying 
so, with the only parking aisle coming from south...


Ale


--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com <http://ilsarrett.wordpress.com>

Research information:

 * Google scholar profile
   <http://scholar.google.it/citations?user=IsyXargJ&hl=it>
 * ORCID <http://orcid.org/-0002-1475-8686>
 * Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta>
 * Impactstory <https://impactstory.org/AlessandroSarretta>

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

Re: [Tagging] leisure=common replacement for public areas with some trees

[Alessandro Sarretta]

On 05/03/19 09:50, Marián Kyral wrote:


-- Původní e-mail --
Od: Marián Kyral 
Komu: tagging@openstreetmap.org
Datum: 5. 3. 2019 9:02:03
Předmět: [Tagging] leisure=common replacement for public areas with 
some trees



What about e.g.: landuse=public_green? It could be also extended
by tags like trees=yes, scrub=yes or public_green=grass /
public_green=flowers.


One more thing: Should we use landuse there? As these areas are 
usually inside of landuse=residental? Maybe use leisure=public_green 
instead?


I would suggest to use landcover=grass 
<https://wiki.openstreetmap.org/wiki/Tag:landcover%3Dgrass> and maybe 
access=yes


m2c

Ale

--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com <http://ilsarrett.wordpress.com>

Research information:

 * Google scholar profile
   <http://scholar.google.it/citations?user=IsyXargJ&hl=it>
 * ORCID <http://orcid.org/-0002-1475-8686>
 * Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta>
 * Impactstory <https://impactstory.org/AlessandroSarretta>

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