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

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

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

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

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

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

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

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

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

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

Re: [Tagging] Doorzone bicycle lanes

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

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

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,

Re: [Tagging] RFC ele:regional

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

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

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

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

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

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

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

Re: [Tagging] Doorzone bicycle lanes

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

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

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 :

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

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?

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

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

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

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

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

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

[Tagging] Doorzone bicycle lanes

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,

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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.

[Tagging] RFC ele:regional

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] RFC ele:regional

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,

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] RFC ele:regional

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

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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,

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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

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

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

Re: [Tagging] Doorzone bicycle lanes

(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