Re: [Tagging] Proposal to change key:man_made to key:human_made

[Topographe Fou]

  Putting appart this 'man' vs 'human' debate...This reminds me a thinking I regularly have in minds: OSM shall have a way to tell all (registered) data users that "starting from /mm/dd following major change in the database will be applied following vote xxx from OSM community. Please see drawbacks, workarounds and recommandations for editors in wiki page www" . The idea would not be to trigger this mechanism every week but to be able to schedule few data scheme improvements in concertation with (and supervized by) a dedicated Working Group (DWG ? Or a contiunuous improvement wg ?). I think OSM already did it in the past and the wellspreading of its data shall not block us for improvements. Keys can be seen as arbitrary strings from a sw point of view but I think there is a benefit to have consistent keys, which may imply from time to time to review 10 years old tagging schemes. It can even simplify life of editors and data consumers.  LeTopographeFou   De: dieterdre...@gmail.comEnvoyé: 18 octobre 2020 11:09 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] Proposal to change key:man_made to key:human_made  Am So., 18. Okt. 2020 um 23:02 Uhr schrieb Graeme Fitzpatrick :On Sun, 18 Oct 2020 at 20:39, Rory McCann  wrote:*definitely* not something one does auomatically.But would it be so impossible? (Not suggesting that it should actually be done!) Couldn't a bot be set to simply find all cases of man_made=, regardless of what it is, & change them to human_made=, similar to using Find & Replace in a Word document?yes, technically it could be done with a bot or also without a bot, directly on the database, in seconds or less.And once we have done it, we could do it again and again, for all kinds of reasons.The problem is not the data at the origin, it is the system around the database.Cheers.Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] We should stop using hyphens to denote address ranges

[Topographe Fou]

  then why not using addr:interpolation=no to state that the hyphen in addr:housenumber does not define a range ? I think everyone would be happy and it will not break current tagging schema. QA tools would raise a warning if there is an hyphen and no addr:interpolation tag. Default rule might be that an hyphen denotes (or not... Or both... I don't care) a range. LeTopographeFou   De: tagging@openstreetmap.orgEnvoyé: 20 août 2020 6:35 PMÀ: andrew.harv...@gmail.comRépondre à: tagging@openstreetmap.orgCc: matkoni...@tutanota.com; tagging@openstreetmap.orgObjet: Re: [Tagging] We should stop using hyphens to denote address ranges  Aug 20, 2020, 15:50 by andrew.harv...@gmail.com:And it may be useful to have tag to mark "yes this is actually a single housenumber despitethat includes hyphen or something else that suggests range"  I would assume that to be the default, when there are multiple addresses best to mark them all out individually or use a linear way with the address at the start and end nodes and addr:interpolation on the line (as a first pass before mapping them out individually) But given that addr:housenumber=1-3  may represent either case it would be nice to be able to state this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (contact:phone)

[Topographe Fou]

  I totally agree. Soren and all others members don't disserve such comment. OSM is a project where everyone can submit its point of view and ask for voting. Even if some think they own the truth.Having said that I think the main topic has not been adressed. For me contact is a namespace. I would prefer a proposition to say "phone key is a shortcut of contact:phone. (Same for email and others)". As such, they shall be handled the same." . And make sure osm wikidata handle namespace schemas ? LeTopographeFou   De: luke.mar...@viacesi.frEnvoyé: 4 décembre 2019 5:52 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] Feature Proposal - RFC - (contact:phone)  
Hi there,


Disclaimer: 

-I don't have much experience with OSM.
-I find the proposition of unifying the usage quite logical. 

-Now that I've read some responses, I understand why the community could be against.


However:

I'm amazed at how harsh people are against Sören. He's been putting some time to help, and the reversal of the proposal made sense when considering the voters' explanations on the wiki page.



Reading a thread like this honestly won't encourage any participation from outsiders (myself included)
And I'm not speaking about the x-th response, the firsts were already aggressive.

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

Re: [Tagging] Tagging meadow orchards

[Topographe Fou]

  Oups, wrong key, 32 use of landuse=mixed, sorry. LeTopographeFou   De: letopographe...@gmail.comEnvoyé: 19 septembre 2019 12:53 PMÀ: tagging@openstreetmap.orgObjet: Re: [Tagging] Tagging meadow orchardsAnd what about something like:Landuse=mixed (0 use in taginfo)Landuse:orchard=yesLanduse:meadow=yes   I would prefer that compared to secondary_landuse as it is much more scalable and less conflict-prone.  LeTopographeFou   De:  joseph.eisenb...@gmail.comEnvoyé: 19 septembre 2019 10:47 AMÀ:  tagging@openstreetmap.orgRépondre à:  tagging@openstreetmap.orgObjet: Re: [Tagging] Tagging meadow orchards  Right. Silvopasture combines trees used for forestry with grass for grazing. That means that the trees are used to produce for forestry products: usually wood or timber, sometimes bark, sap, or other non-food products.Orchards produce food: usually fruits like bananas, coconuts or oranges, but also tea leaves, coffee beans, and fruits used for oil like olives and oil palms. (According to current osm usage)I think a new tag like secondary_landuse or landuse:secondary would be nice so we don’t needn’t tags for every common combination, but I’m ok with orchard=meadow_orchard since it is already in use.JosephOn Thu, Sep 19, 2019 at 4:43 PM Martin Koppenhoefer  wrote:Am Do., 19. Sept. 2019 um 09:18 Uhr schrieb Paul Allen :On Thu, 19 Sep 2019 at 00:33, Martin Koppenhoefer  wrote:I agree the term silvopasture is not a synonym for meadow orchards. A meadow orchard is specifically low density/sparse trees, while silvopasture indicates a forest/woodland, i.e. denser tree cover.Really?  I don't see anything in the Wikipedia article that specifies the tree cover is dense. I didn't write it was "dense", I wrote it was "denser", compared to a meadow orchard.  Infact, it says: "Integrating pasture into existing woodland presents challenges as well: 
the woodland likely needs to be thinned to increase light infiltration"  It also has pictures of several differentsilvopastures, none of which appear to have dense tree cover throughout. it is using the term "woodland". For meadow orchards, I would use the term "meadow" with trees on it. The term "silvo" also is about a "forest"/woods. Can you see the difference?  Also the meadow in meadow orchard can be used for either pasture or cutting the grass, while silvopasture implies pasture.The trees scattered throughout would make it more economic to put animals out to pasture on it than to mow it.  But maybe where you are people do things the least efficient way.  Even ifthat is the case, I doubt that would remain viable for much longer.BTW, we're probably fooling ourselves in many cases where we say a field is pasture ormeadow: it may change from year to year.places in southern Germany used for pasture are often in environments where (mechanically) cutting the grass is not feasible, due to steep terrain, or where mowing does not make a lot of sense because the soil is quite magre.My point was that "silvopasture" has different connotations, it is about (some kind of) forest with animals grazing below, while meadow orchards is about meadows with sparse (fruit) trees on them (or sparse orchards on a meadow, if you like to put it the other way round). Silvopasture requires pasture, meadow orchards don't.Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Tagging meadow orchards

[Topographe Fou]

  And what about something like:Landuse=mixed (0 use in taginfo)Landuse:orchard=yesLanduse:meadow=yes   I would prefer that compared to secondary_landuse as it is much more scalable and less conflict-prone.  LeTopographeFou   De: joseph.eisenb...@gmail.comEnvoyé: 19 septembre 2019 10:47 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] Tagging meadow orchards  Right. Silvopasture combines trees used for forestry with grass for grazing. That means that the trees are used to produce for forestry products: usually wood or timber, sometimes bark, sap, or other non-food products.Orchards produce food: usually fruits like bananas, coconuts or oranges, but also tea leaves, coffee beans, and fruits used for oil like olives and oil palms. (According to current osm usage)I think a new tag like secondary_landuse or landuse:secondary would be nice so we don’t needn’t tags for every common combination, but I’m ok with orchard=meadow_orchard since it is already in use.JosephOn Thu, Sep 19, 2019 at 4:43 PM Martin Koppenhoefer  wrote:Am Do., 19. Sept. 2019 um 09:18 Uhr schrieb Paul Allen :On Thu, 19 Sep 2019 at 00:33, Martin Koppenhoefer  wrote:I agree the term silvopasture is not a synonym for meadow orchards. A meadow orchard is specifically low density/sparse trees, while silvopasture indicates a forest/woodland, i.e. denser tree cover.Really?  I don't see anything in the Wikipedia article that specifies the tree cover is dense. I didn't write it was "dense", I wrote it was "denser", compared to a meadow orchard.  Infact, it says: "Integrating pasture into existing woodland presents challenges as well: 
the woodland likely needs to be thinned to increase light infiltration"  It also has pictures of several differentsilvopastures, none of which appear to have dense tree cover throughout. it is using the term "woodland". For meadow orchards, I would use the term "meadow" with trees on it. The term "silvo" also is about a "forest"/woods. Can you see the difference?  Also the meadow in meadow orchard can be used for either pasture or cutting the grass, while silvopasture implies pasture.The trees scattered throughout would make it more economic to put animals out to pasture on it than to mow it.  But maybe where you are people do things the least efficient way.  Even ifthat is the case, I doubt that would remain viable for much longer.BTW, we're probably fooling ourselves in many cases where we say a field is pasture ormeadow: it may change from year to year.places in southern Germany used for pasture are often in environments where (mechanically) cutting the grass is not feasible, due to steep terrain, or where mowing does not make a lot of sense because the soil is quite magre.My point was that "silvopasture" has different connotations, it is about (some kind of) forest with animals grazing below, while meadow orchards is about meadows with sparse (fruit) trees on them (or sparse orchards on a meadow, if you like to put it the other way round). Silvopasture requires pasture, meadow orchards don't.Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Specific tag for Satellite Dishes

[Topographe Fou]

 Look at this recent page:https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsatellite_dishNote that this tag is 'in use' and has few usage. You can make/revive a proposal in order to approve it (together with man_made=communication(s)_dish?) LeTopographeFou   De: enocks...@gmail.comEnvoyé: 29 juillet 2019 7:04 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgCc: t...@openstreetmap.org; talk...@openstreetmap.orgObjet: [Tagging] Specific tag for Satellite Dishes  Hello,Sorry for cross posting. I am looking for specific tags for Satellite Dish [1]. I haven't found anything near so far. May be am missing something, else it doesn't exist and might be useful to propose and come handy in some cases.Ever mapped something like this or any idea will be great. 1. https://www.wikidata.org/wiki/Q253843-- Best,-Enock
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] paid ferry - fee or toll tag

[Topographe Fou]

  For me, if none of those tags would already exist, I would say that toll is an infrastructure and shall be put where the toll is  (booths, gates, automatic systems...) whereas fee is an attribute which denote that this amenity/road/ferry is not free to use.But as of today both are used, so I keep toll for highways and fee for nearly all other things such as toilets, parking...If I would have to map a ferry road, I would probably be lost also.LeTopographeFou   De: 61sundow...@gmail.comEnvoyé: 19 juin 2019 12:21 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] paid ferry - fee or toll tag  On 19/06/19 18:24, Mateusz Konieczny
  wrote:

  
  Is there some reason to prefer
one of this two keys for tagging whatever ferry is a paid one?
  

What do the cross channel ferries have for UK to France? 

Ha. They don't have a tag on them to indicate that payment is
required. 
Not done on UK to Spain either...
Not for England to Isle of Man
Not for the Orkney ferries either

Toll for England to Ireland 


  
  
  I feel that toll tag is better
as it is part of road structure. 
  


The wiki says either toll or fee. So use what you like. 

  
  
  For recreational cruises fee
may fit better but tagging it as route=ferry is
  
  tagging for renderer anyway.
  
  
  
  As far as popularity in data
goes - both tags have at this moment basically the same
popularity.



  

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

Re: [Tagging] Other missing landform tags

[Topographe Fou]

Oups sorry, it was not your discussion on plateau/mesa, I mixed those 
discussions, my bad...

Whatever I still think summarizing a proposal would help for all those major 
geological features :)



LeTopographeFou


  Message original  



De: letopographe...@gmail.com
Envoyé: 19 avril 2019 9:08 AM
À: tagging@openstreetmap.org
Objet: Re: [Tagging] Other missing landform tags


Warin,

Now you start having some main feedbacks (see plateau/mesa/...), may I suggest 
you write a global proposal for missing geological features? In fact it is what 
you are doing in the mailing list but without formalism. But too many emails 
with too many threads to be able to follow and understand what is the proposal 
and what are other people thinkings for a low band-width user like me. I think 
we would win in efficiency with a good proposal and associated tags and 
pictures in order to go ahead and clarify/vote/reject what you have in mind.

That is my input on this topic for the moment, thank you in advance if you 
proceed this way :)

Yours,

LeTopographeFou


  Message original  



De: 61sundow...@gmail.com
Envoyé: 19 avril 2019 8:29 AM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: [Tagging] Other missing landform tags


Along with plateau the following look to be missing from the OSMwiki,
these may not be all..


Pass A depression or gap in a range of mountains or hills permitting
easier passage from one side to the other.


Point A raised mass of land that projects over a lower area (water or land).

Head/headland A comparatively high promontory of land projecting into
the sea with a steep face. An un-named head is usually described as a
‘Headland’ when a specific name is assigned, it becomes a ‘Head’.


Should these too be added to the wiki. There are navigational features
at least for some of us.



___
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] Other missing landform tags

[Topographe Fou]

Warin,

Now you start having some main feedbacks (see plateau/mesa/...), may I suggest 
you write a global proposal for missing geological features? In fact it is what 
you are doing in the mailing list but without formalism. But too many emails 
with too many threads to be able to follow and understand what is the proposal 
and what are other people thinkings for a low band-width user like me. I think 
we would win in efficiency with a good proposal and associated tags and 
pictures in order to go ahead and clarify/vote/reject what you have in mind.

That is my input on this topic for the moment, thank you in advance if you 
proceed this way :)

Yours,

LeTopographeFou


  Message original  



De: 61sundow...@gmail.com
Envoyé: 19 avril 2019 8:29 AM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: [Tagging] Other missing landform tags


Along with plateau the following look to be missing from the OSMwiki,
these may not be all..


Pass A depression or gap in a range of mountains or hills permitting
easier passage from one side to the other.


Point A raised mass of land that projects over a lower area (water or land).

Head/headland A comparatively high promontory of land projecting into
the sea with a steep face. An un-named head is usually described as a
‘Headland’ when a specific name is assigned, it becomes a ‘Head’.


Should these too be added to the wiki. There are navigational features
at least for some of us.



___
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] amenity=place_of_worship | Re: Mapping of indigenous sacred / ceremonial sites

[Topographe Fou]

 The signage should make the tag, not the opposite. I think it is one of the main rule here. Otherwise there will always be interpretations and personnal feelings.Access=adherents is a non-sens. You don't have to be a customer to enter a shop (you may become one, but only after you entered), same for most of the places of worship when you are not an "adherent" (which by the way is hard to prove/unprove in most cases).I think this discussion (on accessing places of worship) will never come to an end and don't see the need to set an access tag when there is no clear signage (which is usually the fact I think). In this case why not discussing of accessing shops (when you are not buying), railroad stations (when you are not yet a traveller or don't plan to travel but to buy a newspaper), parkings (when you are not going to park but to drop someone)...Let stick to the "sign" rule, it's far more simple and international.Yours,LeTopographeFou   De: matkoni...@tutanota.comEnvoyé: 3 avril 2019 12:25 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] amenity=place_of_worship | Re: Mapping of indigenous sacred / ceremonial sites  Apr 3, 2019, 11:26 AM by r...@technomancy.org:For controlling access, it depends on what sort of control there is.Most sacred sites ("churches") aren't tagged as `access=private` (eventhough they are). One would hope data consumers would take that as implied.Typical christian place of worship is access=permissive (at least in Europe).Though there are some that should be tagged access=permissive.There was discussion about tagging list about "religious based accessrestrictions" a few months ago (thread starts here:https://lists.openstreetmap.org/pipermail/tagging/2018-June/037649.html). There wasn't a clear winner.access=adherents seems to be one that is likely to work wellThe Greek tribe has an ancestral belief system ("Christianity") whichhas some sites they consider sacred, such as Mouth Athos (https://www.openstreetmap.org/relation/2135921 ). That's currentlytagged as a regular `admin_level=3` even though it has strict accesscontrol (only men are allowed there!).Note that Athos is quite unique - typical one will not getadmin_level. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] I have been tagging mosques wrong all along

[Topographe Fou]

Hi,

Personnaly I already use amenity=* for the whole plot/complex when it's clear 
it is not limited to a building. This apply to schools, hospitals and places of 
worship (not exhaustive list) in my way of tagging. I believe this is how 
schools and hospitals are suggested to be mapped and see no exception with 
places of worships. I don't see a need for religion-based way of tagging 
(amenity=place_of_worship schema shall be used the same for any religion).

So yes I agree with you that places of worship are not always limited to a 
building (same for a school, an hospital...).

Yours,

LeTopographeFou


  Message original  



De: j...@liotier.org
Envoyé: 23 mars 2019 3:13 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: [Tagging] I have been tagging mosques wrong all along


In the Sahelian Openstreetmap I enjoy tagging mosques because they are
prominent features, nice for navigation and easy to spot on orbital
imagery - for me it has definitely turned into a "gotta catch'em all"
game... And I'm not even Muslim !

The tagging scheme I had settled upon was amenity=place_of_worship +
religion=muslim (building=mosque if there is a main building) and
landuse=religious + religion=muslim for the plot.

I have learned from Muslims and confirmed in literature that this
tagging scheme is wrong: what I considered as the mosque itself is
merely the main prayer hall. The mosque is actually the whole complex
that I used to tag as landuse=religious.

So, here is my current position regarding the tagging of mosques:

Single building mosque, no change:
amenity=place_of_worship + religion=muslim + building=mosque

Mosque complex: tag the whole plot (often the perimeter is also
barrier=wall):
amenity=place_of_worship + religion=muslim

So, no landuse=religious anymore at all and no building=mosque for the
buildings inside a mosque complex (building=yes - or, for the
adventurous, multipart buildings with distinct minaret and dome)

Anyone else obsessed with mosques to give an opinion on this
clarification - is it correct ?


___
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] Green lanes (OT)

[Topographe Fou]

  I disagree with the fact that making things even more complex (with adding an "all_lane" ) will help to solve when there is already a well known use of lane schema. Imagine cases where bicycles lanes are between two same direction lanes (it sometimes happens with a turn right lane. There the bicycle lane is between the through lane and the turn right lane)Lot of tools are already able to check validity of lane schemas, adding one lane for bicycles (or other transportation means) will not hurt them as soon as all lane tags are in line. I think that moving from a "car sized" to a "whatever size" is not such a big step but would help a lot simplifying the model thanks to a slight change.LeTopographeFou   De: matkoni...@tutanota.comEnvoyé: 18 mars 2019 2:13 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] Green lanes (OT)  Mar 18, 2019, 12:48 AM by ba...@ursamundi.org:On Sun, Mar 17, 2019 at 5:33 PM Mateusz Konieczny  wrote:Note that bicycle only lanes are not included in lanes tag count (only full lanes are counted).Lets fix this error by omission already.  Not counting all lanes serves nobody. Redefining lanes tag from "count of full lanes" to "count of all lanes" while it isused 9 million times is also a poor idea.New tag like all_lanes or something similar would likely be a better idea.https://taginfo.openstreetmap.org//search?q=lanes
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Topographe Fou]

In absolute yes but be carefull: Some editors (like StreetComplete since some 
weeks or iD) might push one or the other schema without the user knowing which 
one is used in the background and sometimes without rationale why this one and 
not the other one on editor side (they implement ONE, they do not offer the 
choice to the user). And I suspect many of those data came from an editor input 
field vs a user which have typed the key and the value.

Yours,


LeTopographeFou


  Message original  



De: charlesmil...@free.fr
Envoyé: 15 mars 2019 9:25 AM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging 
scheme


Taginfo shows it is not the preferred method 979<3562

https://taginfo.openstreetmap.org/tags/cycleway%3Aleft%3Aoneway=-1

https://taginfo.openstreetmap.org/tags/cycleway%3Aleft=opposite_lane

*=opposite_lane is/was well understood as far as I know (I am regularly
"teaching" OSM using the bicycle wiki page as reference).

Why using two tags when one works well, when the value opposite_lane
exists and the interpretation is the same?

I can understand the more structured aspect but using the :oneway value
not to traduce the oneway but its direction is not clean for me. Why not
using something with backward and forward in this case?

Just my opinion but if "cycleway:left:oneway=-1" is officially preferred
I will use it and promote it.

Charles

On 15/03/2019 01:35, Hubert87 wrote:
> I also regard
>
> "cycleway:left=lane"
> "cycleway:left:oneway=-1"
>
> as the currently preferred method and have been mapping/tagging like
> this for a while now.
>
> Just my two cents
>
> Hubert87
>
>
> Am 15.03.2019 um 00:12 schrieb althio:
>> Discussed: maybe there
>> https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html
>> Decided : I don't know
>>
>>> Cmuelle introduces rather complex combinations of tags such as
>>> cycleway:left=lane + cycleway:left:oneway=-1, that should in his
>>> view be used instead of cycleway:left=opposite_lane.  Does anyone on
>>> this list know whether this change has been discussed anywhere, and
>>> where and when it has been decided that cycleway=opposite_lane is a
>>> "legacy tag" ? If so please point me at some references.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] start_date variants

[Topographe Fou]

  Agree on the purpose of Wikidata but many OSM features (such as buildings) does not have a Wikidata item (only major buildings have one, usually landmarks).I would rather say that as soon as an OSM item has a Wikidata attribute then a QA tool may suggest to move some other attributes in Wikidata where they would be better updated and served (start_date for instance). Otherwise those attributes would be fine if no Wikidata item is associated. The OSM wiki pages of such attributes (e.g. start_date) would suggest to put them in Wikidata if and only if an item already exists there.Yours,LeTopographeFou   De: sea...@gmail.comEnvoyé: 18 février 2019 9:43 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] start_date variants  On Tue, Feb 19, 2019 at 4:28 AM Richard  wrote:It would also be interesting to be able to tag the start of construction - often construction starts many years before the building is finshed: Airport BER in Berlin, Germany or La Sagrada Familia in Barcelona, Spain are famous examples. How to tag this? Maybe: construction:start_date?Any thoughts on this?

you could map what was there at any particular time but I think it is better to provide the link to Wikipedia. Ordinary users will ever look at OSM data close enough to find out this details.+1 (but link to Wikidata instead of [or in addition to] Wikipedia)Most OSM data users only care about what is located where. Very few OSM data users would be interested in historical information such as when a building, a basilica, or an airport began and finished its construction. The actual people who would be interested in such information would look elsewhere instead of OSM and I think Wikidata is an excellent place to document such rich types of information. For example, see the Wikidata item for the Sagrada Família: https://www.wikidata.org/wiki/Q48435
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Protected Areas with multiple award

[Topographe Fou]

Hi Emanuel,

I would first consider to put them under its Wikidata page (if any) with 
property P166. Personally I would not take time to enter awards on OSM but 
would link the OSM item to a Wikidata item and fill the Wikidata item with this 
kind of property.

Moreover looking on Taginfo I can't find a tag/key for this with more than 100 
use.

Yours,

LeTopographeFou


  Message original  



De: emanuelfreitassi...@gmail.com
Envoyé: 18 février 2019 7:46 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: [Tagging] Protected Areas with multiple award


I'm unsure how to tag two awards received by a specific protected area. Should 
it be something like protection_award=award1; award2?

Thanks in advance
___
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] Medicine Disposal

[Topographe Fou]

  Hi,Wiki suggests amenity=recycling + recycling:drugs=yes/nohttps://wiki.openstreetmap.org/wiki/Tag:amenity%3DrecyclingIf we choose to put it under 'waste' (instead of recycling) then I suggest to copy the recycling namespace schema and use waste:drugs= yes/no (or something similar) instead of creating something different for a similar use (i.e. waste=drugs).Yours,LeTopographeFou   De: cliff...@snowandsnow.usEnvoyé: 15 février 2019 1:50 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: [Tagging] Medicine Disposal  How should sites that offer drop box disposal for unneeded medicine be tagged? Typical locations would include pharmacys, clinics, hospitals, and law enforcement buildings. I've thought about using the tag amenity=waste + waste=medicineAny better suggestions?Thanks in advance,Clifford-- @osm_seattleosm_seattle.snowandsnow.usOpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of amenity=kindergarten operated by charitable operators and organisations

[Topographe Fou]

Personnaly I don't think I would map umbrella organisations... I would put 
operator and operator:wikidata and let Wikidata update partnerships between 
associations. It is not a property of the kindergarten, it is a property of the 
operator.

LeTopographeFou

  Message original  
De: t.pfei...@computer.org
Envoyé: 7 janvier 2019 11:14 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] Tagging of amenity=kindergarten operated by charitable 
operators and organisations

On 07.01.2019 19:08, Volker Schmidt wrote:
> if it is a religion related operator, I usually also add religion and 
>denomination tags, i.e. in
> your Caritas example it would be
> religion=christian
> denomination=catholic
> 
> 
> I would not be sure how to handle this:
> Are these "access" tags, in the sense that (in the example) the kindergarten 
> only accepts Roman 
> Catholic children, or is it only indicating the religious background of the 
> institution, but they 
> accept children with other religious backgrounds as well.

I have never considered the 'religion' tag as an access tag. Typically I can 
freely enter a PoW, and 
listen to the ceremony, without being a member of that community or believe in 
that religion.

Similarly, educational institutions in my scope mostly accept children with 
different background, in 
particular if the receive state funding. E.g. Ireland, the majority of the 
schools is operated by 
the catholic church, and as a recipient of public funding they have to accept 
everybody, equally.

Back to Konrad's question, any better ideas to tag the name of the operator's 
umbrella organisation?
I drafted:
> operator:umbrella=* would be more suitable, or more self-explanatory but 
> longer
> operator:umbrella_organisation=*

tom

___
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] Can OSM become a geospacial database?

[Topographe Fou]

  I don't see as many issues in your exemple... If École or Musée is part of the name, I don't see why we shall invent a truncated name. It's not because the type is part of the name that we shall remove it.Let's take a more famous example: 'Arc de Triomphe' is the name of a landmark in Paris but it is also an 'Arc' (Arch in English). Same for 'Tour Eiffel' (which is a Tour, i.e. a Tower, but also an antenna). I don't see any solution in renaming them Eiffel or Triomphe. Instead we use the name for the 'name' and add their types (a Tower, an arch, a landmark, an antenna...) in attributes.And if one needs to list all Lakes in a given country then you have your answer: If it is on a geological basis, then he will look for attributes others than 'name'. If it is on a 'per use' basis, i.e. he wants to know which water area is called lake no matter if it is really one or not, then he will look in the name considering all possible translations. If I live next to a place called 'Hudson Bay' then I put name='Hudson Bay' even if some may argue it may not be a Bay.Consequently I don't see a real issue there.YoursLeTopographeFou   De: yauge...@gmail.comEnvoyé: 5 décembre 2018 7:37 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] Can OSM become a geospacial database?  Martin,this is already the case. At least it should be like this, if you see places where the name tag is abused for descriptions you should fix it. I admit, it is not always possible to clearly tell which is the correct name, for some kind of things, not even in the real world.At least in OSM you can add alternative names, generically or with specific meaning (loc_name, short_name, etc.)The name tag is abused very often and systematically. Let's take at look at this spot in the centre of Parishttps://www.openstreetmap.org/#map=18/48.86138/2.36028You can see category names displayed everywhere there, e.g. musium, hotel, school (in French).As a result when you query OSM database for some category items you have to apply algorithms for clearing category names from the name field to get just proper names.Regards,Eugeneср, 5 дек. 2018 г. в 20:25, Martin Koppenhoefer :Am Mi., 5. Dez. 2018 um 16:50 Uhr schrieb Eugene Podshivalov :I invision the following solution here.* First of all, the "name" tag should containt proper name only.this is already the case. At least it should be like this, if you see places where the name tag is abused for descriptions you should fix it. I admit, it is not always possible to clearly tell which is the correct name, for some kind of things, not even in the real world.At least in OSM you can add alternative names, generically or with specific meaning (loc_name, short_name, etc.) * Secondly, introduce a new tag for the real life language specific category name. I know that "name:prefix/postfix" key was originally introduced for another purpose but it can be a candidate here as well. Note that in some languages the place of category name relative to the proper name matters.I agree this could make sense, I am doing it for places where you can eat with this tag and local values:https://taginfo.openstreetmap.org/keys/restaurant%3Atype%3Ait#valuesI would not expect it useful for any kind of things, but there are fields with cultural specialties where I agree that it would be hard to agree on detailed categories on a global level, and still it might not make sense outside of a specific cultural context anyway.Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Topographe Fou]

  Hi Leif,I would rather consider the ability to store a "GTFS API link" (or something similar) in transport relations. As soon as its stops are well referenced, then an app will have everything it needs with nearly no need from users to update them (and ability to automatically detect missing or extra stops for QA tools).YoursLeTopographeFou   De: 354...@gmail.comEnvoyé: 31 octobre 2018 1:26 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: [Tagging] Public Transport Timetables Proposal RFC  Hello everyone!I recently wrote up a proposal page for public transport schedule data.  This information would allow OpenStreetMap to store information about when or how often certain buses or trains arrive at a platform. https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedulesPlease feel free to look over the page and give feedback.  I am very open to changing the proposal, so let me know if you have any ideas for improvements to it.Thanks,Leif Rasmussen
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Topographe Fou]

Hi,

Your intent is to simplify but I don't understand how replacing one tag by 
three or more with different syntaxes key/value according to the type of 
transportation and their introduction in OSM can make things easier.

I share your view when you say that two schemas is too much to maintain but I 
would rather jump to the conclusion that it is PTv1 which should be dropped if 
we want to drop one as it has limitations. PTv2 is not that complexe, it is 
public transportation which are complexe to map.

One thing I never understood was why we have to maintain two schemas (probably 
because consensus was not reached). I guess this is the main reason why some 
people (especially new mappers) can be lost. And also why wiki can sometime say 
one thing or the opposite. I think it delayed the evolution of renderers and 
tools instead of pushing them to evolve with the schemas. I have the feeling 
that your analysis dropped those factors. Once the map on osm.org will render 
PTv2, I'm sure it will be a huge step and that all the work done will pay. 

Then I don't see where is the difficulty to map two different features instead 
of mapping a single approximate one. It means more work, right, but it adds 
more values to the project as a whole. And since nobody is forced to mapped 
everything on its own...

To conclude: I disagree with part of the analysis and with the whole conclusion.

Yours,

LeTopographeFou

  Message original  
De: i...@zverev.info
Envoyé: 28 mars 2018 3:54 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: [Tagging] Still RFC — Drop stop positions and platforms

Hi folks,

A while ago I've made a proposal to deprecate some public_transport=* tags:

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

The discussion was very slow, and in general mappers seemed to accept the 
change. I'd like to push this to voting in a few days, but first I want to know 
if somebody has anything to say about the proposal. Like, why we should not. 
I'd prefer to discuss that before the voting has started.

Ilya
___
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] Toll road sections

[Topographe Fou]

I'm not aware of other toll systems but official country references are tagged 
using the prefix ref:XX where XX is the country code. Note that HU represent 
the country and hu the language (see ISO codes). So your prefix would be ref:HU.

LeTopographeFou 

  Message original  
De: domotor.a...@itineris.hu
Envoyé: 28 août 2017 11:51 AM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: [Tagging] Toll road sections

Hi,

The road toll system for HGVs has sections in Hungary. There are appr. 
2400 of such sections in a varying length from 100 metres to 13 kms.
We'd like to tag roads with the corresponding toll ID. The base tag 
would be "edid" as the official files use this field name.
The question is how we should use it. As it's only Hungarian, a "hu:" or 
"hu:ref:" namespace prefix may be appropriate.
Furthermore, it's only for HGVs so inserting "hgv:" might be sensible as 
well.

Are there any other local toll systems that already use some tagging? We 
could use the same format/logic then.

Greets,
Ákos

___
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] Tagging attractions that are farms

[Topographe Fou]

Hi John,
Based on what you said I would tag this area as a farmyard (because it produces 
things) inside a probably bigger (because of parking, buildings...) regular 
theme park which contains everything else (visitor center, toilets, parking, 
shop...).

LeTopographeFou


  Message original  
De: jo...@mac.com
Envoyé: 2 juin 2017 10:48 AM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] Tagging attractions that are farms


The more I work on tagging this one singular named place, the more I realize I 
wish there was something like

tourism=attraction_centre, because there are several “points of interest” that 
are operated inside this place, and even an actual “attraction” (a raft ride to 
see the clear water).

How do people deal with a place that is a collection of attractions that isn’t 
a park or a disneyland theme park with rides?

Javbw


> On Jun 2, 2017, at 9:08 AM, John Willis  wrote:
> 
> I am trying to tag a regional attraction, and I am unsure how to tag the 
> attraction by itself.

___
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] Pennsylvania colored Interstate detour routes

[Topographe Fou]

  Well, I would use both ref AND colour.Then for the name what you propose looks good from my perspective.If you want to check or get some ideas you can also make some statistics with Overpass on how detours are commonly named.LeTopographeFouDe: roadsgu...@gmail.comEnvoyé: 30 mars 2017 6:19 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] Pennsylvania colored Interstate detour routes  So if I use, for example, colour=blue in the relation, rather than have ref=Blue, I would have "name=I XX Blue Detour"?--RoadsguyOn Thu, Mar 30, 2017 at 9:05 AM, Topographe Fou <letopographe...@gmail.com> wrote:  In your case I would probably also consider to add something like colour=green/yellow/... on the detour relation.LeTopographeFou   De: ba...@ursamundi.orgEnvoyé: 30 mars 2017 2:31 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] Pennsylvania colored Interstate detour routes  Check https://wiki.openstreetmap.org/wiki/Tag:route%3DdetourOn Tue, Mar 28, 2017 at 9:33 AM, Albert Pundt <roadsgu...@gmail.com> wrote:Is there an established way of mapping detour routes such as Pennsylvania's colored Interstate detours, as seen in this picture? I would think it would be as simple as using route relations with route=detour, ref=Green/Blue/Orange/etc, and detour=I 81/I 78/etc, but before I go and add these I want to know whether these should be mapped at all, and if so, what standard practice is.--Roadsguy
___
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] Pennsylvania colored Interstate detour routes

[Topographe Fou]

  In your case I would probably also consider to add something like colour=green/yellow/... on the detour relation.LeTopographeFouDe: ba...@ursamundi.orgEnvoyé: 30 mars 2017 2:31 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: Re: [Tagging] Pennsylvania colored Interstate detour routes  Check https://wiki.openstreetmap.org/wiki/Tag:route%3DdetourOn Tue, Mar 28, 2017 at 9:33 AM, Albert Pundt  wrote:Is there an established way of mapping detour routes such as Pennsylvania's colored Interstate detours, as seen in this picture? I would think it would be as simple as using route relations with route=detour, ref=Green/Blue/Orange/etc, and detour=I 81/I 78/etc, but before I go and add these I want to know whether these should be mapped at all, and if so, what standard practice is.--Roadsguy
___
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] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Topographe Fou]

It's a different topic: speed, height... Mainly apply to a way whereas stops 
mainly (always ?) apply to a node.

Speeds can still be tagged on the way and the sign put appart from the road, 
mainly for rendering purpose because the way it applies to is already tagged 
with the consequence (the speed).

In this thread I already proposed the same mechanism for stops, i.e. a node for 
the sign at it's exact location (for renderers) + a node on the way at the 
location where the car has to stop/halt/slow down (for routing engine). This 
way we can address both needs (routing engine are not the only data consumer ;) 
). What do you think?

LeTopographeFou 


  Message original  
De: dieterdre...@gmail.com
Envoyé: 23 mars 2017 9:05 PM
À: j...@liotier.org
Répondre à: tagging@openstreetmap.org
Cc: tagging@openstreetmap.org
Objet: Re: [Tagging] Traffic sign's relevant direction: direction=* vs. 
relation [Was: traffic_signals:direction=* vs. direction=*]

sent from a phone

> On 23 Mar 2017, at 17:23, Jean-Marc Liotier  wrote:
> 
> - highway=stop+direction=forward node on the incoming way... Only
>  covers the simple case but covers it simply

while this might work often with stop signs it'll hardly work with maxspeed 
signs, because the changing maxspeed requires to split the highway, so that 
there would be 2 highways ending in the same node and forward would not be 
clear of which way.

When I map traffic signs it's mostly city limit, maxspeed/maxweight/maxheight 
and I do it generally for fellow mappers (including myself) because the effect 
of the sign I will map on the highway (typically linear, not just a point). 
Mapping on the side of the road has worked out perfectly for this scope.

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

Re: [Tagging] The direction=* tag

[Topographe Fou]

Hi,

I put stops, give ways and traffic light where the car has to stop/yield which 
can be far from the position of the sign (for instance in the US where the 
light is after the junction, thus may not be crossed if you turn). Also on 
narrow junction you may have the lights at the junction but the stop line some 
meters before to let buses make there turn.

To match all use cases a new scheme has to consider the tagging of both 
stop/yield positions on the road and position of the sign/light (like for bus 
stops). One may think of relations as one explicit way of linking all those 
informations (like restricted turns). Any algorithm which try to deduce a 
position on a road from a position sign will be buggy at some points and greedy.

Then we have to consider that at some junctions the direction/orientation of 1. 
The way 2. The stop/yield line (if any) and 3. The sign/light may be three 
different values!

And yes, OSRM is not the only data consumer to look at (even if it is a good 
one :) ). I dream of a routing app which would warn me of stops/lights in front 
of me or say "At the stop, turn right" instead of "Turn right" .

LeTopographeFou

  Message original  
De: t...@fitchdesign.com
Envoyé: 17 mars 2017 11:26 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] The direction=* tag

If micro mapping, then the stop sign is usually not in the center of the 
traveled way (though I have occasionally seen some there). For micro mapping, 
place a node for the sign where it exists on the side of the road and then use 
the compass direction to indicate how it is facing. As it is detached from the 
highway way forward and backward can have no meaning.

The “highway=stop | give_way” tag on a node on way might be used by map 
rendering, which probably doesn’t care if it has forward or backward tagging. 
I’ve been using Mapnik XML for rendering my maps and I don’t recall the ability 
to detect the direction of a way. Or even if something that is being rendered 
by the point symbolizer can tell if the point is on a way. I could be wrong on 
that. And even if wrong, maybe some rendering tool chain will support that in 
the future. But at present I am pretty sure that map rendering can’t use 
“direction=forward | backward”. It can (and my rendering does) use the compass 
points and/or degrees values for rotating icons in the point symbolizer.

I strongly suspect that tagging the stop/give way sign in the middle of the way 
is for the use of routing and route guidance. It might still be of use by 
guidance (though I am not sure the “direction=forward | backward” matters much 
in that case) but what I am hearing is that as implemented/specified now it is 
not useful for routing. Thus my comment about noise.

I have been following the tagging suggested on the wiki [1] and checking the 
direction of the way in order to determine the value to put on the direction 
tag is tedious. If it is not being used, I might well forgo the direction tag. 
Fortunately the same wiki page states direction is only needed if the signs are 
closely spaced and it is not obvious which intersection/direction the sign is 
for, so the direction tag in that case is almost always optional per my 
interpretation of the wiki.

Cheers!

[1] 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#Tagging_minor_road_stops

> On Mar 17, 2017, at 2:47 PM, yo paseopor  wrote:
> 
> I don't agree with this: marking the direction of the traffic sign is not 
> noise, for a driver can be VITAL, also with the meaning of the traffic sign 
> (the main purpose of a traffic sign).
> Why? Because in a way with two directions we need to know to what direction 
> traffic sign it is for. It is not the same a road cross with an STOP forward 
> than backward (with micromapping it is not the same one lamp than two)
> Put a key like direction is not the best option, because this information can 
> be inside the key itself like traffic_sign:forward or traffic_sign:backward.
> Also it is a good thing to say of what side of the way the traffic sign is.
> In some countries traffic sign of a side is not the same as the other side 
> specially in streets in a city.
> e.g.
> 
> traffic_sign:forward=ES:R2
> highway=stop
> side=right
> 
> Ok, OSMR do not use that...but other tools uses this information so it is 
> important to keep it at the data.
> In a short-term, people like Mapillary or OSC will give us the opportunity 
> (and the data) to map all the traffic signs in a way. Routers and navigation 
> apps should be prepared for that. OSM is nowadays capable of show all this 
> information. Don't make it disappear.
> 
> Salut i mapes (Health and maps)
> yopaseopor

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

Re: [Tagging] how to care about different seasonal road close?

[Topographe Fou]

I believe we still need one user somewhere to update the data each year... I 
suggest to have a scheduled bot which detect obsolete conditions value (based 
on actual date) and automatically create a note on the map like "Obsolete 
conditional access value, please update the feature" .

Otherwise as far as I know Maps.me does not use OSRM anymore since end of 2016. 
They changed to another routing engine (which leads to an amazingly long list 
of routing issues).

LeTopographeFou 


  Message original  
De: hak...@posteo.de
Envoyé: 16 mars 2017 3:03 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: [Tagging] how to care about different seasonal road close?

The road after this point (northwards) is closed in the winter season.

https://www.openstreetmap.org/note/917369#map=17/50.79221/15.32156

But like Petr says, its each year another time. I had the bad luck to
route through this street with maps.me because it is not tagged for
2017, OSRM seems to not care for the year and does not route there. But
graphhopper and mapzen does. And Maps.me, and because it is really a
dead end when you went up there by car its a long way backwards..

So, is there a solution how to deal with roads like this, where you know
that the road will be closed but you dont know the exact time? Because
like here, people will forget to tag it for each year.

___
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] The direction=* tag

[Topographe Fou]

  Hi,The second use should not be encouraged IMHO as it is redundant with the direction of the way.Reguarding the third use, you can use either traffic_signals:direction or direction but the first form will explicitly apply to the traffic_signals while the second may apply to different tags of the node. Imagine a node which is tagged as a traffic light (or a stop) and a crossing or a camera. To which one the direction apply if you don't specify it? If the second form is used, then it applies to all tags which may be associated to a direction. This is how I understand and use it.From my understanding stops, give ways and traffic lights can be mapped the same way but editors (JOSM, iD) have implemented presets for those features at different point in time without feeling the need for consistency. I know that iD is currently doing the job of having a consistent behavior for those three features and that they might prefer (traffic_signals|stop|give_way):direction instead of direction (to be confirmed). They are also working to display the direction on the node on the map.LeTopographeFouDe: t...@fitchdesign.comEnvoyé: 16 mars 2017 5:15 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: [Tagging] The direction=* tag  The “direction” tag [1] has different uses that seem disjoint to me.To specify the orientation (compass point or degrees from north) of an object (adit or cave entrance, etc.). To specify direction (clockwise/counterclockwise) around a roundabout (not sure why this is needed as it should be apparent from local laws or specified with a “_oneway_=yes”).To indicate the direction (forward/backward) a stop or yield (give way) sign has effect along a way.Oddly, that third use seems only for stop and yield signs but not for traffic signals where a “traffic_signals:direction=forward | backward” tag is to be used. However that seems to be the most used form [2]. Apparently some have figured that if we have “traffic_signals:direction” there should be “stop:direction” [3] and “give_way:direction” [4] tags.And other things where a direction like tag might be used, like roof aspect have their own tags (“roof:direction=*”) [5] which follow the syntax and semantics of the first definition of the “direction=*” tag.It seems to me that the first and the third definitions should be split into separate tags with the second definition deprecated.From a data consumer point of view, there may not be a conflict as map rendering is likely to only use the bearing definition while routing would use the forward/backward definition. Though I suppose that a really detailed map may wish to show the actual angle of a stop or yield sign as they are not necessarily exactly aligned with the traveled way. From a mapper’s point of view having totally different  meanings for a tag based on context seems confusing.Since the “forward” and “backward” values are most used, it may be reasonable to keep the third definition of that tag even though it is inconsistent with “traffic_signals:direction”.Should we come up with a new tag to replace the angle/aspect meaning of the “direction=*” tag? If so, what tag name would make sense.“Bearing” (some uses which seem to follow the first definition of “direction”) [6]“Aspect” a couple of instances in use but not clear to me what was intended. [7][8]Thoughts?[1] https://wiki.openstreetmap.org/wiki/Key:direction[2] https://taginfo.openstreetmap.org/keys/direction#values[3] https://taginfo.openstreetmap.org/keys/stop%3Adirection[4] https://taginfo.openstreetmap.org/keys/give_way%3Adirection[5] https://wiki.openstreetmap.org/wiki/Key:roof:direction[6] https://taginfo.openstreetmap.org/keys/bearing#values[7] https://taginfo.openstreetmap.org/keys/Aspect#values[8] https://taginfo.openstreetmap.org/keys/aspect#values___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes=3 + lanes:forward/backward=1 for "semi-divided" roads?

[Topographe Fou]

For your interest and according to Taginfo:

access:lanes > 4269 use
access:lanes:both_ways > 726 use
access:lanes:both_ways=no > 695 use (+ 24 use of value "no|no" )

Used mainly in central North America and Germany.

Yours, 

LeTopographeFou


  Message original  
De: letopographe...@gmail.com
Envoyé: 12 février 2017 12:47 PM
À: tagging@openstreetmap.org
Objet: Re: [Tagging] lanes=3 + lanes:forward/backward=1 for "semi-divided" 
roads?

Marc, it looks like you propose to tag it as a lane which can be used to turn 
which is not what Roadsguy wants to do (if I get it right...).

If the central line can't be used but exists I would put

lanes:both_ways=1
access:lanes:both_ways=no

LeTopographeFou 

  Message original  
De: marc.ge...@gmail.com
Envoyé: 12 février 2017 7:40 AM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] lanes=3 + lanes:forward/backward=1 for "semi-divided" 
roads?

You could add lanes:both_ways=1 turn:lanes:both_ways=left

regards

m

On Sun, Feb 12, 2017 at 5:39 AM, Albert Pundt  wrote:
> Consider High Street in downtown Carlisle, PA. It is one lane each way, with
> a wide space as wide as a travel lane in the middle, but not used for
> anything such as a center turning lane. Tagging this with just lanes=2 seems
> wrong since it fails to take into account the lane width separating the two
> travel lanes, and since there is no raised physical divider, it doesn't seem
> right to mark it as a dual-carriageway road either. I've seen lanes=3 used
> along with lanes:forward=1 and lanes:backward=1, but that seems like it
> might be confusing.
>
> What, if anything, is the proper way to tag roads like this?
>
> --Roadsguy
>
> ___
> 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] lanes=3 + lanes:forward/backward=1 for "semi-divided" roads?

[Topographe Fou]

Marc, it looks like you propose to tag it as a lane which can be used to turn 
which is not what Roadsguy wants to do (if I get it right...).

If the central line can't be used but exists I would put

lanes:both_ways=1
access:lanes:both_ways=no

LeTopographeFou 


  Message original  
De: marc.ge...@gmail.com
Envoyé: 12 février 2017 7:40 AM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] lanes=3 + lanes:forward/backward=1 for "semi-divided" 
roads?

You could add lanes:both_ways=1 turn:lanes:both_ways=left

regards

m

On Sun, Feb 12, 2017 at 5:39 AM, Albert Pundt  wrote:
> Consider High Street in downtown Carlisle, PA. It is one lane each way, with
> a wide space as wide as a travel lane in the middle, but not used for
> anything such as a center turning lane. Tagging this with just lanes=2 seems
> wrong since it fails to take into account the lane width separating the two
> travel lanes, and since there is no raised physical divider, it doesn't seem
> right to mark it as a dual-carriageway road either. I've seen lanes=3 used
> along with lanes:forward=1 and lanes:backward=1, but that seems like it
> might be confusing.
>
> What, if anything, is the proper way to tag roads like this?
>
> --Roadsguy
>
> ___
> 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] Harmonising source tag values.

[Topographe Fou]

  Hi,One interest to do it may be to reduce the volume of the database by improving compression, improve indexing of the values, simplify queries by reducing the need for a request to handle variations of case in a value, simplify statistics by reducing post-analysis... for me there is an added value from a theory point of view.But you're right that in a practical POV the better would be that the editors helps in this work by improving consistency at the begining otherwise it's an endless work. Source:date might be automatically proposed at the creation of a source tag for instance.I'm of those who try to harmonize the values on different tags when it can be done  (and there is an agreement on a close list of values) and I might work on source one day (even if today it's an open field).Then, as a trademark, because "Bing" is the official way to write it, then I vote to write it this way and not in another way.Yours, LeTopographeFou   De: daveswarth...@gmail.comEnvoyé: 8 février 2017 5:49 AMÀ: tagging@openstreetmap.orgRépondre à: daveswarth...@gmail.com; tagging@openstreetmap.orgObjet: Re: [Tagging] Harmonising source tag values.  Not really. Although such a move appeals to my sense of orderliness and my background in database design. All these weird variations in tag values drive me a little bit crazy but normalizing them is a lot of work that will soon be undermined by people using new free-form source tags anyhow. By the way, I use source=Bing with a capital B.On Wed, Feb 8, 2017 at 8:47 AM, Warin <61sundow...@gmail.com> wrote:
  


  
  


Hi,
  
  
  
  One mapper has taken on themselves to 'harmonise' some local
  source tag values.
  
  
  
  There are many more that could be done along the same lines .. the
  major example would be Bing, bing, BING, bing  and bing 
  mm (where  is the numerical year and mm is the numerical
  month).
  
  
  These could all be harmonised to source=Bing (the a majority of
  tags carry this) with source:date= mm as appropriate.
  
  
  But I would see no point in it. I think people will continue to
  use there present source tagging practices ... I use lower case
  bing for example and see no real reason to change.
  
  
  
  
  Are there any who see advantages to this 'harmonisation' ?
  
  
  
  
  

  

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
-- Dave SwarthoutHomer, AlaskaChiang Mai, ThailandTravel Blog at http://dswarthout.blogspot.com

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

Re: [Tagging] Railway=station + area=yes questions:

[Topographe Fou]

  Hi,I know that some consider the wiki as a not-trustable thing but when I read the dedicated page there is a third POV which makes more sense for me and which may explain why you add an extra area tag.http://wiki.openstreetmap.org/wiki/Tag:railway%3DstationTo summarize quickly: It says that railway=station should only be a node (not an shape or a polygon or even an area) and that you should use landuse=railway and building=* to represent the physical infrastructure in other objects.Whatever we think about this page, I agree with you that railway=station does not imply that it is a building.YoursLeTopographeFou   De: jo...@mac.comEnvoyé: 1 octobre 2016 6:52 PMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: [Tagging] Railway=station + area=yes questions:  I have a long thread over at The -carto page trying to describe unexpected behavior of the rendering of railway=station on an area when also accompanied with area=yes. I expect that to tell the -carto renderer that I am saying this is the "area" of the station and building=train_station to be the building. https://github.com/gravitystorm/openstreetmap-carto/issues/327#issuecomment-250489455I am used to mapping all building complexes in a certain way (which is standardized for some complex types and not others). - Outline the defined area of the location with Landuse=* , or a similar tag (like an airport or school). This includes the area for amenities that belong to the location (parking lots, lawns, roads, whatever is inside its fence) - Define buildings using the building=* tag - Add amenities as areas, ways, and points on the Landuse. So I expect there to be a similar system to map stations, as the amenities directly operated by the station (bus circles, pedestrian promenades, parking, separated station buildings and platforms, servicing facilities) to be part of the "station". Defining that area is very useful, especially when their shape is visually useful and access via other routes is restricted. So as other tags have different behavior on a pin vs a building vs a non-building, I expected the renderings of railway=station to be different when the area=yes tag is present . Am I incorrect in expecting this behavior?  Javbw. ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging