Re: [OSM-talk] Planned rendering changes of protected areas
On Thu, Nov 30, 2017 at 9:38 PM, Eugene Alvin Villar wrote: > On Fri, Dec 1, 2017 at 8:58 AM, Paul Johnson wrote: > >> On Thu, Nov 30, 2017 at 6:05 PM, ajt1...@gmail.com >> wrote: >> >>> On 30/11/2017 13:46, Daniel Koć wrote: >>> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new scheme) are frequently tagged in parallel, and it looks like the old scheme is used as a hack just to make it visible on default map. >>> >>> Just to chuck one example in - I've tagged lots of >>> "leisure=nature_reserve" and almost no "boundary=protected_area; >>> protect_class=XYZ". The reason is simple - nature reserves where I'm >>> likely to be mapping often have a sign saying "XYZ nature reserve". There >>> isn't going to be a sign helping me work out what "protect_class" in OSM it >>> is, so that doesn't get mapped. It's also nothing to do with "what gets >>> rendered"; I actually render my own maps and map quite a lot of stuff that >>> isn't displayed there :) >>> >> >> Seems like it wouldn't be too difficult to consider the two as equivalent. >> > > Not exactly. Some protected areas are cultural/social/heritage protected > areas. Specifically those tagged with protect_class=21 to 29. > I meant the specific protect_class tags referring to nature preserves specifically. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planned rendering changes of protected areas
On Fri, Dec 1, 2017 at 8:58 AM, Paul Johnson wrote: > On Thu, Nov 30, 2017 at 6:05 PM, ajt1...@gmail.com > wrote: > >> On 30/11/2017 13:46, Daniel Koć wrote: >> >>> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new >>> scheme) are frequently tagged in parallel, and it looks like the old scheme >>> is used as a hack just to make it visible on default map. >>> >> >> Just to chuck one example in - I've tagged lots of >> "leisure=nature_reserve" and almost no "boundary=protected_area; >> protect_class=XYZ". The reason is simple - nature reserves where I'm >> likely to be mapping often have a sign saying "XYZ nature reserve". There >> isn't going to be a sign helping me work out what "protect_class" in OSM it >> is, so that doesn't get mapped. It's also nothing to do with "what gets >> rendered"; I actually render my own maps and map quite a lot of stuff that >> isn't displayed there :) >> > > Seems like it wouldn't be too difficult to consider the two as equivalent. > Not exactly. Some protected areas are cultural/social/heritage protected areas. Specifically those tagged with protect_class=21 to 29. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Length of ways
On Thu, Nov 30, 2017 at 6:13 PM, Martin Koppenhoefer wrote: > I’m not sure if this is still valid, but a long time ago the measurements > in Josm weren’t very accurate... It uses the great circle distance[0], which is accurate to about 0.5%[1], still over long distances that can add up. I believe it would be more accurate to project each segment of the way to a local coordinate system and measure, and then sum the measures. Mike [0] https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/Way.java (search on getLength) [1] https://en.wikipedia.org/wiki/Great-circle_distance especially for long distances, where the curvature of the earth leads to > significant errors if not accounted for. Don’t know whether Josm uses an > ellipsoid or spheroid (I recall initially it used carthesian coordinates > and calculated in a plane). Just wanted to mention it. > > There’s also a measurement plugin for josm. > > cheers, > Martin > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Length of ways
I’m not sure if this is still valid, but a long time ago the measurements in Josm weren’t very accurate, especially for long distances, where the curvature of the earth leads to significant errors if not accounted for. Don’t know whether Josm uses an ellipsoid or spheroid (I recall initially it used carthesian coordinates and calculated in a plane). Just wanted to mention it. There’s also a measurement plugin for josm. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planned rendering changes of protected areas
On Thu, Nov 30, 2017 at 6:05 PM, ajt1...@gmail.com wrote: > On 30/11/2017 13:46, Daniel Koć wrote: > >> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new >> scheme) are frequently tagged in parallel, and it looks like the old scheme >> is used as a hack just to make it visible on default map. >> > > Just to chuck one example in - I've tagged lots of > "leisure=nature_reserve" and almost no "boundary=protected_area; > protect_class=XYZ". The reason is simple - nature reserves where I'm > likely to be mapping often have a sign saying "XYZ nature reserve". There > isn't going to be a sign helping me work out what "protect_class" in OSM it > is, so that doesn't get mapped. It's also nothing to do with "what gets > rendered"; I actually render my own maps and map quite a lot of stuff that > isn't displayed there :) > Seems like it wouldn't be too difficult to consider the two as equivalent. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planned rendering changes of protected areas
sent from a phone On 30. Nov 2017, at 23:09, Daniel Koć wrote: >> There are 62k uses of boundary=protected_area and 77k of >> leisure=nature_reserve and 31k of the combination - which does not >> really support your idea that the latter is used just as a hack. > > How would you detect such a hack then? > > In my opinion 31k is a serious amount (about a half of both) that is a strong > suggestion of the problem, at least. there is no problem with 2 different tags fitting for the same kind of thing. These are also different in scope, leisure=nature_reserve is for all kind of natural protected areas, while boundary=protected_area is for all kind of protected areas. It appears to be very detailed at first glance, but if you look at the actual tagging almost one third misses the most basic information (protect_class) and the long list of additional tags suggested in the wiki contains some questionable items and instructions. E.g. protection_aim, protection_ban and protection_instructions don’t seem to be suitable for a tag value, even more as it is not documented how to apply them. E.g. protection_object: the wiki says it should describe what is protected (but not in detail, says again the wiki: “Preferably don´t list species or elements - therefor you should give a website-url.”), in actual values “recreation” is leading, second is “timber”: https://taginfo.openstreetmap.org/keys/protection_object#values valid_from is a rarely used duplicate of start_date, etc. My suggestion for osm carto is to look at both tagging schemes for nature reserves. I wouldn’t drop support for leisure =nature reserve cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Length of ways
On 1 December 2017 at 00:45, Mike Thompson wrote: > Relation length: > In JOSM > Select a member way > In the "tags/memberships" window scroll down to the "Member of" section > Right click > Select members (add) > Note the length in the lower margin of JOSM's main window Really, really, useful. Thank you. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Length of ways
On 1 December 2017 at 00:20, Mike Thompson wrote: > On Thu, Nov 30, 2017 at 5:15 PM, Andy Mabbett > wrote: >> >> Do we have a tool that will give me the length of a way (or a >> relation, made from several continuous ways)? > If you select the way in JOSM it will give you the length in the lower > margin of the window. I'm a JOSM user, and I'd never noticed that! Thank you. > I don't know about relations. I'll add a feature request, tomorrow. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Length of ways
Relation length: In JOSM Select a member way In the "tags/memberships" window scroll down to the "Member of" section Right click Select members (add) Note the length in the lower margin of JOSM's main window On Thu, Nov 30, 2017 at 5:20 PM, Mike Thompson wrote: > If you select the way in JOSM it will give you the length in the lower > margin of the window. I don't know about relations. > > On Thu, Nov 30, 2017 at 5:15 PM, Andy Mabbett > wrote: > >> Do we have a tool that will give me the length of a way (or a >> relation, made from several continuous ways)? >> >> -- >> Andy Mabbett >> @pigsonthewing >> http://pigsonthewing.org.uk >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk >> > > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Length of ways
For a batch solution: * Pyosmium has an osm "road length" example: https://github.com/osmcode/pyosmium/blob/master/examples/road_length.py 2017-12-01 1:15 GMT+01:00 Andy Mabbett : > Do we have a tool that will give me the length of a way (or a > relation, made from several continuous ways)? > > -- > Andy Mabbett > @pigsonthewing > http://pigsonthewing.org.uk > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Length of ways
If you select the way in JOSM it will give you the length in the lower margin of the window. I don't know about relations. On Thu, Nov 30, 2017 at 5:15 PM, Andy Mabbett wrote: > Do we have a tool that will give me the length of a way (or a > relation, made from several continuous ways)? > > -- > Andy Mabbett > @pigsonthewing > http://pigsonthewing.org.uk > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Length of ways
Do we have a tool that will give me the length of a way (or a relation, made from several continuous ways)? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planned rendering changes of protected areas
On 30/11/2017 13:46, Daniel Koć wrote: 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new scheme) are frequently tagged in parallel, and it looks like the old scheme is used as a hack just to make it visible on default map. Just to chuck one example in - I've tagged lots of "leisure=nature_reserve" and almost no "boundary=protected_area; protect_class=XYZ". The reason is simple - nature reserves where I'm likely to be mapping often have a sign saying "XYZ nature reserve". There isn't going to be a sign helping me work out what "protect_class" in OSM it is, so that doesn't get mapped. It's also nothing to do with "what gets rendered"; I actually render my own maps and map quite a lot of stuff that isn't displayed there :) Best Regards, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planned rendering changes of protected areas
W dniu 30.11.2017 o 17:38, Christoph Hormann pisze: There are 62k uses of boundary=protected_area and 77k of leisure=nature_reserve and 31k of the combination - which does not really support your idea that the latter is used just as a hack. How would you detect such a hack then? In my opinion 31k is a serious amount (about a half of both) that is a strong suggestion of the problem, at least. That is frankly just nonsense. If rendering (or not rendering) features with leisure=nature_reserve, boundary=protected_area or boundary=national_park causes visual clutter in a map depends on if and how you render these features. That is the responsibility of you as a map designer. Blaming a tagging scheme for not being able to do that without visual clutter is a bit strange. It's easy - with leisure=nature_reserve you don't have any classification system, so you have less tools to make a proper rendering decisions. The other solution is guessing or accepting the mess, which are poor options for me. Have you looked at if these classes are actually used consistently at the moment? A tagging scheme with ~25 numerical codes as classes with fairly brief and abstract descriptions is not usually destined for success in OSM. We don't need to check every single one of them, probably just selecting a nature related subset of them would be enough. Not everything should be rendered (like "community life" or "earth-moving area") and even just selecting national parks from the rest would be clear win for a start. 4. The new scheme looks like more general than the old one, so it's all that's we really need. Which is just another way of saying boundary=protected_area is much less meaningful than leisure=nature_reserve since the latter at least specifies it is nature protection while the former does not. Just look at the classification, there's a cluster of such classes: https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Nature-protected-area You are also contradicting yourself here - in 2. you say "the old scheme is too generic" and here you say "the new scheme looks like more general" - which is it? By "generic" I mean "lacking details", which is bad. By "general" I mean "encompassing all of this and more", which is good. but then drop arguing for certain tagging ideas based on your perceived needs for rendering. Tagging decisions should be based on how mappers can best document their knowledge about the geography. Not on what some developers find convenient for rendering. In my opinion there's a better tagging scheme for documenting that knowledge, that's why I suggested deprecation. But that is just the opening of discussion, not the final solution. -- "My method is uncertain/ It's a mess but it's working" [F. Apple] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planned rendering changes of protected areas
On Thu, Nov 30, 2017 at 7:46 AM, Daniel Koć wrote: > Hi, > > I'm thinking about changes in rendering of protected areas on osm-carto > and I wanted to give community a hint, because it's a popular kind of > objects. There is a fresh discussion about it from this comment on: > > https://github.com/gravitystorm/openstreetmap-carto/issues/ > 603#issuecomment-347879897 > > In short: > > 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new > scheme) are frequently tagged in parallel, and it looks like the old scheme > is used as a hack just to make it visible on default map. > > 2. The old scheme is too generic and it causes visual clutter, because all > of the protected areas are displayed at once. > > 3. New scheme has many classes defined, which would allow us to fine tune > the rendering (different zoom levels and only some of them). > > 4. The new scheme looks like more general than the old one, so it's all > that's we really need. > > Therefore I think rendering of leisure=nature_reserve should be dropped on > osm-carto, so boundary=* would take over. In this case the areas should be > tagged with a new scheme to be visible there. That might lead to > deprecation of leisure=nature_reserve in the future. I'm OK with this. I wouldn't mind some kind of subtle fill where appropriate. Class 24 areas probably should render something closer to administrative boundaries currently do. Any hatch in that case would need to be insanely subtle in order to not overwhelm other areas that have hatches or it'd just make a real mess of things in the western US (especially in my area where it's a 2-3 hour drive in the shortest direction to leave such a region). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planned rendering changes of protected areas
On Thursday 30 November 2017, Daniel Koc4� wrote: > > I'm thinking about changes in rendering of protected areas on > osm-carto and I wanted to give community a hint, because it's a > popular kind of objects. I have no definitive opinion on the tagging question but i consider your approach here highly questionable. More details on that in the following. > 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new > scheme) are frequently tagged in parallel, and it looks like the old > scheme is used as a hack just to make it visible on default map. Presenting leisure=nature_reserve as an 'old scheme' and 'boundary=*' as a 'new scheme' is a serious mischaracterization. The tags leisure=nature_reserve, boundary=protected_area and boundary=national_park all started being used around the same time. There is no old and new here. There are 62k uses of boundary=protected_area and 77k of leisure=nature_reserve and 31k of the combination - which does not really support your idea that the latter is used just as a hack. > 2. The old scheme is too generic and it causes visual clutter, > because all of the protected areas are displayed at once. That is frankly just nonsense. If rendering (or not rendering) features with leisure=nature_reserve, boundary=protected_area or boundary=national_park causes visual clutter in a map depends on if and how you render these features. That is the responsibility of you as a map designer. Blaming a tagging scheme for not being able to do that without visual clutter is a bit strange. > 3. New scheme has many classes defined, which would allow us to fine > tune the rendering (different zoom levels and only some of them). Have you looked at if these classes are actually used consistently at the moment? A tagging scheme with ~25 numerical codes as classes with fairly brief and abstract descriptions is not usually destined for success in OSM. > 4. The new scheme looks like more general than the old one, so it's > all that's we really need. Which is just another way of saying boundary=protected_area is much less meaningful than leisure=nature_reserve since the latter at least specifies it is nature protection while the former does not. You are also contradicting yourself here - in 2. you say "the old scheme is too generic" and here you say "the new scheme looks like more general" - which is it? On a general note: Please do not mix tagging discussions and rendering discussions - that is a recipe for desaster. If rendering considerations lead you to realize tagging issues and you want to discuss those that is fine but then drop arguing for certain tagging ideas based on your perceived needs for rendering. Tagging decisions should be based on how mappers can best document their knowledge about the geography. Not on what some developers find convenient for rendering. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Planned rendering changes of protected areas
Hi, I'm thinking about changes in rendering of protected areas on osm-carto and I wanted to give community a hint, because it's a popular kind of objects. There is a fresh discussion about it from this comment on: https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-347879897 In short: 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new scheme) are frequently tagged in parallel, and it looks like the old scheme is used as a hack just to make it visible on default map. 2. The old scheme is too generic and it causes visual clutter, because all of the protected areas are displayed at once. 3. New scheme has many classes defined, which would allow us to fine tune the rendering (different zoom levels and only some of them). 4. The new scheme looks like more general than the old one, so it's all that's we really need. Therefore I think rendering of leisure=nature_reserve should be dropped on osm-carto, so boundary=* would take over. In this case the areas should be tagged with a new scheme to be visible there. That might lead to deprecation of leisure=nature_reserve in the future. -- "My method is uncertain/ It's a mess but it's working" [F. Apple] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
