Re: [Talk-us] Parks, again
Thanks for the advice, Mateusz. I'll think about this some more, and if it still seems like a good idea I'll propose it on github. Andy Townsend gave me the same advice. Best regards - doug On 1/7/2018 4:06 PM, Mateusz Konieczny wrote: > For start: the best place to propose improvements to default map > style is to propose it at > https://github.com/gravitystorm/openstreetmap-carto > > In other places it is highly unusual that somebody involved in > development map style will notice it and on issue tracker > ( https://github.com/gravitystorm/openstreetmap-carto/issues ) proposed > ideas stay under implementation or rejection so nothing is missed > (though somebody still need to implement it), > > > On Sun, 7 Jan 2018 19:58:54 + > Doug Hembry wrote: > >> You are right that I raised the issue of the green fill for >> leisure=park because it is being used for large, wild protected >> lands > That is clearly incorrect tagging. But I guess that these people would > just switch to leisure=pitch or leisure=garden if > rendering for leisure=park would be removed. > >> I'm not sure what you meant about the national_park borders... I'm >> sorry. Could you clarify? > https://wiki.openstreetmap.org/wiki/Tag:boundary=national%20park?uselang=en > is already rendered so I am curious why people still tag for renderer > and use leisure=park in places that are something completely diffferent. > Typically it stops when correct tagging is also displayed. > >> And it's really no big inconvenience for mappers to >> add landuse=grass (or whatever) to their definition of a small urban >> park. > Note that in my experience (limited to Europe) it is very unusual for > entire park to have a single land cover (either grass or trees or > anything else) and it is vastly simpler to draw park area than many > landcover=* or landuse=* areas. > > >> On the other hand, one could argue that since the natural=*, >> landcover=* (and even landuse=*) tags exist, why should we be >> providing another, special way of fill-coloring parks (even small >> urban parks)? > Primarily - to display something useful also in areas that are not fully > mapped (what is quite rare). > >> would be >> to drop rendering for "boundary=national_park" and >> "leisure=nature_reserve" as well > I would not expect it to happen soon. Especially as this tagging is not > terrible and is simpler than proposed new one and widely used. > > Completely broken waterway=wadi tag still haunts us (see > https://github.com/gravitystorm/openstreetmap-carto/issues/1365 ) for > links to gory details. > . > ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, again
For start: the best place to propose improvements to default map style is to propose it at https://github.com/gravitystorm/openstreetmap-carto In other places it is highly unusual that somebody involved in development map style will notice it and on issue tracker ( https://github.com/gravitystorm/openstreetmap-carto/issues ) proposed ideas stay under implementation or rejection so nothing is missed (though somebody still need to implement it), On Sun, 7 Jan 2018 19:58:54 + Doug Hembry wrote: > You are right that I raised the issue of the green fill for > leisure=park because it is being used for large, wild protected > lands That is clearly incorrect tagging. But I guess that these people would just switch to leisure=pitch or leisure=garden if rendering for leisure=park would be removed. > I'm not sure what you meant about the national_park borders... I'm > sorry. Could you clarify? https://wiki.openstreetmap.org/wiki/Tag:boundary=national%20park?uselang=en is already rendered so I am curious why people still tag for renderer and use leisure=park in places that are something completely diffferent. Typically it stops when correct tagging is also displayed. > And it's really no big inconvenience for mappers to > add landuse=grass (or whatever) to their definition of a small urban > park. Note that in my experience (limited to Europe) it is very unusual for entire park to have a single land cover (either grass or trees or anything else) and it is vastly simpler to draw park area than many landcover=* or landuse=* areas. > On the other hand, one could argue that since the natural=*, > landcover=* (and even landuse=*) tags exist, why should we be > providing another, special way of fill-coloring parks (even small > urban parks)? Primarily - to display something useful also in areas that are not fully mapped (what is quite rare). > would be > to drop rendering for "boundary=national_park" and > "leisure=nature_reserve" as well I would not expect it to happen soon. Especially as this tagging is not terrible and is simpler than proposed new one and widely used. Completely broken waterway=wadi tag still haunts us (see https://github.com/gravitystorm/openstreetmap-carto/issues/1365 ) for links to gory details. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, again
On 1/7/2018 12:52 PM, Kevin Kenny wrote: On Sun, Jan 7, 2018 at 2:58 PM, Doug Hembry mailto:doughem...@hotmail.com>> wrote: Briefly, my personal preference (for what it's worth), assuming rendering is added at some point for "boundary=protected_area", would be to drop rendering for "boundary=national_park" and "leisure=nature_reserve" as well (as I'm suggesting for "leisure=park"). The "boundary=national_park" tag is redundant, given "boundary=protected_area and protect_class=2 and protection_title=national_park". IMHO, it could be deprecated. I don't have an opinion on "leisure=nature_reserve". Maybe there's some value to keeping it as part of the set of "leisure=*" values that describe facilities for human recreation, but it doesn't need to explicitly render. I have 'leisure=nature_reserve' on a lot of things so that they will render with the renderer that we have. +1 (or they use "boundary=national_park", then "boundary:type=protected_area" for the same reason) I've been trying hard to make sure that they are also tagged with 'boundary=protected_area protect_class=* access=*' as well, so that when and if the renderer shifts to protected areas, I'm good to go. While posting this, I discovered that I've missed a few, but I need to do research to figure out what protect_class they are. That's one reason that I don't like requiring that 'protect_class' be the only driver. It's often not observable on the ground. I can't tag it correctly until and unless I've done some non-field investigation. +1 It seems probable that some people using the boundary=protected area set will initially skip the protect_class=* tag, or defer providing it, although the table in the wiki is useful. It will likely get filled in eventually by someone, and in the meantime, if/when the renderer supports these tags, it will probably have to tolerate a missing protect_class tag, maybe by assuming a default value (?)I've also done some limited landcover with a few areas like https://www.openstreetmap.org/relation/6467468, but I find it to be really slow going (getting it right involves comparing summer and winter images, for instance). In maps that I render, I ordinarily derive landcover from non-OSM sources, so getting landcover for me has a very low priority - I mostly map what I plan to render. (Also called, "scratching your own itch.") We're lucky in sunny CA, in that it's pretty clear from imagery where are the edges of woods, scrub or grasslands, etc. Season doesn't seem to cause problems. But around here, landcover that people have imported in the past tends to grossly inaccurate. A fair number of 'national parks' are actually class 5 or 6, owing to inholdings and private-public partnerships. They usually have 1b's and 2's embedded within them. OK.. hadn't noticed this, but my point was that the protect_title tag documents that this is a National Park. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, again
On Sun, Jan 7, 2018 at 2:58 PM, Doug Hembry wrote: > Briefly, my personal preference (for what it's worth), assuming > rendering is added at some point for "boundary=protected_area", would be > to drop rendering for "boundary=national_park" and > "leisure=nature_reserve" as well (as I'm suggesting for "leisure=park"). > The "boundary=national_park" tag is redundant, given > "boundary=protected_area and protect_class=2 and > protection_title=national_park". IMHO, it could be deprecated. I don't > have an opinion on "leisure=nature_reserve". Maybe there's some value to > keeping it as part of the set of "leisure=*" values that describe > facilities for human recreation, but it doesn't need to explicitly render. > I have 'leisure=nature_reserve' on a lot of things so that they will render with the renderer that we have. I've been trying hard to make sure that they are also tagged with 'boundary=protected_area protect_class=* access=*' as well, so that when and if the renderer shifts to protected areas, I'm good to go. While posting this, I discovered that I've missed a few, but I need to do research to figure out what protect_class they are. That's one reason that I don't like requiring that 'protect_class' be the only driver. It's often not observable on the ground. I can't tag it correctly until and unless I've done some non-field investigation. I've also done some limited landcover with a few areas like https://www.openstreetmap.org/relation/6467468, but I find it to be really slow going (getting it right involves comparing summer and winter images, for instance). In maps that I render, I ordinarily derive landcover from non-OSM sources, so getting landcover for me has a very low priority - I mostly map what I plan to render. (Also called, "scratching your own itch.") A fair number of 'national parks' are actually class 5 or 6, owing to inholdings and private-public partnerships. They usually have 1b's and 2's embedded within them. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, again
There is a lot to unpack in this discussion. First, OSM has the strong tenet that we should not code (data tag) for the renderer. That is sound advice and largely serves us well, but it fails to directly address that there is no point to being an OSM volunteer unless there ARE renderers which display the results of our mapping (tagging). Well, if you spend time in the more "coding" aspects of our project, you can glean the largely opaque (to most OSMers) processes and personalities of renderers and rendering, and maybe that is appropriate: after all, they are the "back end." Yes, this is where important decisions are made about what data in our map either are or are not shown. (I'm talking about Carto, what might be called OSM's "front door" or "pretty face.") Carto is, for better or worse (and it has gotten much better) what most mappers (and other OSM consumers, though not all) "see as OSM." I know that's not strictly true, but let's say for purposes of this discussion about parks that it is. Especially since having discovered OSM in 2009, I love cartography and mapping. I also love parks, hiking, biking, nature and enjoying our public lands which are protected (at certain "levels") from further human development. So, even as I got started mapping in OSM back then, accurately mapping parks (indeed, even positing ideas at how we might potentially improve how OSM maps parks, something I continue nine years later) became an important goal of mine in this project, reflected in my user page, mapping practices and passionate talk-us discussions. I have followed many twists along the way, such as when leisure=nature_reserve is more correct than leisure=park, a lengthy debate (here) about landuse=forest (which I eventually cried "uncle" about, seeing that we were badly smearing the semantics of well-established wiki definitions, although they were and are ambiguous), striving to "do the right thing" with National Forests, National Parks, State Parks et al, important distinctions between landuse and landcover (still badly under-addressed in our project, as rendering distinctions between them remains muddy and has not fully emerged), the development of the protected_area (a good thing, but sorely lacking in helpfulness when it comes to being rendered — a difficult task, I realize) and other related topics. It is quite complex, it is difficult to communicate about all the moving parts, let alone reach solid consensus, let alone render perfectly what we mean. Tagging accurately, with well-designed and well-documented (in our wiki) schema are absolutely essential. Rendering, at least at "some" level (a single renderer suffices, one, like Carto, which is also well-designed to carefully "map what is important and not map what is not important") isn't QUITE AS essential, but let's use the word "vital" or say "very important." The full path from "volunteer entering data" to "seeing it blossom upon the map" is largely what drives the passion of OSM volunteers doing our good work. So the choice of what to render (in Carto) is vital. As we diligently enter map data, we are pulled forward by the sometimes-seemingly-contradictory desires of wanting to see beautiful renderings of our work as well as to rather precisely enter data, and not code for the renderer. Threading that needle is not alway successful, and it is often thwarted, as I believe it is in this case (parks and related entities, what we might agree are "protected areas") by the distinct lack of these entities rendering well. It is also complicated by the legacy of older/preceding tagging conventions. We've done good work with developing the protected_area schema in our tagging syntax. We haven't done good work rendering the full spectrum of what we mean by those. Again, this is difficult. Colors, confusion with landuse/landcover, ideas about dashing (whether jurisdiction, landcover, "use," or other — I'm open to all ideas) are valid topics to discuss. Let's understand that there has been a medium-long arc of history (over a decade) in our project which must accommodate the way things were done two, five, ten years ago, as well as that we wish to move forward with more robust tagging schema AND better renderings of those schema. In short, and it is widely known: legacies can be challenging to grow beyond. These are complex issues, we have been evolving them over years on top of doing things with more simplistic (legacy) methods, and so many issues must be accommodated in a "smart growth" (towards excellent tagging being supported by excellent rendering) methodology. This forum may not be the best way to do that, as I feel I have typed too much for one missive already. Please, let good discussion continue. We are many people, with many good ideas, who wish to see the "right" and "best" things happen as our project grows and improves. Once again, I believe us to be more in a
Re: [Talk-us] Parks, again
Hi Mateusz, You are right that I raised the issue of the green fill for leisure=park because it is being used for large, wild protected lands, where it causes problems for "natural" and "landcover" tagging. If mappers only used it for smallish, low-protection, usually urban parks, as the wiki defines, it wouldn't be such a problem since these parks are usually mainly grass anyway, and no-one bothers to define them in detail with "natural=*" or "landcover=*". So, yes, the problem arises in what I think is tagging for the renderer. And yes, that means it's really not the renderer's problem. Agreed.. On the other hand, one could argue that since the natural=*, landcover=* (and even landuse=*) tags exist, why should we be providing another, special way of fill-coloring parks (even small urban parks)? It would be more consistent to use the same set of landcover tags for ALL park-type and protected areas. And it's really no big inconvenience for mappers to add landuse=grass (or whatever) to their definition of a small urban park. (Incidentally, the other leisure=* areas that are provided with a fill-color (garden, playground, dog_park,..) are almost guaranteed to be small, and a single color fill is no problem) I'm not sure what you meant about the national_park borders... I'm sorry. Could you clarify? I stayed away from "boundary=national_park" and "leisure=nature_reserve" topic so as not to muddy the water in my original note. But I think it's true that there is also tagging for the renderer going on with these tags too - to force boundary rendering for "boundary=protected_area" which isn't there at present. Briefly, my personal preference (for what it's worth), assuming rendering is added at some point for "boundary=protected_area", would be to drop rendering for "boundary=national_park" and "leisure=nature_reserve" as well (as I'm suggesting for "leisure=park"). The "boundary=national_park" tag is redundant, given "boundary=protected_area and protect_class=2 and protection_title=national_park". IMHO, it could be deprecated. I don't have an opinion on "leisure=nature_reserve". Maybe there's some value to keeping it as part of the set of "leisure=*" values that describe facilities for human recreation, but it doesn't need to explicitly render. I should add that my comments are based only on experiences of my local neck of the woods (CA State, and maybe the west coast of the US). I know you have to consider requirements from all over.. Thanks for reading this far.. On 1/6/2018 7:58 PM, Mateusz Konieczny wrote: > On Sat, 6 Jan 2018 21:11:04 + > Doug Hembry wrote: > >> IMHO, AT THE VERY LEAST, the background green fill for leisure=park >> could and should be dropped by openstreeetmap-carto - it is >> unnecessary, causes problems, and can be replaced by natural=* or >> landcover=* . This would reduce one incentive for inappropriate use, >> and if still used inappropriately, it wouldn't matter so much. > I am not sure. As I understand, problem is caused by tagging for > renderer - but national park borders are already displayed in this > style. > . > ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, again
On 06/01/2018 21:11, Doug Hembry wrote: (lots snipped, pretty much all of which I agree with) IMHO, AT THE VERY LEAST, the background green fill for leisure=park could and should be dropped by openstreeetmap-carto - it is unnecessary, causes problems, and can be replaced by natural=* or landcover=* . This would reduce one incentive for inappropriate use, and if still used inappropriately, it wouldn't matter so much. There's a discussion that touches on this at https://github.com/gravitystorm/openstreetmap-carto/issues/603 - it was initially proposed there to replace the rendering of leisure=nature_reserve with rendering protected_area. leisure=park and leisure=nature_reserve were both designed for specific on-the-ground features, but there's been significant usage of both to "turn areas green" in the OSM Carto map style. While on the topic of rendering "parks", I do agree with Steve (again, if I'm understanding correctly) that it would be valuable, if possible at some point in the future - both for map clarity as well as providing useful information to users - for carto to use different colors for different types of boundaries. I differ with Steve in that IMO the coloring should be based off protect_class (or at least for several bands of protect_class if there are too many distinct values for separate colors) rather than jurisdiction. Jurisdiction is less meaningful to users than level of protection, and in any case is usually obvious from the area name and other tags. Further, boundary rendering should indicate access restrictions (access=yes/no/permit) by some means - perhaps a dashed line as is presently done for highways. To be honest, I wouldn't "suggest that OSM Carto do X" here - there's been a lot of discussion already and no conclusions there. What I'd suggest instead is that someone knocks up a rendering of California based on what it would look like if boundary=protected_area, or protect_class, or whatever is used instead of park, nature_reserve and/or national_park. It's not that complicated to do that - there are basic instructions for creating a tile server at https://switch2osm.org/manually-building-a-tile-server-16-04-2-lts/ and California is small enough in OSM terms to fit on a virtual machine on an average desktop PC. I did something similar for the UK - here https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/c342d0e42aeec0219777535a16e4c025a8886bf1/style.lua#L362 is a simple example of "it it's tagged like X, make it render like Y", and the result is the dashed lines around e.g. https://www.openstreetmap.org/way/144944672 on this map: https://map.atownsend.org.uk/maps/map/map.html#zoom=12&lat=53.3107&lon=-1.7177 . If anyone wants any help with that, please ask. There's quite a lot of useful information around already, bt it is spread out in different places. Best Regards, Andy ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, again
On Sat, 6 Jan 2018 21:11:04 + Doug Hembry wrote: > IMHO, AT THE VERY LEAST, the background green fill for leisure=park > could and should be dropped by openstreeetmap-carto - it is > unnecessary, causes problems, and can be replaced by natural=* or > landcover=* . This would reduce one incentive for inappropriate use, > and if still used inappropriately, it wouldn't matter so much. I am not sure. As I understand, problem is caused by tagging for renderer - but national park borders are already displayed in this style. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, again
On January 4, 2018 at 6:21:03 PM PST, Bradley White wrote: >> I don't think the title >> given to a piece of land should necessarily have bearing on the data >> representation, in the same way "Hampstead Heath" doesn't get >> "natural=heath" just because it's in the name. I forgot to make this point in my previous post. The British English convention of calling a (sometimes municipal) park-like area "Hampstead Heath" being explicitly stated as a different semantic than what OSM tags "natural=heath" is an important distinction to make, and I'm glad our wiki does so. However, by way of contrast, something called "Park" generally IS a park: I seldom, if ever, find an exception to this. As long as that is true (and contrasts sharply with "heath" as you and our wiki remind us), I'll continue to tag something named "Park" with leisure=park. Yes, sometimes I'll use leisure=nature_reserve, but guess what? That's because it's name contains "Nature Reserve" or "Open Space Reserve" or some other set of English words that map directly onto the tag "leisure=nature_reserve." So, while it doesn't NECESSARILY have bearing, I am an intelligent enough user of language (and its derived semantics) to "properly" map these semantics to specific syntax tags in OSM. All OSM volunteers must do at least a little bit of this, and we can even talk about the more subtle aspects of doing so in a forum like talk-us. Our tag of park, I continue to assert most assiduously, is vast and elastic. We might improve it with a rich schema, but until then, it is correct to tag park entries with this tag. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, again
On January 4, 2018 at 6:21:03 PM PST, Bradley White wrote: >> As you say "feel like Type 2" I think is where it fuzzies in my mind. Parks >> go to 3, 4, even 11 and beyond. Parks have a wide range of "experiences" >> besides 1 and 2. > > So do roads. There are countless kinds of roads, with varying levels > of importance and physical features. Instead of using a catch-all > "highway=road" tag, and instead of tagging infinitesimal levels of > network importance (or any of the other countless possible metrics), > we develop a classification system that allocates all roads into a > small set of (semi)-easy-to-work-with-and-understand classes. Some > roads don't fit well into this system, true. It isn't always clean; it > can be ambiguous; it continues to be debated over, and that's fine. > But, for the most part, it has worked, certainly better than the > all-or-nothing alternatives would have. I believe you are saying (agreeing) that "roads have many flavors." Yes. We have many highway=* tags to accommodate those, and while there remain some sticky difficulty in a few corner cases, as we map with values motorway, primary, trunk, secondary, tertiary... OSM (recall, "Street" is our middle name) does well as a result. The tag "highway=road" is not a "catch-all" tag applied recklessly to any and all roads: for the most part roads are tagged with the above (more correct, more precise) values and "highway=road" is left for more ambiguous cases, for example when fuzzy aerial imagery suggests a road/highway, but little or nothing else is known. If I got any of that wrong, please gently correct me. Although, I think we are largely in agreement: we both (and many of us in OSM) use the highway= tag with little argument or consequence. (Again, in a few minor cases, discussion continues). > I agree with previous posters that this is same case with parks. In > the same way that the fact that there is something different enough > about a freeway and a narrow county back-road to represent them > differently in the database, there is something different enough about > a park I would take a kid to play on the playground for an hour, and a > park that I can spend half the day mountain biking around in without > encountering more than a small handful of people, that I think they > should be differentiated between in our data. I don't think the title > given to a piece of land should necessarily have bearing on the data > representation, in the same way "Hampstead Heath" doesn't get > "natural=heath" just because it's in the name. I don't know to which previous posters you refer (this is a new thread I've broken off) and I am not sure of the point with which you are agreeing. If I had to guess (I prefer not guessing) it seems you mean that OSM could benefit from a wide array of park tagging similar to how it enjoys a wide array of highway tagging. I do not disagree, meaning I agree. Sure, early on we seem to have "broken out" (from "generic parks") the specific semantic of "national_park." As I said before, doing so (and where we are now), brings us up from one type of park (all of them) up to two (a certain kind of them excluding the rest), with two being a very small number. There might be dozens or even hundreds of types of parks, and refining this to exactitude and full consensus all across Earth could take OSM decades, with much tedious and messy "sausage making" along the way. Not that it wouldn't be valuable to do so (it would be) since as a result of those efforts, OSM might become one of the best park maps ever made of our whole planet. Alas, as "street" IS our middle name, we've come closer to the goal of well-describing our highway networks, rather than our parks. Though, parks (and many, many other objects in OSM) are somewhat well-represented, I think many agree. We crawl before we walk, we walk before we run. However, we haven't really well or fully described parks. We only partially describe them, which "isn't nothing." (I'm happy to accept this, use it to enter parks, AND improve on our park entry schema). As I mentioned, in 2009 Apo42 in California got into the (good, in my opinion) habit of adding to a (partial, though substantial) statewide parks import a new (back then) tag of "park:type" which often blended jurisdiction, type of natural area and/or purpose. For example, some of its values are county_park, state_beach and state_historical_reserve. This was an early, first foray into better characterizing what California's Department of State Parks throws into a large bin called "parks," (all of them, from beaches to historical reserves) while using the state's own data to better sub-categorize them. As you say, there are all kinds of purposes for what humanity calls "park" and it would be good for OSM to capture these aspects. What we haven't done is talk about what vast issues this gives rise to, primary: what is important? Jurisd
Re: [Talk-us] Parks, again
> As you say "feel like Type 2" I think is where it fuzzies in my mind. Parks > go to 3, 4, even 11 and beyond. Parks have a wide range of "experiences" > besides 1 and 2. So do roads. There are countless kinds of roads, with varying levels of importance and physical features. Instead of using a catch-all "highway=road" tag, and instead of tagging infinitesimal levels of network importance (or any of the other countless possible metrics), we develop a classification system that allocates all roads into a small set of (semi)-easy-to-work-with-and-understand classes. Some roads don't fit well into this system, true. It isn't always clean; it can be ambiguous; it continues to be debated over, and that's fine. But, for the most part, it has worked, certainly better than the all-or-nothing alternatives would have. I agree with previous posters that this is same case with parks. In the same way that the fact that there is something different enough about a freeway and a narrow county back-road to represent them differently in the database, there is something different enough about a park I would take a kid to play on the playground for an hour, and a park that I can spend half the day mountain biking around in without encountering more than a small handful of people, that I think they should be differentiated between in our data. I don't think the title given to a piece of land should necessarily have bearing on the data representation, in the same way "Hampstead Heath" doesn't get "natural=heath" just because it's in the name. Currently, I use the tagging scheme detailed by Greg earlier. I am certainly not opposed to using "leisure=park" along with a basic classification tag, say "park=developed/undeveloped" or something, but Greg's scheme has the benefit of using established tags with rendering support that still more or less respect the definition and intent of the tags. While "leisure=nature_reserve" has generally assumed some kind of conservation status, I think the newish "boundary=protected_area" tags do a much better job detailing land conservation, and that "leisure=nature_reserve" is the perfect tag to adopt for the type 1 parks which Greg talks about. These 'type 1' parks are, after all, pieces of *nature* being *reserved* by a government agency for *leisure* of the public. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Parks, again
On Jan 3, 2018, at 5:24 PM, Greg Troxel wrote: > I think the National Park term causes a lot of problems. As I see it, > there are two kinds of places: > > 1) a natural area with some accomodation for human use, which is mostly > natural except for a few bits. > > 2) a semi-natural area which has grass and trees (instead of > concrete), but is fairly manicured. In this way it is more like a > maintained garden than wilderness.. > > Both of these exist at various scales. I hear you. I'm listening. This is all true. There are also 3), 4) and many, many others. Yes. Our definition of "park" (both as humans and in OSM) is quite elastic, let's face it. As you say "feel like Type 2" I think is where it fuzzies in my mind. Parks go to 3, 4, even 11 and beyond. Parks have a wide range of "experiences" besides 1 and 2. > A "conservation area" in my town might be only 100 acres. You are in > the forest, with just a cleared trail and blazes. But at the entrance, > there is a dirt parking lot and a sign with a map. This is a type 1 > area with a very small (enough for 10 cars) part that almost feels a > little type 2 (except the parking lot is barely usable), but it's so > small we just call it type 1. Again, I hear this, this is true, I nod my head in agreement. There is what we experience in the real world and yes, that maps directly onto a tag in OSM. Park is that. States use it. Nations use it. "Come camp here for the night or a week" places which are commercial use it. It is elastic in the real world and many use it, as we call myriad of them by using the name park in our speech as a noun. It is a wide and flexible concept in human thinking, directly applied to all kinds of places around the world. By billions of us. Frequently. > Whether anybody (administrator of thing or not) uses the work Park is > not relevant at all. Mmm, no. We (humanity, including administrators and the people) mean something as we use the word "park" together in wide harmony. That is (at least partly!) why we tag with the word "park." Yes, there are "local parks with benches and grass in our city." Yes, there are "national parks." We're only up to two, right there. Then you get to their various scales. There are many more than two. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us