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] free_standing_emergency_department, amenity or clinic ?

[Mateusz Konieczny]

2 May 2019, 04:37 by cosmic...@gmail.com:

> My view is that we should focus on getting the schema, keys and
> attributes correct, and worry less about the rendering.
>
I would strongly advocate not worrying about rendering too much.
In general tags require some use before rendering is going to appear.

(though one should be careful with creating duplicates of already
adopted tags and do it only where it is really, really a good idea)

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

Re: [Tagging] Handicap Parking Access Aisles

[Tony Shield]

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 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Tobias Wrede]

Am 30.04.2019 um 21:05 schrieb Kevin Kenny:

On Tue, Apr 30, 2019 at 2:19 PM s8evq  wrote:

Personally, I like signed_direction=yes. It's simple and avoids using the word 
oneway.
Also, using the value forward|backward might not be necessary, as it's possible 
to deduce this from the order of ways in the relation.

The forward/backward direction cannot be deduced from the order of the
ways if the relation contains fewer than three ways.



Do you suggest to stick with (counter)clockwise then?

Is there really a use case? How many circular routes are made up of only 
one or two ways? I suppose one could add the information to the ways 
then in that special case.


The counter(clockwise) designation doesn't work well in cases of 
touching or crossing ways (figure 8 shaped trails for example) or when 
alternative routes are included in the relation.


Tobias


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

Re: [Tagging] Status of oneway=cw oneway=ccw

[Tobias Wrede]

Am 30.04.2019 um 20:18 schrieb s8evq:

- bidirectional=no
- signed_oneway=yes
- signed_direction=yes
- designated_direction=forward|both|backward
- signed=forward|backward|both|none

Personally, I like signed_direction=yes. It's simple and avoids using the word 
oneway.
Also, using the value forward|backward might not be necessary, as it's possible 
to deduce this from the order of ways in the relation.

signed_direction=yes is not intuitive in my opinion. Mappers might apply 
it ("yes, there is a signed direction") but might forget to put the 
members in the right order. Having a forward|backward|both|none in there 
might make it more obvious to take care to apply the tag correctly.


Tobias


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

Re: [Tagging] Status of oneway=cw oneway=ccw

[Paul Allen]

On Thu, 2 May 2019 at 10:33, Tobias Wrede  wrote:

> The counter(clockwise) designation doesn't work well in cases of
> touching or crossing ways (figure 8 shaped trails for example)


A figure-eight trail could be mapped as two touching circular trails.  But
there are probably
disadvantages to doing it that way.

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

Re: [Tagging] Handicap Parking Access Aisles

[Volker Schmidt]

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  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 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 
> listTagging@openstreetmap.orghttps://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] Status of oneway=cw oneway=ccw

[Hufkratzer]

On 30.04.2019 21:05, Kevin Kenny wrote:

On Tue, Apr 30, 2019 at 2:19 PM s8evq  wrote:

Personally, I like signed_direction=yes. It's simple and avoids using the word 
oneway.
Also, using the value forward|backward might not be necessary, as it's possible 
to deduce this from the order of ways in the relation.

The forward/backward direction cannot be deduced from the order of the
ways if the relation contains fewer than three ways.


For a non-roundtrip route consiting of two consecutive ways the route 
direction can be deduced from the order of the ways in the relation.



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

Re: [Tagging] Status of oneway=cw oneway=ccw

[Paul Allen]

On Thu, 2 May 2019 at 11:13, Hufkratzer  wrote:

>
> For a non-roundtrip route consiting of two consecutive ways the route
> direction can be deduced from the order of the ways in the relation.
>

Note that (last time I tried) not all popular editors preserve the order of
ways in relations.

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

Re: [Tagging] Status of oneway=cw oneway=ccw

[Hufkratzer]

On 02.05.2019 12:20, Paul Allen wrote:
On Thu, 2 May 2019 at 11:13, Hufkratzer > wrote:



For a non-roundtrip route consiting of two consecutive ways the route
direction can be deduced from the order of the ways in the relation.


Note that (last time I tried) not all popular editors preserve the 
order of ways in relations.


--
Paul


Really? Which one does not? This would be bug that needs to be fixed!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Handicap Parking Access Aisles

[Tony Shield]

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 
=parking_space and 
parking_space 
=disabled 
 



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 > 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 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

___
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] free_standing_emergency_department, amenity or clinic ?

[Nita Rae Sanders]

On 5/1/19, Nita Rae Sanders  wrote:
> On 5/1/19, Graeme Fitzpatrick  wrote:
>>> On 5/1/2019 7:47 AM, Nita Rae Sanders wrote:
>>> > Have we reached the conclusion that a new tagging value is needed ?
>>>
>>
>> Getting there!
>>
>>
>>> > If so, what is the schema for the new value ?
>>>
>>
>> Still being discussed
>>
>>
>>> > Can we move on to a vote ?
>>>
>>
>> Not yet!
>>
>> On Thu, 2 May 2019 at 01:41, Jmapb  wrote:
>>
>>> Personally I'm okay with continuing to use
>>> healthcare=centre+healthcare:speciality=emergency.
>>>
>>> I'm warm to the idea of a healthcare=department tag, but I don't know if
>>> it fully expresses the importance of a standalone emergency department.
>>>
>>
>> I did suggest healthcare=emergency the other day.
>>
>> Was thinking about swapping it around to emergency=medical or something
>> similar, but then just saw emergency=emergency_ward_entrance
>> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Demergency_ward_entrance
>> ,
>> which has been used 600 times.
>>
>> How about changing that to either just =emergency_ward or
>> =emergency_department?
>>
>> Unfortunately, it apparently only currently renders as a normal entrance,
>> without the medical colour scheme. As I also mentioned that could be
>> rendered as A-E using the hospital white on red colours.
>>
>> To muddle things further, there's a possibility that healthcare=* POIs
>>> will stop rendering in the default style,
>>
>>
>> That will be somewhat annoying :-(
>>
>>  Thanks
>>
>> Graeme
>>
>  My view is that we should focus on getting the schema, keys and
> attributes correct, and worry less about the rendering. If the
> rendering is not doing the desired thing, then we open a ticket about
> that issue, and let the rendering folks deal with it. Right now, I am
> more concerned with getting some form of consensus about what the
> correct tag=value should be, such that anyone down the road can
> quickly understand the meaning of same.
>
> The facilities in question are both a remote appendage to a large
> hospital, and a stand alone destination in their own right. The
> article I linked up thread makes it clear that a few of these
> facilities exist without the major hospital connection, but they are a
> very small minority. In Florida, I do not believe they exist at all
> (due to state licensing requirements).
>
Based on my reading of TagInfo, the pairing of
healthcare=emergency_department is not used at all.

I am tacitly suggesting that these facilities be tagged as
healthcare=emergency_department, hospital=no, with an optional (and
likely present) operator=*, plus the usual addressing information.

amenity shall not be used.

That would both convey that they are an emergency department, that
they are not a full hospital, and who they are associated with.

Comments ?

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

Re: [Tagging] Status of oneway=cw oneway=ccw

[Paul Allen]

On Thu, 2 May 2019 at 11:26, Hufkratzer  wrote:

>
> Really? Which one does not?
>

i Dunno.  But if I need to edit a relation I use JOSM (that and splitting
woods so I can name the
two sections differently) Is about all I use it for.

This would be bug that needs to be fixed!
>

It's not a bug, it's a feature.  Well, it's an acknowledged problem.  Or
was.  I haven't tried it in a
while, because unscrambling a large relation is not my iDea of fun.

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

Re: [Tagging] Feature Proposal - Voting - Key:golf_cart

[Joseph Eisenberg]

Voting has been open for about a week for the key "golf_cart", which
is already being used to define access for golf carts on highways and
paths.

Please remember to read the proposal and then add your vote or comments:
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:golf_cart#Voting

On 4/26/19, Joseph Eisenberg  wrote:
> It has been over 2 weeks since the RFC for
> https://wiki.openstreetmap.org/wiki/Proposed_features/Key:golf_cart
>
> This key is already in use over 16,000 times to define access
> restrictions for golf carts on highway ways (especially highway=path
> and highway=service), highway=crossing and amenity=parking.
>
> Voting will clarify that using a highway tag, such as highway=path or
> highway=service with golf_cart=designated is the preferred way to tag
> a golf cart path on a golf course.
>
> Please see the discussion page. There were no major issues, and the
> minor questions and suggestions have been addressed
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Key:golf_cart
>
> Then log in and scroll to the bottom to vote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Key:golf_cart#Voting
>
> Voting will be open till 11 May 2019
>
> - Joseph E.
>

___
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 
=parking_space and 
parking_space 
=disabled 
 



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 > 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 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 

Re: [Tagging] Status of oneway=cw oneway=ccw

[s8evq]

Reading the replies, it seems the open question is whether we should solely 
rely on the order of ways in a relation, or on a key value to deduce/specify 
the direction in which the signposts are visible. I'm open for either solution. 

My question is: If you we use "forward|backward|both" as the value in for 
example designated_direction=*", to what does forward relate? How do you know 
what forward is?

On Thu, 2 May 2019 11:35:38 +0200, Tobias Wrede  wrote:

> Am 30.04.2019 um 20:18 schrieb s8evq:
> > - bidirectional=no
> > - signed_oneway=yes
> > - signed_direction=yes
> > - designated_direction=forward|both|backward
> > - signed=forward|backward|both|none
> >
> > Personally, I like signed_direction=yes. It's simple and avoids using the 
> > word oneway.
> > Also, using the value forward|backward might not be necessary, as it's 
> > possible to deduce this from the order of ways in the relation.
> >
> signed_direction=yes is not intuitive in my opinion. Mappers might apply 
> it ("yes, there is a signed direction") but might forget to put the 
> members in the right order. Having a forward|backward|both|none in there 
> might make it more obvious to take care to apply the tag correctly.
> 
> Tobias
> 
> 
> ___
> 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] Handicap Parking Access Aisles

[Tony Shield]

Hi

It does appear that 'access aisle' is US and from watching the video and 
your picture it is an integral part of a parking_bay or parking_lane for 
disabled access. It follows that a parking bay or parking lane tagged 
for disabled then it must follow the regulations of that country. For 
very detailed mapping of such a bay or lane then making it clear that 
the hatched area is for disabled users as part of the adjoining parking 
bay is good, but please do not use words with a very wide meaning, 
please find a way of limiting the meaning to disabled people - 
disabled_access_area is good for me.


Regards

T

On 02/05/2019 13:24, Alessandro Sarretta wrote:


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 
=parking_space and 
parking_space 
=disabled 
 



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

Re: [Tagging] free_standing_emergency_department, amenity or clinic ?

[Jmapb]

On 5/2/2019 6:47 AM, Nita Rae Sanders wrote:


I am tacitly suggesting that these facilities be tagged as
healthcare=emergency_department, hospital=no, with an optional (and
likely present) operator=*, plus the usual addressing information.

amenity shall not be used.

That would both convey that they are an emergency department, that
they are not a full hospital, and who they are associated with.

Comments ?


Thanks for your efforts on this! Comments --

* healthcare=emergency_department is simple and relatively unambiguous.
However, because I've been contemplating a healthcare=department tag, I
fear this could trigger a trend of healthcare=*_department tags instead
(=radiology_department, =surgery_department, etc) which seems a little
backward given the current trend towards using namespace prefixes for
details of this level.

...that said, as mentioned earlier, I'm not really convinced that
healthcare=department + healthcare:speciality=emergency captures the
true importance of these standalone facilities. So I'm not arguing for
that either. (ie, I know we're supposed to ignore rendering, but *if*
healthcare=department were ever to render on the default map I'd expect
it would just be a red dot like healthcare=yes. I'd want the standalone
ER to at least have the same prominence as healthcare=centre.)

I don't have an alternate suggestion at the moment, so I'm open to
healthcare=emergency_department if nothing better arises.

* hospital=no strikes me as unnecessary -- and even potentially
confusing. Because this is not the usual way of indicating whether a
feature is a hospital, I can easily imagine a mapper thinking it means
"is this a hospital-run facility?" rather than "is this itself hospital?"

* regarding amenity, I actually think you might want to consider adding
the amenity=doctors tag, at least transitionally. It's not strictly
wrong, it's well within the traditional use of the tag (which, in the
pre-healthcare=* era, has been basically "anything smaller than a
hospital") and it will render. (Yes, I'm suggesting tagging for the
renderer!! Get the tar and feathers! But it's not *incorrect* tagging,
and I feel that showing map users the nearest emergency room,
potentially saving lives, is worth the small ideological compromise.)

All that aside, tag them in a way that makes sense to you, with the
understanding that you or someone else may retag them when consensus is
reached on this issue. And the usual caveats of "don't expect it to
render until it becomes widely used" except doubly so with the uncertain
schedule of support of healthcare=* tags.

 J


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

Re: [Tagging] Handicap Parking Access Aisles

[Clifford Snow]

On Thu, May 2, 2019 at 7:54 AM Tony Shield  wrote:

> Hi
>
> It does appear that 'access aisle' is US and from watching the video and
> your picture it is an integral part of a parking_bay or parking_lane for
> disabled access. It follows that a parking bay or parking lane tagged for
> disabled then it must follow the regulations of that country. For very
> detailed mapping of such a bay or lane then making it clear that the
> hatched area is for disabled users as part of the adjoining parking bay is
> good, but please do not use words with a very wide meaning, please find a
> way of limiting the meaning to disabled people - disabled_access_area is
> good for me.
>
Tony you seem to have summarized what I've read in other posts, that
access_aisle is too generic which would lead to people adding it to
features that have nothing to do with wheelchair access. Once that happens,
the tag will have lost its meaning.

Since the area is intended for wheelchair access to vehicles, does
highway=footway + footway=wheelchair_loading_aisle work better? It does
away with needing to add a third tag, wheelchair=designated, and would work
even if someone added wheelchair=designated.

Best,
Clifford

-- 
@osm_washington
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] free_standing_emergency_department, amenity or clinic ?

[Jmapb]

On 5/2/2019 11:53 AM, Jmapb wrote:

* regarding amenity, I actually think you might want to consider adding
the amenity=doctors tag, at least transitionally. It's not strictly
wrong, it's well within the traditional use of the tag (which, in the
pre-healthcare=* era, has been basically "anything smaller than a
hospital")

I'd forgotten about amenity=clinic, which, while also not 100% accurate,
might be a better fit for a auxiliary transitional amenity tag than
amenity=doctors... if you decide to go this route. I see that this tag
also came up as a suggestion in the help forum. J

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

[Tagging] Whispering asphalt

[amilopowers]

Hello

I used to live in Fribourg, Switzerland where they put "whispering asphalt" on 
one of the main roads in order to prevent noise. You can barely hear an EV now, 
but that is another story.

Since we have quite a lot of discussions about noise pollution I thought it 
might be a good idea to implement a tag for that.

surface=whispering_asphalt or surface=silent_asphalt came to my mind but I 
don't know what the official term for that aspahlt in English is. In German we 
call it "Flüsterbelag" or "Flüsterasphalt".

Then I found on Overpass-Turbo someone that tagged "asphalt:type=porous". [1] 
Since I don't work in that area I don't know for sure if this is the same thing 
as I imagine and I found only one Wikipedia article in German [2] about that 
asphalt I mean.

I personally prefer one of my first ideas, since I hate to add another 
key/value if I can say it in one.

I look forward to hear your thoughts and comments.

Regards
Ueli (amilopowers)

[1] https://overpass-turbo.eu/s/Iky (click "run")
[2] https://de.wikipedia.org/wiki/Asphalt#Offenporiger_Asphalt


Sent from ProtonMail, encrypted email based in Switzerland.

signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Whispering asphalt

[Tod Fitch]

I have not heard of “whispering asphalt” but I know that in some areas of the 
state I live in they have been using a porous asphalt on roads to provide 
better traction during rain storms.

So I am not sure if the current uses of “asphalt:type=porous” would be to 
indicate pavement designed for good traction in the rain or if it was for 
making a less noisy road.

From taginfo, it looks like asphalt:type has only been used a few times and 
always with the value of porous. And it looks like they are all in the one area 
you found with your overpass query. Perhaps the original mapper could be 
contacted to see what they were trying to describe.

Cheers!
Tod

> On May 2, 2019, at 12:55 PM, amilopow...@u-cloud.ch wrote:
> 
> Signed PGP part
> Hello
> 
> I used to live in Fribourg, Switzerland where they put "whispering asphalt" 
> on one of the main roads in order to prevent noise. You can barely hear an EV 
> now, but that is another story.
> 
> Since we have quite a lot of discussions about noise pollution I thought it 
> might be a good idea to implement a tag for that.
> 
> surface=whispering_asphalt or surface=silent_asphalt came to my mind but I 
> don't know what the official term for that aspahlt in English is. In German 
> we call it "Flüsterbelag" or "Flüsterasphalt".
> 
> Then I found on Overpass-Turbo someone that tagged "asphalt:type=porous". [1] 
> Since I don't work in that area I don't know for sure if this is the same 
> thing as I imagine and I found only one Wikipedia article in German [2] about 
> that asphalt I mean.
> 
> I personally prefer one of my first ideas, since I hate to add another 
> key/value if I can say it in one.
> 
> I look forward to hear your thoughts and comments.
> 
> Regards
> Ueli (amilopowers)
> 
> 
> [1] https://overpass-turbo.eu/s/Iky  (click 
> "run")
> [2] https://de.wikipedia.org/wiki/Asphalt#Offenporiger_Asphalt 
> 
> 
> 
> Sent from ProtonMail , encrypted email based in 
> Switzerland.
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] free_standing_emergency_department, amenity or clinic ?

[Nita Rae Sanders]

On 5/2/19, Jmapb  wrote:
> On 5/2/2019 6:47 AM, Nita Rae Sanders wrote:
>
>> I am tacitly suggesting that these facilities be tagged as
>> healthcare=emergency_department, hospital=no, with an optional (and
>> likely present) operator=*, plus the usual addressing information.
>>
>> amenity shall not be used.
>>
>> That would both convey that they are an emergency department, that
>> they are not a full hospital, and who they are associated with.
>>
>> Comments ?
>
> Thanks for your efforts on this! Comments --
>
> * healthcare=emergency_department is simple and relatively unambiguous.
> However, because I've been contemplating a healthcare=department tag, I
> fear this could trigger a trend of healthcare=*_department tags instead
> (=radiology_department, =surgery_department, etc) which seems a little
> backward given the current trend towards using namespace prefixes for
> details of this level.

The term 'Emergency Department' is unique in it's use of department.
ED is a modern replacement for the term ER. Wikipedia has a page for
Emergency Department, but not for Surgery Department. Searching for
Radiology Department redirects to Radiology, so I think the comparison
is not quite apt.

> ...that said, as mentioned earlier, I'm not really convinced that
> healthcare=department + healthcare:speciality=emergency captures the
> true importance of these standalone facilities. So I'm not arguing for
> that either. (ie, I know we're supposed to ignore rendering, but *if*
> healthcare=department were ever to render on the default map I'd expect
> it would just be a red dot like healthcare=yes. I'd want the standalone
> ER to at least have the same prominence as healthcare=centre.)

Yes, see my remarks below.

> I don't have an alternate suggestion at the moment, so I'm open to
> healthcare=emergency_department if nothing better arises.
>
> * hospital=no strikes me as unnecessary -- and even potentially
> confusing. Because this is not the usual way of indicating whether a
> feature is a hospital, I can easily imagine a mapper thinking it means
> "is this a hospital-run facility?" rather than "is this itself hospital?"

See below.

> * regarding amenity, I actually think you might want to consider adding
> the amenity=doctors tag, at least transitionally. It's not strictly
> wrong, it's well within the traditional use of the tag (which, in the
> pre-healthcare=* era, has been basically "anything smaller than a
> hospital") and it will render. (Yes, I'm suggesting tagging for the
> renderer!! Get the tar and feathers! But it's not *incorrect* tagging,
> and I feel that showing map users the nearest emergency room,
> potentially saving lives, is worth the small ideological compromise.)

Absolutely, which is why I went with hospital=no, because the
canonical definition of an ED is valid both for free-standing and for
embedded within a hospital. I am envisioning something where all ED's
will be designated as such, even those embedded within the hospital.
It is an attempt to provide a common tagging system, exactly for the
purpose you point out … saving lives. I am open to other schemes to
distinguish between free_standing and embedded, something which allows
for an ED to be tagged as an ED. To be even more succinct, Shand's (in
Gainesville) has an embedded ED, and embedded ED for pediatrics, and
two free_standing ED units.

> All that aside, tag them in a way that makes sense to you, with the
> understanding that you or someone else may retag them when consensus is
> reached on this issue. And the usual caveats of "don't expect it to
> render until it becomes widely used" except doubly so with the uncertain
> schedule of support of healthcare=* tags.
>
>   J
>
>
> ___
> 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] Whispering asphalt

[Paul Allen]

On Thu, 2 May 2019 at 20:57,  wrote:

>
> I used to live in Fribourg, Switzerland where they put "whispering
> asphalt" on one of the main roads in order to prevent noise. You can barely
> hear an EV now, but that is another story.
>
> Since we have quite a lot of discussions about noise pollution I thought
> it might be a good idea to implement a tag for that.
>
> surface=whispering_asphalt or surface=silent_asphalt came to my mind but I
> don't know what the official term for that aspahlt in English is. In German
> we call it "Flüsterbelag" or "Flüsterasphalt".
>

> Then I found on Overpass-Turbo someone that tagged "asphalt:type=porous".
> [1] Since I don't work in that area I don't know for sure if this is the
> same thing as I imagine and I found only one Wikipedia article in German
> [2] about that asphalt I mean.
>

I'd not heard of this stuff (no pun intended) so I did some googling.  As
Tod responded, those of
us who aren't obsessed by asphalt would assume that porous asphalt was
intended for
drainage.  And porous asphalt is indeed used to improve drainage.  But it
can also be used for noise
reduction.  From http://asphaltmagazine.com/turning-the-volume-down/
it seems that the US term for porous asphalt used for noise reduction is
"quiet asphalt."  In the
UK the generic term for low noise surfaces is "low noise surfaces."

I wouldn't use porous_asphalt for several reasons:

1) It might be porous for drainage and have little or no effect on noise.

2) It might be something other than asphalt.

3) It might be asphalt but with grooves rather than being porous (there's
more than one way
to reduce the noise).

I wouldn't use "silent" or "quiet" in the tag despite the US calling it
"quiet asphalt" because it's
quietER not quiet.  So "noise reducing" or something along those lines.

Given that many types of surface might have low noise, we probably need to
keep it independent
of the surface material, otherwise we'll end up with noise_reducing_asphalt,
noise_reducing_concrete, etc.

So, an idea to be taken behind the bikesheds and kicked to death...
surface:noise_reducing=yes.
I'll take the first kick - what do we do when noise_reducing becomes the
norm and then
somebody invents extra_noise_reducing.  And the second kick - how often are
we going to
be able to choose between two routes, one of which is noise-reducing and
one isn't, will
routers support it and will anybody ever want to choose low noise over
shortest route or
fastest route?  Third kick - it may be important to those living nearby,
but they won't need a map
to know if the road is noisy or not.

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

Re: [Tagging] Whispering asphalt

[Florian Lohoff]

On Thu, May 02, 2019 at 07:55:40PM +, amilopow...@u-cloud.ch wrote:
> Hello
> 
> I used to live in Fribourg, Switzerland where they put "whispering
> asphalt" on one of the main roads in order to prevent noise. You can
> barely hear an EV now, but that is another story.
> 
> Since we have quite a lot of discussions about noise pollution I
> thought it might be a good idea to implement a tag for that.
> 
> surface=whispering_asphalt or surface=silent_asphalt came to my mind
> but I don't know what the official term for that aspahlt in English
> is. In German we call it "Flüsterbelag" or "Flüsterasphalt".
> 
> Then I found on Overpass-Turbo someone that tagged
> "asphalt:type=porous". [1] Since I don't work in that area I don't
> know for sure if this is the same thing as I imagine and I found only
> one Wikipedia article in German [2] about that asphalt I mean.
> 
> I personally prefer one of my first ideas, since I hate to add another
> key/value if I can say it in one.
> 
> I look forward to hear your thoughts and comments.

The point is that when you invent a new value for surface a lot of
consumers will assume it to be some kind of bad/worse surface and
reduce the average speed to expect.

I'd rather propose surface=asphalt asphalt=whisper or the like.

asphalt:type would also be okay with me. There are more likely 100s of types
of asphalt.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Whispering asphalt

[Yuri Astrakhan]

I don't think we should do asphalt classification -- too difficult for many
cases, and very little value, especially in this case because it is not the
"type" of asphalt, it is rather a "feature" of asphalt. Multiple features
could exist in the same asphalt - e.g. it could have noise-canceling
qualities, or it could have under-surface charging, or it could have solar
panels integrated into it, or it could have high melting point so it works
well under sun.

In other words, I think it should be a yes flag, something like
noise_reducing_surface=yes

On Thu, May 2, 2019 at 5:12 PM Florian Lohoff  wrote:

> On Thu, May 02, 2019 at 07:55:40PM +, amilopow...@u-cloud.ch wrote:
> > Hello
> >
> > I used to live in Fribourg, Switzerland where they put "whispering
> > asphalt" on one of the main roads in order to prevent noise. You can
> > barely hear an EV now, but that is another story.
> >
> > Since we have quite a lot of discussions about noise pollution I
> > thought it might be a good idea to implement a tag for that.
> >
> > surface=whispering_asphalt or surface=silent_asphalt came to my mind
> > but I don't know what the official term for that aspahlt in English
> > is. In German we call it "Flüsterbelag" or "Flüsterasphalt".
> >
> > Then I found on Overpass-Turbo someone that tagged
> > "asphalt:type=porous". [1] Since I don't work in that area I don't
> > know for sure if this is the same thing as I imagine and I found only
> > one Wikipedia article in German [2] about that asphalt I mean.
> >
> > I personally prefer one of my first ideas, since I hate to add another
> > key/value if I can say it in one.
> >
> > I look forward to hear your thoughts and comments.
>
> The point is that when you invent a new value for surface a lot of
> consumers will assume it to be some kind of bad/worse surface and
> reduce the average speed to expect.
>
> I'd rather propose surface=asphalt asphalt=whisper or the like.
>
> asphalt:type would also be okay with me. There are more likely 100s of
> types
> of asphalt.
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away
> ___
> 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] Whispering asphalt

[Paul Allen]

On Thu, 2 May 2019 at 22:24, Yuri Astrakhan  wrote:

> or it could have solar panels integrated into it
>

Yes, roads with integrated solar panels have been proposed.  Any rational
engineering
analysis comes to the conclusion that this is a very, very stupid idea for
many reasons.
Nevertheless, there have been some trials.  All have done worse than the
analyses.
They have been thoroughly debunked.  The surface isn't durable.  The panels
are
very expensive in labour costs to replace when they break.  They don't give
enough
traction.  A horizontal surface means sub-optimal efficiency, getting worse
the further
you get from the equator.  Traffic on the roads shields the panels from the
sun.

So there are a few trials scattered around the world.  There's little
chance they'll become
widespread without several major technological breakthroughs because it's
far cheaper
and more efficient to put panels over a road than embed them within it.

You raised some good points about surface features (which may not be
limited to just
asphalt) but solar panels is unlikely to be one of them.  And if they're
solar panels that
have embedded leds for smart road-surface signage and embedded heating
elements
for melting snow, they are a complete scam.  So we'll never have to invent
a tag
for "Solar Freakin' Roadways" (that's what they call themselves).

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

Re: [Tagging] Whispering asphalt

[Tobias Wrede]

Am 02.05.2019 um 23:23 schrieb Yuri Astrakhan:
I don't think we should do asphalt classification -- too difficult for 
many cases, and very little value, especially in this case because it 
is not the "type" of asphalt, it is rather a "feature" of asphalt. 
Multiple features could exist in the same asphalt - e.g. it could have 
noise-canceling qualities, or it could have under-surface charging, or 
it could have solar panels integrated into it, or it could have high 
melting point so it works well under sun.


In other words, I think it should be a yes flag, something like  
noise_reducing_surface=yes


I would question to use any qualification at all. Whatever is now called 
a quiet/whispering/noise reducing asphalt will have become a standard in 
a couple of years and then a new type even more noise reducing will have 
been invented. Will we then have 
noise_reducing_surface=no|little|yes|yes_yes|definitely_yes?


If someone cannot resist I would second Yuri's suggestion.

Tobias


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

Re: [Tagging] Whispering asphalt

[Paul Allen]

On Thu, 2 May 2019 at 22:43, Tobias Wrede  wrote:

> I would question to use any qualification at all. Whatever is now called
> a quiet/whispering/noise reducing asphalt will have become a standard in
> a couple of years and then a new type even more noise reducing will have
> been invented. Will we then have
> noise_reducing_surface=no|little|yes|yes_yes|definitely_yes?
>

If we need this tag (I have my doubts) then the only sane way of handling
that would be
something like noise_reduction_db=* where the figure is relative to a
"normal" surface
(e.g., smooth concrete) measured at some specified distance.  I'll leave it
to the
specialists to come up with those conditions.

I really doubt we need it.  People are unlikely to choose a minimum-noise
route even if
their satnav offered the option, not if it means the journey is longer or
slower.  People
living nearby who are actually affected by road noise will know whether
they have a loud
road or a quiet one without our help.  We won't be able to tell if the tag
applies from
satellite imagery.  It will be hard to verify unless a community proudly
puts up signs
announcing they've spent money on such a surface.  OTOH, people tag things
like
this just because they can, so we'll probably have to come up with
something sane here
before people make tags up at random.

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

Re: [Tagging] Whispering asphalt

[Yuri Astrakhan]

Well, one use case would be for property shoppers to find an area with the
quieter asphalt.  But yes, all this is a bit far fetched.

On the other hand, I do not want to restrict people from mapping whatever
interesting information they know, as long as that information is in
standardized-ish format that is easy to consume, and does not break
existing consumers

On Thu, May 2, 2019 at 5:53 PM Paul Allen  wrote:

> On Thu, 2 May 2019 at 22:43, Tobias Wrede  wrote:
>
>> I would question to use any qualification at all. Whatever is now called
>> a quiet/whispering/noise reducing asphalt will have become a standard in
>> a couple of years and then a new type even more noise reducing will have
>> been invented. Will we then have
>> noise_reducing_surface=no|little|yes|yes_yes|definitely_yes?
>>
>
> If we need this tag (I have my doubts) then the only sane way of handling
> that would be
> something like noise_reduction_db=* where the figure is relative to a
> "normal" surface
> (e.g., smooth concrete) measured at some specified distance.  I'll leave
> it to the
> specialists to come up with those conditions.
>
> I really doubt we need it.  People are unlikely to choose a minimum-noise
> route even if
> their satnav offered the option, not if it means the journey is longer or
> slower.  People
> living nearby who are actually affected by road noise will know whether
> they have a loud
> road or a quiet one without our help.  We won't be able to tell if the tag
> applies from
> satellite imagery.  It will be hard to verify unless a community proudly
> puts up signs
> announcing they've spent money on such a surface.  OTOH, people tag things
> like
> this just because they can, so we'll probably have to come up with
> something sane here
> before people make tags up at random.
>
> --
> Paul
>
> ___
> 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] Whispering asphalt

[Peter Elderson]

Whenever the quali ...-reducing is used, I know the stuff or thing actually 
produces ... where ... is bad. 

Mvg Peter Elderson

> Op 2 mei 2019 om 23:52 heeft Paul Allen  het volgende 
> geschreven:
> 
>> On Thu, 2 May 2019 at 22:43, Tobias Wrede  wrote:
> 
>> I would question to use any qualification at all. Whatever is now called 
>> a quiet/whispering/noise reducing asphalt will have become a standard in 
>> a couple of years and then a new type even more noise reducing will have 
>> been invented. Will we then have 
>> noise_reducing_surface=no|little|yes|yes_yes|definitely_yes?
> 
> If we need this tag (I have my doubts) then the only sane way of handling 
> that would be
> something like noise_reduction_db=* where the figure is relative to a 
> "normal" surface
> (e.g., smooth concrete) measured at some specified distance.  I'll leave it 
> to the
> specialists to come up with those conditions.
> 
> I really doubt we need it.  People are unlikely to choose a minimum-noise 
> route even if
> their satnav offered the option, not if it means the journey is longer or 
> slower.  People
> living nearby who are actually affected by road noise will know whether they 
> have a loud
> road or a quiet one without our help.  We won't be able to tell if the tag 
> applies from
> satellite imagery.  It will be hard to verify unless a community proudly puts 
> up signs
> announcing they've spent money on such a surface.  OTOH, people tag things 
> like
> this just because they can, so we'll probably have to come up with something 
> sane here
> before people make tags up at random.
> 
> -- 
> Paul
> 
> ___
> 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] free_standing_emergency_department, amenity or clinic ?

[Graeme Fitzpatrick]

On Fri, 3 May 2019 at 06:44, Nita Rae Sanders  wrote:

> I am envisioning something where all ED's will be designated as such, even
> those embedded within the hospital.
> It is an attempt to provide a common tagging system, exactly for the
> purpose you point out … saving lives.


I totally agree with you that the entrance to the ED should be
distinguished from the "normal" hospital.

A couple of them in our area have been tagged like this:
https://www.openstreetmap.org/node/5045644127#map=17/-28.07073/153.37681
by re-using the =hospital tag & naming it "Emergency" which does work, but
isn't ideal.

I am open to other schemes to distinguish between free_standing and
> embedded, something which allows
> for an ED to be tagged as an ED.


I must admit I still like the idea of putting the ED under the emergency=
key, rather than healthcare=, - healthcare suggests normal day-to-day,
going to the doctor, but emergency is, well, for emergencies! :-)


> To be even more succinct, Shand's (in Gainesville) has an embedded ED, and
> embedded ED for pediatrics, and
> two free_standing ED units.
>

& that should work with 4 x A-E shown, with this one named "Pediatric"

Incidentally, with regard to names, Wiki:

*"Emergency department* became commonly used when emergency medicine
 was recognised as a
medical specialty, and hospitals and medical centres developed departments
of emergency medicine to provide services. Other common variations include
'emergency ward,' 'emergency centre' or 'emergency unit'.

'Accident and Emergency' or 'A&E' is still the accepted term in the United
Kingdom,[5] 
 some Commonwealth 
 countries,[*citation needed
*] and the
Republic of Ireland, as are earlier terms such as 'Casualty' or 'casualty
ward', which continue to be used informally. The same applies to 'emergency
room' or 'ER' in North America, originating when emergency facilities were
provided in a single room of the hospital by the department of surgery."

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

Re: [Tagging] Whispering asphalt

[Graeme Fitzpatrick]

On Fri, 3 May 2019 at 07:53, Paul Allen  wrote:

> If we need this tag (I have my doubts) then the only sane way of handling
> that would be
> something like noise_reduction_db=* where the figure is relative to a
> "normal" surface
> (e.g., smooth concrete) measured at some specified distance.
>

& because concrete is "noisier" than asphalt to drive on, do we then turn
this round & say that "this" stretch of road is noise_increase_db=* ? :-)

Thanks

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