Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> I’m asking for comments on 
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional

Two big comments:

  First, the current wiki documentation about ele and Altitude should be
  really straigthened out, so that we have a basis for what we are
  comparing to.

  Second, the notion of a single regional vertical datum doesn't really
  work.  In the US, that could be the old NGVD29, or the current NAVD88.
  Plus, we are about to get NATRF2022.  However, all of these are within
  a meter or so, and in terms of vertical data in OSM, that's not really
  a big problem.  So if there is going to be precision, then we should
  follow GIS and have an explicit datum.  I would say an EPSG code is
  sensible -- see the proj package for canonical values.



As for ele/Altitude, there is great confusion out there about "WGS84"
and two separate concepts:

  height above the ellipsoid.  Often written HAE. The ellipsoid is a
  mathematical surface that is NOT a surface of equal gravity.  While
  geodesists and geodetic surveyors use it, and while it's part of the
  calculations within GPS, I am not aware of a single vertical datum in
  use in any country that is relative to the ellipisoid.  Note that
  water does not flow "downhill" when "down" means to a lower value of
  HAE.  Water is hugely important in elevation and mapping.

  height above geoid, or height above a reference equal-gravity surface,
  or height above sea level.  (Yes, I realize that "sea level" is a huge
  can of worms.)   This is more or less what every height system uses or
  intends to use.


In WGS84, one gets from the base computation lat/lon and a height above
the ellipsoid.  This is purely a geometric answer and is totally
disconnected from grravity.  Then, GPS receivers use a gravity model to
compute the offset from the ellipsoid and the reference gravity surface
(which is more or less the "sea level surface"), and they them use that
to get a "height above sea level".  Receivers that display to humans
display this sea level height.  NMEA has that same sea level height.

(Android stands alone in that the API returns height above ellipsoid.
That's not wrong, but it is unusual.  IMHO how Android defines an
interface is irrelevant to OSM's definitions.)


When people say "WGS84 altitude", they mean the height above the WGS84
equal-gravity surface as computed from the ellipsoidal height and the
gravity model.  This is sort of 0m at sea level.  Note that the
ellipsoid can be 100m different from this equal-gravity surface, and is
often significantly different.  It's ~30m in Boston and I hear it's 50m
in Switzerland.  Nobody who says "WGS84 altitude" really means "WGS84
ellipsoidal height".  If they did, they would say "WGS84 ellipsoidal
height".


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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Graeme Fitzpatrick]

On Mon, 4 May 2020 at 04:55, Jean-Marc Liotier  wrote:

> Then, isn't it nice that leisure=common has been abandoned in it's former
> British usage ? As far as I know, that was its only other usage - or is it
> also used in other parts of the world ?
>

I don't know how they break up between leisure= v landuse=, but town
commons are to be found in, or on the outskirts of, many (most?) small
country towns in Australia.

Thanks

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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Enock Seth Nyamador]

This has been a long thread so far. landuse=common, I have used it pretty
much in Ghana and West Africa as well when an open space just didn't serve
one purpose, neither a pitch nor park but can be used for both. This
deprecation needs a second look.

Best,

Am So., 3. Mai 2020 um 18:55 Uhr schrieb Jean-Marc Liotier :

> On 5/3/20 7:36 PM, Marc M. wrote:
>
> Le 03.05.20 à 18:13, Joseph Eisenberg a écrit :
>
> it is true that this tag (leisure=common)is ambiguous because it is being
> used for totally different purposes in different countries.
>
> I think this argument is crucial. if more than one meaning exists for a
> tag, having a precise meaning for a country is useless, osm is a global
> base, it's a bad idea to hope a render style "tag A rendered as meaning1 in
> Africa, as meaning2 in Europe, as meaning3 in Asia".
>
> Then, isn't it nice that leisure=common has been abandoned in it's former
> British usage ? As far as I know, that was its only other usage - or is it
> also used in other parts of the world ?
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

On 5/3/20 7:36 PM, Marc M. wrote:

Le 03.05.20 à 18:13, Joseph Eisenberg a écrit :
it is true that this tag (leisure=common)is ambiguous because it is 
being used for totally different purposes in different countries. 
I think this argument is crucial. if more than one meaning exists for 
a tag, having a precise meaning for a country is useless, osm is a 
global base, it's a bad idea to hope a render style "tag A rendered as 
meaning1 in Africa, as meaning2 in Europe, as meaning3 in Asia".


Then, isn't it nice that leisure=common has been abandoned in it's 
former British usage ? As far as I know, that was its only other usage - 
or is it also used in other parts of the world ?



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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Marc M.]

Hello,

Le 03.05.20 à 18:13, Joseph Eisenberg a écrit :
> it is true that this tag (leisure=common)is ambiguous because it is
> being used for totally different purposes in different countries.

I think this argument is crucial.
if more than one meaning exists for a tag, having a precise meaning for
a country is useless, osm is a global base, it's a bad idea to hope a
render style "tag A rendered as meaning1 in Africa, as meaning2 in
Europe, as meaning3 in Asia".
for quality, it is important to abandon multi-meaning tags and use
new tags instead, one for each existing sense.

as the subject said "leisure=common <...> need a replacement"
several replacements.

Regards,
Marc

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

Re: [Tagging] Doorzone bicycle lanes

[Volker Schmidt]

I would advocate a more generic approach that remains open to other types
of hazards (there are many, unfortunately).
A generic
hazard:bicycle=yes|dooring|pedestrians_on_cycleway|dangerous_exit|whatever
(I have started using provisionally
hazard:bicycle=yes plus description= but that needs improvement)
Then you putthat that to whatever element is involved (way, crossing node,
gate, ...)

In the same way you could create hazard:foot (or hazard:pedestrian), and
hazard:wheelchair, and  hazard:motorcycle, and hazard:motorcar .

Or something along these lines ...




On Sun, 3 May 2020 at 16:42, Andrew Harvey  wrote:

> On Mon, 4 May 2020 at 00:30, Hubert87  wrote:
>
>> (Two replies is one)
>>
>> Am 03.05.2020 um 15:29 schrieb Andrew Harvey:
>>
>> On Sun, 3 May 2020 at 23:14, Hubert87  wrote:
>>
>>> I like the idea of using "buffered".
>>>
>>> "doorzone" to me, is a pretty laoded and subjective.
>>>
>>
>> I don't see it as subjective. If there is parking directly next to the
>> bicycle lane and if a parked car opening a door would intersect with the
>> marked bicycle lane, then the bicycle lane is within a door zone. Is it the
>> term that's the issue or the concept? Judging by the wikipedia page
>> https://en.wikipedia.org/wiki/Doored it seems like a fairly widespread
>> term globally.
>>
>> I'm familiar with that term and the concept. However 'doorzone' (to me)
>> seems to have negativ implications (=> hazard), due to cyclists being
>> doored. (If I remeber corectly, cyclelanes/paths next to parking cars don't
>> seem to be a big problem in NL due to the "Dutch Reach", this is similar to
>> cyclist being right-hooked as it is inherend of the position of the
>> cycleway relativ to the carrigeway)
>>
>> So, I'd rather see the concept of "doorzone" be an emergend property of
>> multiple other tags (buffer, position of cycle lane, ...) derived by data
>> users/renderes/routers.
>>
> While that does sound better, it is also quite complex as you point out
> taking into account buffer, buffer distance, position of lanes but also
> relative ordering of the traffic, parking and bicycle lane, counterflow
> cycle lanes. Because of this a quick and simply "doorzone" tag I think is
> useful for mappers who don't want to go into such detail. It also makes it
> clear, otherwise there could always be a slight difference between data
> contributor expectation and data consumer given the complex evaluation
> without a dedicated door zone tag.
>
>
>
> On Mon, 4 May 2020 at 00:19, Martin Koppenhoefer 
> wrote:
>
>> do you really need the lane component?
>> Could be cycleway:doorzone=yes/no
>> or with left/right when lanes on both sides exist that have different
>> properties.
>>
>
> Agreed.
> ___
> 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] With leisure=common deprecated, Senegal & Mali need a replacement

[Joseph Eisenberg]

We stopped rendering it, but we didn’t edit the wiki page to set the status
to “deprecated”. Many tags are not rendered because they are ambiguous
(e.g. natural=fell) but that doesn’t mean they are deprecated.

On Sun, May 3, 2020 at 9:34 AM Andy Townsend  wrote:

> On 03/05/2020 17:13, Joseph Eisenberg wrote:
> > The deprecation was not discussed, and it was not done by anyone at
> > OpenStreetMap Carto, BTW.
> >
> Er - wasn't that
> https://github.com/gravitystorm/openstreetmap-carto/pull/3619 ? You
> commented in the discussion there...
>
> Best Regards,
>
> Andy
>
>
>
> ___
> 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] With leisure=common deprecated, Senegal & Mali need a replacement

[Andy Townsend]

On 03/05/2020 17:13, Joseph Eisenberg wrote:
The deprecation was not discussed, and it was not done by anyone at 
OpenStreetMap Carto, BTW.


Er - wasn't that 
https://github.com/gravitystorm/openstreetmap-carto/pull/3619 ? You 
commented in the discussion there...


Best Regards,

Andy



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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Joseph Eisenberg]

The deprecation was not discussed, and it was not done by anyone at
OpenStreetMap Carto, BTW.

However, it is true that this tag (leisure=common)is ambiguous because it
is being used for totally different purposes in different countries.

So while you might be using it in a consistent way in your region, database
users who are looking at the whole globe will have trouble interpreting
what it means.

That's why it would be better to propose a new, different tag to map open
areas of unvegetated land in villages and towns.

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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Rafael Avila Coya]

I also agree that leisure=common (leisure, not landuse) should continue 
to be used as it has been up to now for African (and not only African) 
countries, because () their context differs so much from European 
countries, for example. I find it the most suitable, and it's been the 
one we've been using for years without any conflict with other tags.


I had opened this talk back in March [1], and got the answer [2] that 
this deprecation is bogus, and based on a decision made by 
openstreetmap-carto maintainers to drop the tag from rendering...


Cheers,

Rafael.

[1] https://lists.openstreetmap.org/pipermail/hot/2020-March/015194.html

[2] https://lists.openstreetmap.org/pipermail/hot/2020-March/015196.html

O 30/04/20 ás 16:29, Jean-Marc Liotier escribiu:

On 4/30/20 2:12 PM, Martin Koppenhoefer wrote:
Am Do., 30. Apr. 2020 um 14:07 Uhr schrieb Andy Townsend 
mailto:ajt1...@gmail.com>>:



How about "leisure=common"?


+1, I would prefer leisure=common over landuse, as these seem to be 
"features"

(countable, etc.)


leisure=common is an especially good candidate because land which is 
legally designated as common land in the UK should nowadays be tagged 
as designation=common - and there is therefore no longer a namespace 
collision... leisure=common is available for recycling into our 
African purpose !






___
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] [Talk-ml] [Talk-sn] With leisure=common deprecated, Senegal & Mali need a replacement

[severin.menard via Tagging]

Oui désolé, en effet je me suis trompé sur la clé !

Yes sorry, my mistake regarding the right key!

‐‐‐ Original Message ‐‐‐
Le dimanche 3 mai 2020 17:54, Pierre Béland via Talk-ml 
 a écrit :

> Fr
>
> Oups un instant Jean-Marc. Erreur sans doute de la part de Séverin, je disais 
> bien
>  leisure=common
>
> En
>
> Oops a moment Jean-Marc. Probably a mistake on Séverin's part, I did say...
>  leisure=common
>
> Pierre
>
> Le dimanche 3 mai 2020 11 h 13 min 40 s UTC−4, Jean-Marc Liotier 
>  a écrit :
>
> So, this discussion gravitates towards using landuse=common for those African 
> urban freely accessible multipurpose open spaces, which I fully support.
>
> Implementing this change requires the following actions:
>
> - Editing the leisure=common wiki page, in French and in English (I'll do 
> that)
>
> - Reinstating the rendering of leisure=common in downstream cartographic 
> styles, would be even better if the color matched the surface=* so that sandy 
> surfaces don't appear green.
>
> - Reinstating the rendering of leisure=common in JOSM's default style (it 
> recently changed to grey to mark deprecation). (I'll open a JOSM ticket
>
> - Altering QA rules (JOSM Validator and Osmose) so that the leisure=common 
> deprecation only applies to the United Kingdom of Great Britain, where 
> commons have a legal definition and designation=common must be used for them. 
> (I'll open a JOSM ticket but if someone has prior experience interacting with 
> the Osmose people, that would be nice)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-sn] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

Indeed I have misread. Let's leave the debate open for a little while 
more - this is no time for implementation yet.


Oui, j'ai mal lu, trop rapidement. Laissons donc la discussion continuer 
- ce n'est pas encore le moment d'agir.



On 5/3/20 5:54 PM, Pierre Béland wrote:

Fr

Oups un instant Jean-Marc. Erreur sans doute de la part de Séverin, je 
disais bien

leisure=common

En

Oops a moment Jean-Marc. Probably a mistake on Séverin's part, I did 
say...

 leisure=common

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

Re: [Tagging] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Andy Townsend]

On 03/05/2020 16:12, Jean-Marc Liotier wrote:


So, this discussion gravitates towards using landuse=common for those 
African urban freely accessible multipurpose open spaces, which I 
fully support.


Just to be clear you've said "landuse=common" above but "leisure=common" 
below?




Implementing this change requires the following actions:

- Editing the leisure=common wiki page, in French and in English (I'll 
do that)


- Reinstating the rendering of leisure=common in downstream 
cartographic styles, would be even better if the color matched the 
surface=* so that sandy surfaces don't appear green.


Each cartographic style will have its own sorts of things that it wants 
to show, and I can fully understand some of them thinking that 
"leisure=common" isn't something that they want to show. You'll be able 
to submit pull requests to those that are in github, but there's no 
"automatic right of feature X to be shown".


With regard to the second bit, I'd be happy to accept a pull request at 
https://github.com/SomeoneElseOSM/SomeoneElse-style that did that (it'd 
be about half a dozen lines of lua).  Setting up a map server based on 
that is pretty straightforward - it's set out in 
https://wiki.openstreetmap.org/wiki/User:SomeoneElse/Ubuntu_1804_tileserver_load 
which in turn is very similar to 
https://switch2osm.org/serving-tiles/manually-building-a-tile-server-18-04-lts/ 
.  Server costs would be significant on an average salary in Mali (a 
day's wages per month or so?) but much less so on an a European or North 
American one (perhaps a cup of coffee-shop coffee every few days).



- Reinstating the rendering of leisure=common in JOSM's default style 
(it recently changed to grey to mark deprecation). (I'll open a JOSM 
ticket


- Altering QA rules (JOSM Validator and Osmose) so that the 
leisure=common deprecation only applies to the United Kingdom of Great 
Britain, where commons have a legal definition and designation=common 
must be used for them. (I'll open a JOSM ticket but if someone has 
prior experience interacting with the Osmose people, that would be nice)


Actually, I'd suggest that "leisure=common" was perfectly valid in the 
UK too.  Back in 2017 it was misused as a tag in the UK but now it 
mostly isn't; I added it back in to the style that I maintain for 
UK/Ireland this year.  Obviously "designation", if known, makes sense too.


Best Regards,

Andy



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

Re: [Tagging] [Talk-sn] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Pierre Béland via Tagging]

Fr
Oups un instant Jean-Marc. Erreur sans doute de la part de Séverin, je disais 
bien leisure=common 

En
Oops a moment Jean-Marc. Probably a mistake on Séverin's part, I did say...
 leisure=common 
Pierre 
 

Le dimanche 3 mai 2020 11 h 13 min 40 s UTC−4, Jean-Marc Liotier 
 a écrit :  
 
  
So, this discussion gravitates towards using landuse=common for those African 
urban freely accessible multipurpose open spaces, which I fully support.
 
 
Implementing this change requires the following actions:
 
- Editing the leisure=common wiki page, in French and in English (I'll do that)
 
- Reinstating the rendering of leisure=common in downstream cartographic 
styles, would be even better if the color matched the surface=* so that sandy 
surfaces don't appear green.
 
- Reinstating the rendering of leisure=common in JOSM's default style (it 
recently changed to grey to mark deprecation). (I'll open a JOSM ticket
 
- Altering QA rules (JOSM Validator and Osmose) so that the leisure=common 
deprecation only applies to the United Kingdom of Great Britain, where commons 
have a legal definition and designation=common must be used for them. (I'll 
open a JOSM ticket but if someone has prior experience interacting with the 
Osmose people, that would be nice)
 

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

Re: [Tagging] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Joseph Eisenberg]

The tag landuse=common is different than leisure=common but the two seem to
be mixed up in this post.

The new tag landuse=common is not yet documented:
https://wiki.openstreetmap.org/wiki/Tag:landuse=common
It has been used 197 times, but perhaps due to confusion with the more
common tag leisure=common:
https://taginfo.openstreetmap.org/tags/landuse=common

The existing tag is leisure=common -
https://wiki.openstreetmap.org/wiki/Tag:leisure=common

-- Joseph Eisenberg

— Joseph Eisenberg

On Sun, May 3, 2020 at 8:14 AM Jean-Marc Liotier  wrote:

> So, this discussion gravitates towards using landuse=common for those
> African urban freely accessible multipurpose open spaces, which I fully
> support.
>
> Implementing this change requires the following actions:
>
> - Editing the leisure=common wiki page, in French and in English (I'll do
> that)
>
> - Reinstating the rendering of leisure=common in downstream cartographic
> styles, would be even better if the color matched the surface=* so that
> sandy surfaces don't appear green.
>
> - Reinstating the rendering of leisure=common in JOSM's default style (it
> recently changed to grey to mark deprecation). (I'll open a JOSM ticket
>
> - Altering QA rules (JOSM Validator and Osmose) so that the leisure=common
> deprecation only applies to the United Kingdom of Great Britain, where
> commons have a legal definition and designation=common must be used for
> them. (I'll open a JOSM ticket but if someone has prior experience
> interacting with the Osmose people, that would be nice)
>
>
> On 5/3/20 4:19 PM, severin.menard via Tagging wrote:
>
> Je suis d'accord avec Pierre : le tag landuse=common convient bien à ces
> espaces ouverts dans les villages et villes africaines et un parc n'a pas
> grand-chose à voir avec.
> 
> I agree with Pierre: the tag landuse=common is well suited to these open
> spaces in African villages and towns and a park has little to do with it.
>
>
> ‐‐‐ Original Message ‐‐‐
> Le mercredi 29 avril 2020 21:59, Pierre Béland via Talk-ml
>   a écrit :
>
> Like others, I did map many of these. I can tell you that we often see a
> common space in center of african villages, often near the school,  and  it
> is surely not green and have no facilities like in the Nordic countries
> parks.
>
> People have to understand that there are often no infrastructures in
> African villages. But young people still gather and play.
>
> I dont think that the OSM tagging schema should reflect the legal status
> in specific countries like UK. Various tags can reflect various realities.
> And leisure=common seems to be quite well adapted to Africa and dont exist
> to stretch the legal defininition of UK.
>
> When the tag is used in UK, I would understand that the UK contributors
> want to follow a certain rule particular to their country.
>
> But I dont agree to deprecate the the leisure=common tag for Africa.
>
>
>
> Le mercredi 29 avril 2020 15 h 34 min 57 s UTC−4, Jean-Marc Liotier
>   a écrit :
>
>
> Here is a 360° picture of a square in Dakar:
> https://www.mapillary.com/map/im/jYNQFMwHiNEZRCnpi71heA - larger than a
> street (it occupies a whole city block), used as a multipurpose common
> area (pickup soccer games are a staple but parking or lounging around
> also occur, and the occasional popular event) and usually surfaced with
> sand or whatever the ground is.
>
> We have long tagged it leisure=common (389 ways in Senegal and 486 in
> Mali according to http://overpass-turbo.eu/s/TqN) - which is a bit of
> stretch from the British legal definition, but worked well enough and
> did not conflict with its British usage. But leisure=common is now
> deprecated
>
> So, what should we use instead ?
> https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon suggests using
> leisure=park - which isn't too much of a stretch functionally but evokes
> greenery that does not occur here (though British commons are just as
> green and we were happy with leisure=common)... Any other ideas ? Or I'm
> going to use leisure=park+surface=sand !
>
>
> ___
> 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] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

So, this discussion gravitates towards using landuse=common for those 
African urban freely accessible multipurpose open spaces, which I fully 
support.


Implementing this change requires the following actions:

- Editing the leisure=common wiki page, in French and in English (I'll 
do that)


- Reinstating the rendering of leisure=common in downstream cartographic 
styles, would be even better if the color matched the surface=* so that 
sandy surfaces don't appear green.


- Reinstating the rendering of leisure=common in JOSM's default style 
(it recently changed to grey to mark deprecation). (I'll open a JOSM ticket


- Altering QA rules (JOSM Validator and Osmose) so that the 
leisure=common deprecation only applies to the United Kingdom of Great 
Britain, where commons have a legal definition and designation=common 
must be used for them. (I'll open a JOSM ticket but if someone has prior 
experience interacting with the Osmose people, that would be nice)



On 5/3/20 4:19 PM, severin.menard via Tagging wrote:
Je suis d'accord avec Pierre : le tag landuse=common convient bien à 
ces espaces ouverts dans les villages et villes africaines et un parc 
n'a pas grand-chose à voir avec.


I agree with Pierre: the tag landuse=common is well suited to these 
open spaces in African villages and towns and a park has little to do 
with it.



‐‐‐ Original Message ‐‐‐
Le mercredi 29 avril 2020 21:59, Pierre Béland via Talk-ml 
 a écrit :


Like others, I did map many of these. I can tell you that we often 
see a common space in center of african villages, often near the 
school,  and  it is surely not green and have no facilities like in 
the Nordic countries parks.


People have to understand that there are often no infrastructures in 
African villages. But young people still gather and play.


I dont think that the OSM tagging schema should reflect the legal 
status in specific countries like UK. Various tags can reflect 
various realities.  And leisure=common seems to be quite well adapted 
to Africa and dont exist to stretch the legal defininition of UK.


When the tag is used in UK, I would understand that the UK 
contributors want to follow a certain rule particular to their country.


But I dont agree to deprecate the the leisure=common tag for Africa.



Le mercredi 29 avril 2020 15 h 34 min 57 s UTC−4, Jean-Marc Liotier 
 a écrit :



Here is a 360° picture of a square in Dakar:
https://www.mapillary.com/map/im/jYNQFMwHiNEZRCnpi71heA - larger than a
street (it occupies a whole city block), used as a multipurpose common
area (pickup soccer games are a staple but parking or lounging around
also occur, and the occasional popular event) and usually surfaced with
sand or whatever the ground is.

We have long tagged it leisure=common (389 ways in Senegal and 486 in
Mali according to http://overpass-turbo.eu/s/TqN) - which is a bit of
stretch from the British legal definition, but worked well enough and
did not conflict with its British usage. But leisure=common is now
deprecated

So, what should we use instead ?
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon suggests using
leisure=park - which isn't too much of a stretch functionally but evokes
greenery that does not occur here (though British commons are just as
green and we were happy with leisure=common)... Any other ideas ? Or I'm
going to use leisure=park+surface=sand !


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

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

sent from a phone

> On 3. May 2020, at 15:23, Jarek Piórkowski  wrote:
> 
> What happens when the sign is replaced or removed?


if the information on the sign is replaced you should obviously update the 
value, when it disappears I would not act, but I imagine the purist answer 
would be to remove the tag.

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

Re: [Tagging] Doorzone bicycle lanes

[Andrew Harvey]

On Mon, 4 May 2020 at 00:30, Hubert87  wrote:

> (Two replies is one)
>
> Am 03.05.2020 um 15:29 schrieb Andrew Harvey:
>
> On Sun, 3 May 2020 at 23:14, Hubert87  wrote:
>
>> I like the idea of using "buffered".
>>
>> "doorzone" to me, is a pretty laoded and subjective.
>>
>
> I don't see it as subjective. If there is parking directly next to the
> bicycle lane and if a parked car opening a door would intersect with the
> marked bicycle lane, then the bicycle lane is within a door zone. Is it the
> term that's the issue or the concept? Judging by the wikipedia page
> https://en.wikipedia.org/wiki/Doored it seems like a fairly widespread
> term globally.
>
> I'm familiar with that term and the concept. However 'doorzone' (to me)
> seems to have negativ implications (=> hazard), due to cyclists being
> doored. (If I remeber corectly, cyclelanes/paths next to parking cars don't
> seem to be a big problem in NL due to the "Dutch Reach", this is similar to
> cyclist being right-hooked as it is inherend of the position of the
> cycleway relativ to the carrigeway)
>
> So, I'd rather see the concept of "doorzone" be an emergend property of
> multiple other tags (buffer, position of cycle lane, ...) derived by data
> users/renderes/routers.
>
While that does sound better, it is also quite complex as you point out
taking into account buffer, buffer distance, position of lanes but also
relative ordering of the traffic, parking and bicycle lane, counterflow
cycle lanes. Because of this a quick and simply "doorzone" tag I think is
useful for mappers who don't want to go into such detail. It also makes it
clear, otherwise there could always be a slight difference between data
contributor expectation and data consumer given the complex evaluation
without a dedicated door zone tag.



On Mon, 4 May 2020 at 00:19, Martin Koppenhoefer 
wrote:

> do you really need the lane component?
> Could be cycleway:doorzone=yes/no
> or with left/right when lanes on both sides exist that have different
> properties.
>

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

Re: [Tagging] Doorzone bicycle lanes

[Hubert87]

(Two replies is one)

Am 03.05.2020 um 15:29 schrieb Andrew Harvey:


On Sun, 3 May 2020 at 23:14, Hubert87 mailto:sg.fo...@gmx.de>> wrote:

I like the idea of using "buffered".

"doorzone" to me, is a pretty laoded and subjective.


I don't see it as subjective. If there is parking directly next to the
bicycle lane and if a parked car opening a door would intersect with
the marked bicycle lane, then the bicycle lane is within a door zone.
Is it the term that's the issue or the concept? Judging by the
wikipedia page https://en.wikipedia.org/wiki/Doored it seems like a
fairly widespread term globally.


I'm familiar with that term and the concept. However 'doorzone' (to me)
seems to have negativ implications (=> hazard), due to cyclists being
doored. (If I remeber corectly, cyclelanes/paths next to parking cars
don't seem to be a big problem in NL due to the "Dutch Reach", this is
similar to cyclist being right-hooked as it is inherend of the position
of the cycleway relativ to the carrigeway)

So, I'd rather see the concept of "doorzone" be an emergend property of
multiple other tags (buffer, position of cycle lane, ...) derived by
data users/renderes/routers.




Maybe something like:

cycleway:right=lane
cycleway:right:lane=exclusive
(cycleway:right:buffered=right/left/both/no)
cycleway:right:buffered:right=yes/no/0.3(m)


The problem still exists that this doesn't say if you're at risk of
being doored https://en.wikipedia.org/wiki/Doored (eg no buffer, but
also no parking lane), so a specific tag like
cycleway:lane:doorzone=yes/no/buffer addresses that better in my opinion.


Ideally, one of theese properties describing would need to use the
"parking:lane=*"- tag, to make is tag more wide spread.
My rational is, using the same tags, that one could conclude the conzept
of "doorzone" but also other parking conflicts, like crossing the cycle
lane to pull  in/out of an parking spot.

Am 03.05.2020 um 16:07 schrieb Andrew Harvey:

I've started sketching this out at
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:cycleway:lane:doorzone
 but
I think we need more examples of the full range of scenarios as I've
only got two so far.

On Sun, 3 May 2020 at 23:35, Hubert87 mailto:sg.fo...@gmx.de>> wrote:

Meant to also add a discriptive tag, like

cycleway:right:parking_lane=right/left/both/no/yes


You would just use the existing parking:lane:parallel=left/right/both
tag no?


Yes and No.
Yes, as it give additional data to use.
No, not "just", because that would not give the position of the parking
lane relativ to the cycleway/cyclelane.

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

Re: [Tagging] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[severin.menard via Tagging]

Bonjour,

Je suis d'accord avec Pierre : le tag landuse=common convient bien à ces 
espaces ouverts dans les villages et villes africaines et un parc n'a pas 
grand-chose à voir avec.

Severin


I agree with Pierre: the tag landuse=common is well suited to these open spaces 
in African villages and towns and a park has little to do with it.

Translated with www.DeepL.com/Translator (free version)

‐‐‐ Original Message ‐‐‐
Le mercredi 29 avril 2020 21:59, Pierre Béland via Talk-ml 
 a écrit :

> Hi Jean-Marc
>
> Like others, I did map many of these. I can tell you that we often see a 
> common space in center of african villages, often near the school,  and  it 
> is surely not green and have no facilities like in the Nordic countries parks.
>
> People have to understand that there are often no infrastructures in African 
> villages. But young people still gather and play.
>
> I dont think that the OSM tagging schema should reflect the legal status in 
> specific countries like UK. Various tags can reflect various realities.  And 
> leisure=common seems to be quite well adapted to Africa and dont exist to 
> stretch the legal defininition of UK.
>
> When the tag is used in UK, I would understand that the UK contributors want 
> to follow a certain rule particular to their country.
>
> But I dont agree to deprecate the the leisure=common tag for Africa.
>
> Pierre
>
> Le mercredi 29 avril 2020 15 h 34 min 57 s UTC−4, Jean-Marc Liotier 
>  a écrit :
>
> Here is a 360° picture of a square in Dakar:
> https://www.mapillary.com/map/im/jYNQFMwHiNEZRCnpi71heA- larger than a
> street (it occupies a whole city block), used as a multipurpose common
> area (pickup soccer games are a staple but parking or lounging around
> also occur, and the occasional popular event) and usually surfaced with
> sand or whatever the ground is.
>
> We have long tagged it leisure=common (389 ways in Senegal and 486 in
> Mali according to http://overpass-turbo.eu/s/TqN) - which is a bit of
> stretch from the British legal definition, but worked well enough and
> did not conflict with its British usage. But leisure=common is now
> deprecated
>
> So, what should we use instead ?
> https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommonsuggests using
> leisure=park - which isn't too much of a stretch functionally but evokes
> greenery that does not occur here (though British commons are just as
> green and we were happy with leisure=common)... Any other ideas ? Or I'm
> going to use leisure=park+surface=sand !
>
> ___
> Talk-ml mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ml___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Doorzone bicycle lanes

[Martin Koppenhoefer]

sent from a phone

> On 3. May 2020, at 10:52, Andrew Harvey  wrote:
> 
> I still would learn towards cycleway:lane:doorzone=yes as being my preferred 
> option though, since you can tag =no as well.


do you really need the lane component?
Could be cycleway:doorzone=yes/no
or with left/right when lanes on both sides exist that have different 
properties.

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

Re: [Tagging] Doorzone bicycle lanes

[Andrew Harvey]

On Sun, 3 May 2020 at 23:32, Volker Schmidt  wrote:

> Here in Italy we do have both cycle lanes, cycle paths, and foot-cycle
> paths with dooring risk. So far I have not seen any tagging for these, but
> I would welcome a uniform approach for tagging this hazard on any type of
> cycling infrastructure, and it should be a hazard tag. In that context I
> would like to have also a way of tagging the danger of pedestrians crossing
> the cycle path/lane (e.g. cycle lane between roadside parking spaces and
> sidewalk ; another
> example  - both
> show passenger-door hazard)
> I would not put the hazard on the car parking spaces, it needs to go on
> the way the cyclist takes.
>

That example of https://www.openstreetmap.org/way/343935838 is a good one
since it's not a bicycle lane, it's physically separated from the road and
mapped as shared path using a way separate from the road
(bicycle=designated + foot=designated + segregated=yes). So in that case I
do agree that this door zone concept doesn't just apply to on road bicycle
lanes (cycleway=lane). Maybe cycleway:doorzone=yes/no=buffer is better than
cycleway:lane:doorzone then so it can apply to all types of bicycle ways.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Doorzone bicycle lanes

[Andrew Harvey]

I've started sketching this out at
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:cycleway:lane:doorzone
but
I think we need more examples of the full range of scenarios as I've only
got two so far.

On Sun, 3 May 2020 at 23:35, Hubert87  wrote:

> Meant to also add a discriptive tag, like
>
> cycleway:right:parking_lane=right/left/both/no/yes
>

You would just use the existing parking:lane:parallel=left/right/both tag
no?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Doorzone bicycle lanes

[Hubert87]

Meant to also add a discriptive tag, like

cycleway:right:parking_lane=right/left/both/no/yes

Am 03.05.2020 um 15:12 schrieb Hubert87:

I like the idea of using "buffered".

"doorzone" to me, is a pretty laoded and subjective.

Maybe something like:

cycleway:right=lane
cycleway:right:lane=exclusive
(cycleway:right:buffered=right/left/both/no)
cycleway:right:buffered:right=yes/no/0.3(m)

Yours
Hubert87

Am 03.05.2020 um 10:55 schrieb Jan Michel:

Hi,
I oppose adding this officially to the top-level cycleway:lane tag.
I see this information as one more property of the cycleway, like
surface, smoothness, width and so on.

We already have a documented key 'cycleway:buffer' that is described
as the width of the buffer space between car lanes and the bicycle lane.
The 'cycleway:buffer' tag is also used combined with :left and :right
to denote the buffer on left-hand and right-hand side of the cycleway.

Mappers in Berlin worked on a more detailed tagging of buffer and
protection of bicycle lanes, see (unfortunately in German only)
https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege

I'd suggest to get in contact with them and discuss this. I imagine that
this information could fit very well into the cycleway:buffer tag - A
door zone is a non-existent buffer, so instead of 'no' one could use
'doorzone' as one of the non-numeric values.

Jan



On 03.05.20 08:37, Andrew Harvey wrote:

For a while myself and others have been using cycleway:lane=doorzone
to say the bicycle lane is in a doorzone, I've now added
documentation of this as "in use" at
https://wiki.openstreetmap.org/wiki/Key:cycleway:lane. However this
conflicts with the other "in use" cycleway:lane=exclusive/advisory,
since you can have exclusive/advisory lanes which are doorzone or not.

None of these have gone through a proposal process and both are
independently in use.



___
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] Doorzone bicycle lanes

[Volker Schmidt]

Here in Italy we do have both cycle lanes, cycle paths, and foot-cycle
paths with dooring risk. So far I have not seen any tagging for these, but
I would welcome a uniform approach for tagging this hazard on any type of
cycling infrastructure, and it should be a hazard tag. In that context I
would like to have also a way of tagging the danger of pedestrians crossing
the cycle path/lane (e.g. cycle lane between roadside parking spaces and
sidewalk ; another
example  - both
show passenger-door hazard)
I would not put the hazard on the car parking spaces, it needs to go on the
way the cyclist takes.

Il dom 3 mag 2020, 11:38 Robert Skedgell  ha scritto:

> On 03/05/2020 07:37, Andrew Harvey wrote:
> > For a while myself and others have been using cycleway:lane=doorzone to
> > say the bicycle lane is in a doorzone, I've now added documentation of
> > this as "in use"
> > at https://wiki.openstreetmap.org/wiki/Key:cycleway:lane. However this
> > conflicts with the other "in use" cycleway:lane=exclusive/advisory,
> > since you can have exclusive/advisory lanes which are doorzone or not.
> >
> > None of these have gone through a proposal process and both are
> > independently in use.
> >
> > Given cycleway:lane=exclusive/advisory have more use than doorzone, I
> > think we should put cycleway:lane=exclusive/advisory through the formal
> > proposal process and then change how we map doorzones as
> > cycleway:lane:doorzone=yes so it can work together with
> exclusive/advisory.
> >
> > Any other opinions?
> >
> > Also on https://wiki.openstreetmap.org/wiki/Key:cycleway:lane there is
> > cycleway=shared_lane + cycleway:lane=pictogram, should this not be
> > cycleway:shared_lane=pictogram?
> >
> > Given https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dshared_lane is
> > already defined as "Used to identify roads which contain a shared lane
> > marking, or sharrow, to indicate that the travel lane is shared by
> > bicycles and other vehicles." what does the =pictogram tag mean and how
> > is it different to cycleway=shared_lane?
>
> Once a consensus has been arrived at for tagging the cycle lane itself,
> would it also be worth suggesting in the wiki that the tag(s) be used in
> conjunction with parking:lane:*=parallel (
> https://wiki.openstreetmap.org/wiki/Key:parking:lane )?
>
> As a separate issue, there are advisory cycle lanes combined with a
> single yellow line parking restriction, where there is a usable lane at
> the times when parking is prohibited, but effectively no cycle lane when
> parking is permitted (sometimes with a doorzone risk on the carriageway).
>
> --
> Robert Skedgell (rskedgell)
>
> ___
> 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] Doorzone bicycle lanes

[Andrew Harvey]

On Sun, 3 May 2020 at 23:14, Hubert87  wrote:

> I like the idea of using "buffered".
>
> "doorzone" to me, is a pretty laoded and subjective.
>

I don't see it as subjective. If there is parking directly next to the
bicycle lane and if a parked car opening a door would intersect with the
marked bicycle lane, then the bicycle lane is within a door zone. Is it the
term that's the issue or the concept? Judging by the wikipedia page
https://en.wikipedia.org/wiki/Doored it seems like a fairly widespread term
globally.


>
> Maybe something like:
>
> cycleway:right=lane
> cycleway:right:lane=exclusive
> (cycleway:right:buffered=right/left/both/no)
> cycleway:right:buffered:right=yes/no/0.3(m)
>

The problem still exists that this doesn't say if you're at risk of being
doored https://en.wikipedia.org/wiki/Doored (eg no buffer, but also no
parking lane), so a specific tag like cycleway:lane:doorzone=yes/no/buffer
addresses that better in my opinion.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Jarek Piórkowski]

On Sun, 3 May 2020 at 08:16, Martin Koppenhoefer  wrote:
> > On 3. May 2020, at 13:06, Volker Schmidt  wrote:
> > When I see an elevation value on the ground I do not see any reference to 
> > the reference system, so I cannot know, as a mapper, what reference system 
> > is at the base of the informaton that I find on the ground. In that respect 
> > the proposal is not at all  from a practical perspective
>
> the idea is you do not even have to know, simply copy the value from the sign.

What happens when the sign is replaced or removed?

You might want to change the wiki description to be much more explicit
that this is only what is given on a sign and not a "regionally common
reference system".

--Jarek

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

Re: [Tagging] Doorzone bicycle lanes

[Hubert87]

I like the idea of using "buffered".

"doorzone" to me, is a pretty laoded and subjective.

Maybe something like:

cycleway:right=lane
cycleway:right:lane=exclusive
(cycleway:right:buffered=right/left/both/no)
cycleway:right:buffered:right=yes/no/0.3(m)

Yours
Hubert87

Am 03.05.2020 um 10:55 schrieb Jan Michel:

Hi,
I oppose adding this officially to the top-level cycleway:lane tag.
I see this information as one more property of the cycleway, like
surface, smoothness, width and so on.

We already have a documented key 'cycleway:buffer' that is described
as the width of the buffer space between car lanes and the bicycle lane.
The 'cycleway:buffer' tag is also used combined with :left and :right
to denote the buffer on left-hand and right-hand side of the cycleway.

Mappers in Berlin worked on a more detailed tagging of buffer and
protection of bicycle lanes, see (unfortunately in German only)
https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege

I'd suggest to get in contact with them and discuss this. I imagine that
this information could fit very well into the cycleway:buffer tag - A
door zone is a non-existent buffer, so instead of 'no' one could use
'doorzone' as one of the non-numeric values.

Jan



On 03.05.20 08:37, Andrew Harvey wrote:

For a while myself and others have been using cycleway:lane=doorzone
to say the bicycle lane is in a doorzone, I've now added
documentation of this as "in use" at
https://wiki.openstreetmap.org/wiki/Key:cycleway:lane. However this
conflicts with the other "in use" cycleway:lane=exclusive/advisory,
since you can have exclusive/advisory lanes which are doorzone or not.

None of these have gone through a proposal process and both are
independently in use.



___
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 ele:regional

[Martin Koppenhoefer]

sent from a phone

>> On 3. May 2020, at 12:51, Andrew Harvey  wrote:
> There is an EPSG code https://spatialreference.org/ref/epsg/5711/ for the 
> datum, perhaps ele:epsg:5711= is better then.


A system like this would probably be ignored by 85-98% of our mappers, although 
I would encourage to use it if you know this.

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

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

sent from a phone

> On 3. May 2020, at 13:06, Volker Schmidt  wrote:
> 
> When I see an elevation value on the ground I do not see any reference to the 
> reference system, so I cannot know, as a mapper, what reference system is at 
> the base of the informaton that I find on the ground. In that respect the 
> proposal is not at all clear from a practical perspective


the idea is you do not even have to know, simply copy the value from the sign. 

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

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-03 13:05, Volker Schmidt wrote:

> Martin 
> I am not an expert, but it looks as if the Wiki page Key:ele [1] is not 
> up-to-date. 
> I thought that WGS84 uses the EGM96 Geoid, named "WGS84 EGM96 Geoid".  Hence 
> there should be no difference between WGS84 and EGM96 elevations. 
> 
> Also it would be helpful, f you could give examples of local elevation 
> systems which would need explicit tagging. 
> When I see an elevation value on the ground I do not see any reference to the 
> reference system, so I cannot know, as a mapper, what reference system is at 
> the base of the informaton that I find on the ground. In that respect the 
> proposal is not at all clear from a practical perspective.

I think most countries with a coastline commonly use "sea level" as the
vertical basis. The definition of "sea level" differs from country to
country of course. NL uses "NAP" (Normaal Amsterdams Peil; normal
Amsterdam level) whereas Belgium uses "TAW" (Tweede Algemene
Waterpassing; second general water-levelling) as its basis. The
difference is 2.33m, which might not be so important for the heights of
mountains but along the coast it is critical for the correct
understanding of water depths, tides etc. The Westerschelde estuary
flows through NL until just before it reaches Antwerp (Belgium). To
avoid expensive misunderstandings it is essential that all bathymetric
data, tidal data, bridge heights etc be very clearly labelled with their
datum. 

  

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Key:ele___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Volker Schmidt]

Martin
I am not an expert, but it looks as if the Wiki page Key:ele
 is not up-to-date.
I thought that WGS84 uses the EGM96 Geoid, named "WGS84 EGM96 Geoid".
Hence there should be no difference between WGS84 and EGM96 elevations.

Also it would be helpful, f you could give examples of local elevation
systems which would need explicit tagging.
When I see an elevation value on the ground I do not see any reference to
the reference system, so I cannot know, as a mapper, what reference system
is at the base of the informaton that I find on the ground. In that respect
the proposal is not at all clear from a practical perspective.

Yours confused
Volker

On Sun, 3 May 2020 at 12:06, Martin Koppenhoefer 
wrote:

> I’m asking for comments on
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional
>
> Cheers Martin
>
> sent from a phone
> ___
> 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 ele:regional

[Andrew Harvey]

I'm all for specifying elevation of mountain peaks etc in other datum which
may work better than WGS:84.

I think it's better to specify which datum the value is in, it'll be a
nightmare over time working out which datum the original mapper intended as
new datums are rolled out and are upgraded, and leaves confusion if there
are multiple datum in use.

ele:=value

Where  is the height datum.

Next question is then how to specify , in Australia we commonly use
https://www.ga.gov.au/scientific-topics/positioning-navigation/geodesy/ahdgm/ahd,
so could use ele:ahd but that probably collides with other anachronisms
globally so is not ideal. There is an EPSG code
https://spatialreference.org/ref/epsg/5711/ for the datum, perhaps
ele:epsg:5711= is better then.

I'm not sure if there are any issues legally using EPSG codes, but presume
it's okay.

On Sun, 3 May 2020 at 20:06, Martin Koppenhoefer 
wrote:

> I’m asking for comments on
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional
>
> Cheers Martin
>
> sent from a phone
> ___
> 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] Doorzone bicycle lanes

[Jan Michel]

Hi Florimond,

On 03.05.20 11:04, Florimond Berthoux wrote:

And I'd say yes also for :
cycleway:lane:exclusive
In which case is this tag needed? A cycleway=lane shouldn't be shared 
with anybody else, and we already have values for shared lanes, e.g.

share_busway or shared_lane.


cycleway:lane:width
cycleway:lane:color


Why do you want to add the ':lane' part into the tags?
The keys without it are already in widespread use:
cycleway:width, cycleway:[left|right|both]:width
cycleway:colour, cycleway:[left|right|both]:colour
(also note the BE spelling 'colour')

Jan



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

[Tagging] RFC ele:regional

[Martin Koppenhoefer]

I’m asking for comments on 
https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional

Cheers Martin 

sent from a phone___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Doorzone bicycle lanes

[Robert Skedgell]

On 03/05/2020 07:37, Andrew Harvey wrote:
> For a while myself and others have been using cycleway:lane=doorzone to
> say the bicycle lane is in a doorzone, I've now added documentation of
> this as "in use"
> at https://wiki.openstreetmap.org/wiki/Key:cycleway:lane. However this
> conflicts with the other "in use" cycleway:lane=exclusive/advisory,
> since you can have exclusive/advisory lanes which are doorzone or not.
> 
> None of these have gone through a proposal process and both are
> independently in use.
> 
> Given cycleway:lane=exclusive/advisory have more use than doorzone, I
> think we should put cycleway:lane=exclusive/advisory through the formal
> proposal process and then change how we map doorzones as
> cycleway:lane:doorzone=yes so it can work together with exclusive/advisory.
> 
> Any other opinions?
> 
> Also on https://wiki.openstreetmap.org/wiki/Key:cycleway:lane there is
> cycleway=shared_lane + cycleway:lane=pictogram, should this not be
> cycleway:shared_lane=pictogram?
> 
> Given https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dshared_lane is
> already defined as "Used to identify roads which contain a shared lane
> marking, or sharrow, to indicate that the travel lane is shared by
> bicycles and other vehicles." what does the =pictogram tag mean and how
> is it different to cycleway=shared_lane?

Once a consensus has been arrived at for tagging the cycle lane itself,
would it also be worth suggesting in the wiki that the tag(s) be used in
conjunction with parking:lane:*=parallel (
https://wiki.openstreetmap.org/wiki/Key:parking:lane )?

As a separate issue, there are advisory cycle lanes combined with a
single yellow line parking restriction, where there is a usable lane at
the times when parking is prohibited, but effectively no cycle lane when
parking is permitted (sometimes with a doorzone risk on the carriageway).

-- 
Robert Skedgell (rskedgell)

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

Re: [Tagging] Doorzone bicycle lanes

[Andrew Harvey]

On Sun, 3 May 2020 at 18:56, Jan Michel  wrote:

> Hi,
> I oppose adding this officially to the top-level cycleway:lane tag.
> I see this information as one more property of the cycleway, like
> surface, smoothness, width and so on.
>
> We already have a documented key 'cycleway:buffer' that is described
> as the width of the buffer space between car lanes and the bicycle lane.
> The 'cycleway:buffer' tag is also used combined with :left and :right to
> denote the buffer on left-hand and right-hand side of the cycleway.
>
> Mappers in Berlin worked on a more detailed tagging of buffer and
> protection of bicycle lanes, see (unfortunately in German only)
> https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege
>
> I'd suggest to get in contact with them and discuss this. I imagine that
> this information could fit very well into the cycleway:buffer tag - A
> door zone is a non-existent buffer, so instead of 'no' one could use
> 'doorzone' as one of the non-numeric values.


I didn't know about cycleway:buffer, it sounds good but I don't think alone
it is enough because:

- It doesn't indicate if cars can be parked next to the cyclelane (as a
doorzone only occurs when there are parked cars). I know we can marked a
parking lane with parking:lane:parallel but I think it's better to have an
explict way to say the cyclelane is in a doorzone.
- Can be hard to measure distances and hence hard to say at what distance
is considered in the door zone or not. In all the examples I know of there
is no buffer so cycleway:buffer:left=no (for left hand side driving) but a
half meter buffer might still be considered within the doorzone.

The current wiki page for cycleway:buffer implies cycleway:buffer is
between the cyclelane and traffic lane, it feels safer to never use
cycleway:buffer and instead always explicitly state cycleway:buffer:left
and cycleway:buffer:right, but it does get complicated with counterflow
cyclelanes.


On Sun, 3 May 2020 at 19:05, Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> I think sub properties of a feature should go with this scheme
> mainfeature:subpropertie=values(yes/no/enumeration/absolute values/...)
> This help to respect orthogonality : values of a key should not conflict
>

Agreed


> So yes for :
> cycleway:lane:doorzone=yes/no/buffered
> buffered for the case there is a buffer marked between car park lane and
> cycle lane like this :
> https://cyclingsavvy.org/wp-content/uploads/2018/08/BikeLaneBuffer.jpg
> no means that the cyclelane is wide enough to not be doored (no buffer
> though).
>

That sounds good, except I think cycleway:lane:doorzone=no should mean that
no part of the cyclelane is within the doorzone or there is no car parking
and hence safe from doorzoning. cycleway:lane:doorzone=yes means that any
part of the cyclelane is prone to doorzoning and
cycleway:lane:doorzone=buffered means that there is a buffer to protect
from doorzoning, so while mostly you'll be safe from doorzoning you might
still want to exercise some caution.

I think this then can work in combination with cycleway:buffer:left and
cycleway:buffer:right.


>
> And I'd say yes also for :
> cycleway:lane:exclusive
> cycleway:lane:width
> cycleway:lane:color
> etc.
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Doorzone bicycle lanes

[Florimond Berthoux]

Hi,

I'm happy to see that doorzone tag is used, I think it's a good way to
evaluate bad cycle infrastructure.

Le dim. 3 mai 2020 à 10:52, Andrew Harvey  a
écrit :

>
>
> On Sun, 3 May 2020 at 18:17, Martin Koppenhoefer 
> wrote:
>
>> I am not completely sure, if I get this right, do you mean the area where
>> a door that is opened, would intersect with the space of a cycle lane?
>>
>
> Exactly, see also https://en.wikipedia.org/wiki/Dooring. Personally when
> riding I use the cycle lane as a buffer between parked cars and just ride
> outside of the cycle lane. There's been cases of mappers removing the
> cycleway=lane tag saying it's unsafe due to the doorzone, but that's wrong
> since there is a cycle lane there, so a dedicated tag would help
> alleviate this.
>
>
>> Maybe this could be tagged as a “hazard”, i.e. a property, rather than
>> forming a subtype of cyclelanes?
>> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>>
>
> That's an interesting idea. They key to note is that this is not usually a
> signposted hazard rather comes about due to the position of a parallel
> parking lane next to the cycle lane.
>
> cycleway:hazard=doorzone could apply. Though there could be other kinds of
> hazards which apply as well and it's unclear how that would work. I still
> would learn towards cycleway:lane:doorzone=yes as being my preferred option
> though, since you can tag =no as well.
>

I think sub properties of a feature should go with this scheme
mainfeature:subpropertie=values(yes/no/enumeration/absolute values/...)
This help to respect orthogonality : values of a key should not conflict

So yes for :
cycleway:lane:doorzone=yes/no/buffered
buffered for the case there is a buffer marked between car park lane and
cycle lane like this :
https://cyclingsavvy.org/wp-content/uploads/2018/08/BikeLaneBuffer.jpg
no means that the cyclelane is wide enough to not be doored (no buffer
though).

And I'd say yes also for :
cycleway:lane:exclusive
cycleway:lane:width
cycleway:lane:color
etc.

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


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

Re: [Tagging] Doorzone bicycle lanes

[Jan Michel]

Hi,
I oppose adding this officially to the top-level cycleway:lane tag.
I see this information as one more property of the cycleway, like
surface, smoothness, width and so on.

We already have a documented key 'cycleway:buffer' that is described
as the width of the buffer space between car lanes and the bicycle lane.
The 'cycleway:buffer' tag is also used combined with :left and :right to 
denote the buffer on left-hand and right-hand side of the cycleway.


Mappers in Berlin worked on a more detailed tagging of buffer and 
protection of bicycle lanes, see (unfortunately in German only)

https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege

I'd suggest to get in contact with them and discuss this. I imagine that
this information could fit very well into the cycleway:buffer tag - A 
door zone is a non-existent buffer, so instead of 'no' one could use

'doorzone' as one of the non-numeric values.

Jan



On 03.05.20 08:37, Andrew Harvey wrote:
For a while myself and others have been using cycleway:lane=doorzone to 
say the bicycle lane is in a doorzone, I've now added documentation of 
this as "in use" at 
https://wiki.openstreetmap.org/wiki/Key:cycleway:lane. However this 
conflicts with the other "in use" cycleway:lane=exclusive/advisory, 
since you can have exclusive/advisory lanes which are doorzone or not.


None of these have gone through a proposal process and both are 
independently in use.



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

Re: [Tagging] Doorzone bicycle lanes

[Andrew Harvey]

On Sun, 3 May 2020 at 18:17, Martin Koppenhoefer 
wrote:

> I am not completely sure, if I get this right, do you mean the area where
> a door that is opened, would intersect with the space of a cycle lane?
>

Exactly, see also https://en.wikipedia.org/wiki/Dooring. Personally when
riding I use the cycle lane as a buffer between parked cars and just ride
outside of the cycle lane. There's been cases of mappers removing the
cycleway=lane tag saying it's unsafe due to the doorzone, but that's wrong
since there is a cycle lane there, so a dedicated tag would help
alleviate this.


> Maybe this could be tagged as a “hazard”, i.e. a property, rather than
> forming a subtype of cyclelanes?
> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>

That's an interesting idea. They key to note is that this is not usually a
signposted hazard rather comes about due to the position of a parallel
parking lane next to the cycle lane.

cycleway:hazard=doorzone could apply. Though there could be other kinds of
hazards which apply as well and it's unclear how that would work. I still
would learn towards cycleway:lane:doorzone=yes as being my preferred option
though, since you can tag =no as well.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Doorzone bicycle lanes

[Martin Koppenhoefer]

sent from a phone

> On 3. May 2020, at 08:39, Andrew Harvey  wrote:
> 
> For a while myself and others have been using cycleway:lane=doorzone to say 
> the bicycle lane is in a doorzone,


I am not completely sure, if I get this right, do you mean the area where a 
door that is opened, would intersect with the space of a cycle lane?

Maybe this could be tagged as a “hazard”, i.e. a property, rather than forming 
a subtype of cyclelanes?
https://wiki.openstreetmap.org/wiki/Proposed_features/hazard


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

[Tagging] Doorzone bicycle lanes

[Andrew Harvey]

For a while myself and others have been using cycleway:lane=doorzone to say
the bicycle lane is in a doorzone, I've now added documentation of this as
"in use" at https://wiki.openstreetmap.org/wiki/Key:cycleway:lane. However
this conflicts with the other "in use" cycleway:lane=exclusive/advisory,
since you can have exclusive/advisory lanes which are doorzone or not.

None of these have gone through a proposal process and both are
independently in use.

Given cycleway:lane=exclusive/advisory have more use than doorzone, I think
we should put cycleway:lane=exclusive/advisory through the formal proposal
process and then change how we map doorzones as cycleway:lane:doorzone=yes
so it can work together with exclusive/advisory.

Any other opinions?

Also on https://wiki.openstreetmap.org/wiki/Key:cycleway:lane there is
cycleway=shared_lane + cycleway:lane=pictogram, should this not be
cycleway:shared_lane=pictogram?

Given https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dshared_lane is
already defined as "Used to identify roads which contain a shared lane
marking, or sharrow, to indicate that the travel lane is shared by bicycles
and other vehicles." what does the =pictogram tag mean and how is it
different to cycleway=shared_lane?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging