Re: [Tagging] Feature Proposal - Voting - tag:Police

[Mateusz Konieczny]

Just wait for the end of voting schedule.


5 May 2019, 20:53 by bkil.hu...@gmail.com:

> We're now at 20 unanimous approval votes. Do we still need more?
>
> On Sun, Apr 28, 2019 at 11:51 PM Graeme Fitzpatrick <> graemefi...@gmail.com 
> > > wrote:
>
>>
>>
>> On Mon, 29 Apr 2019 at 04:18, Jan S <>> grimpeu...@gmail.com 
>> >> > wrote:
>>
>>>
>>> So, I'm looking forward to your votes
>>>
>>
>> Done! Good luck :-)
>>
>> Thanks
>>
>> Graeme
>> ___
>>  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

[Nick Bolten]

Hi all!

I think a value of "access_aisle" is entirely appropriate and that it makes
sense to be a footway, such as highway=footway + footway=access_aisle,
though if there's another new subtype that would be a catch-all for similar
features that would also make sense (e.g. footway=service). Access aisle
carries the same meaning in other English-speaking countries, including
UK-based governmental recommendations on blue badge spaces.

An access aisle is exactly the feature being described: the extra space
given to the side of a parking space for someone who needs more space to
exit. This is *not* solely for wheelchair users, it's also intended for use
by individuals using walkers or who need assistance exiting or entering a
vehicle, etc. I believe the purpose of this tag is so that any data
consumers can ask the question, "where are parking spaces with access
aisles?" and, "how do they connect to other foot ways?" Those same
consumers would probably want to know a width tag as well and possibly the
width of the parking space - it might warrant some research.

So, with that in mind:

- wheelchair=yes on a footway definitely doesn't describe an access aisle.
It means, "this mapper thinks a wheelchair user can use this footway",
which doesn't communicate anything to do with parking amenities.
wheelchair=* is also not that useful of a tag in the first place, because
wheelchair users disagree on what pedestrian features they care about on a
footway.

- wheelchair=designated is in a similar situation in that it doesn't
communicate that it's an access aisle, but a footway primarily intended for
wheelchair users, which also isn't true of an access aisle.

- footway=wheelchair_loading_aisle does communicate that it's a special
loading aisle, but has the same issue of restricting it's meaning to
wheelchair users.

I'm not sure what term would be a suitable alternative to access aisle,
since it'd need to have these meanings:

- It's a pedestrian space
- It's intended for disability access, which is widely defined and differs
between countries
- It's for passengers entering/exiting vehicles at a parking space.

Best,

Nick

On Thu, May 2, 2019, 8:59 AM Clifford Snow  wrote:

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

Re: [Tagging] Feature Proposal - Voting - tag:Police

[Joseph Eisenberg]

The voting has to be left open for 2 weeks, in case there are some more
people that want to comment or vote. But after that it will be approved if
there are no new votes.

On Mon, May 6, 2019 at 3:54 AM bkil  wrote:

> We're now at 20 unanimous approval votes. Do we still need more?
>
> On Sun, Apr 28, 2019 at 11:51 PM Graeme Fitzpatrick 
> wrote:
>
>>
>>
>> On Mon, 29 Apr 2019 at 04:18, Jan S  wrote:
>>
>>>
>>> So, I'm looking forward to your votes
>>
>>
>> Done! Good luck :-)
>>
>> Thanks
>>
>> Graeme
>> ___
>> 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] Feature Proposal - Voting - tag:Police

[bkil]

We're now at 20 unanimous approval votes. Do we still need more?

On Sun, Apr 28, 2019 at 11:51 PM Graeme Fitzpatrick 
wrote:

>
>
> On Mon, 29 Apr 2019 at 04:18, Jan S  wrote:
>
>>
>> So, I'm looking forward to your votes
>
>
> Done! Good luck :-)
>
> Thanks
>
> Graeme
> ___
> 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 - Key:golf_cart

[bkil]

We're currently at 16 unanimous approval votes. Do we still need more?

On Thu, May 2, 2019 at 2:00 PM Joseph Eisenberg 
wrote:

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

Re: [Tagging] Whispering asphalt

[bkil]

Thank you for bringing street_vendor=* to my attention. I've been looking
for something like this for some time now.

On Fri, May 3, 2019 at 11:33 AM Mateusz Konieczny 
wrote:

>
>
>
> 2 May 2019, 21:55 by amilopow...@u-cloud.ch:
>
> surface=whispering_asphalt or surface=silent_asphalt
>
> Please avoid fragmenting surface tag.
>
> Then I found on Overpass-Turbo someone that tagged "asphalt:type=porous".
>
> Something like that would be preferable if it is mappable.
>
> In general, introducing new values for established tags to tag some
> property should be avoided.
>
> For example I believe that
>
> natural=tree + leaf_cycle=evergreen
> or
> shop=greengrocer+ street_vendor=yes [1]
>
> is preferable over
>
> natural=evergreen_tree
> or
> shop=greengrocer_street_vendor [1]
>
> Using properties allows both to tag detail and to avoid breaking data
> users
> that were created before more detailed tagging started.
>
> [1] I assume here that street vendor is mappable -
> appearing regularly at the same place for a long time
> ___
> 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] RFC - Feature Proposal - area of steps for pedestrians.

[Paul Allen]

On Sun, 5 May 2019 at 01:24, Graeme Fitzpatrick 
wrote:

>
> The modelling intricacies are *w* over my head :-),
>

Mine too.

but would it work as several blocks of "big" steps, modelled by Tobias'
> system, divided by the normal stairs icon?
>

If all other ways fail, it would be worth a try.  It might work.  I will
have to wait until Tobias' system is
rolled out.  If it's rolled out.   Given all the difficult examples posted
here, there are many places
where something like this is needed to do justice to rather prominent
features.

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

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

[ael via Tagging]

On Sun, May 05, 2019 at 07:38:45AM +0200, s8evq wrote:
> Another attempt at summarizing the current situation:
> 
> How should we included the direction?
> 
> - Andy Townsend suggested "Explicit start and/or finish nodes?", but I'm 
> afraid that's not enough to deduce the direction of complex hiking routes 
> like this one: https://www.openstreetmap.org/relation/9535700
> 
> - Using the sorted order of the relation? A lot of criticism on this method. 
> It's fragile and could easily break when newbies edit. On the other hand, 
> it's the only solution we have. Sarah remarked: "An unsorted route is not 
> wrong, it's only less precise. Maps can show it without issues including 
> waymarkedtrails. It just can't give you some advanced features."

Just a thought, but with minimal background knowledge:-

Why not add a boolean tag, something like "sorted=yes" which editors
will always turn off unless the editor (or user) can verify that the
sorting has been maintained? Provided that there is a well defined order
relation, that should be something that editor could automate?

ael


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

Re: [Tagging] Waterway tributary role

[Werner Hoch]

Hi,

Am Samstag, den 13.04.2019, 11:48 + schrieb marc marc:
> destination is the opposite, no ?
> if river A go into river B  :
> in relation A : destination=B
> in relation B : A with rôle tributary

Destination helps human mappers to understand the data.
It is optional.
https://wiki.openstreetmap.org/wiki/Relation:waterway

Currently I only add it if the connection data of the waterway segments
do not end in another river.

e.g. a river flows into an ocean and it has the tag
destination="atlantic ocean".
This tag is usefull as you now don't have to look for an downstream
river, where just some node connection is missing.

For larger rivers you can use wikidata for connection analyses, too.
If the wikidata tags are added to the waterway relations you can
compare the geometric connection (from osm) with the logical
connections described in wikidata:

E.g. the Ohio River https://www.wikidata.org/wiki/Q4915 flows into
(mouth of the watercourse) the https://www.wikidata.org/wiki/Q1497
Mississippi River that flows into Gulf of Mexico https://www.wikidata.
org/wiki/Q12630 which is part of the American Mediterranean Sea
https://www.wikidata.org/wiki/Q470088 and that is part of the Atlantic
Ocean https://www.wikidata.org/wiki/Q97

In my opinion the best mapping method now is to add the wikidata tag
and define the mouth of watercourse in wikidata (if not already there).
I do not like the tributary role in waterway relations and not the
watershed relations.

Regars
Werner



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

Re: [Tagging] Waterway tributary role

[Werner Hoch]

Hi,

Am Donnerstag, den 11.04.2019, 13:48 +0300 schrieb Eugene Podshivalov:
> Hi all,
> Does anyone remember where "tributary" role of waterway relations was
> discussed.
> It is used quite often in Fance but I could not find any reference on
> the wiki.

From 2010 to 2012 the mapping of waterway relations has been unified
and https://wiki.openstreetmap.org/wiki/Relation:waterway was the
result of it.

Part of the discussion about the tributary role is here:
https://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Waterway#tributary_vs._tributary_of_relation_role

The role has not made it into the the final definition of the waterway
relation model, but is still used in France.

You can see the bad side effect in Wikipedia:
Nice rivers in the map:
https://en.wikipedia.org/wiki/Danube
https://en.wikipedia.org/wiki/Mississippi_River

The Seine with it's tributaries
https://en.wikipedia.org/wiki/Seine
displays the watershed.

In parallel there is the
https://wiki.openstreetmap.org/wiki/Relation:watershed mapping. This at
least divides the mapping of watersheds and waterway into seperate
models. Nobody ever wrote a proposal about this.

Regards
Werner




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