Re: [Talk-us] Park Boundary tagging
I'm not sure it's useful to continue, but (ignoring wiki and existing practice) I think of a boundary as closed line, not as an area. Yes, you can talk about inside and outside, but really that's it. The notion of all land inside this closed way has this property is distinct from this line is a boundary (which the two-relation approach makes very clear). What I don't like about the boundary tag is that I don't see any reason why this area has property X won't end up with boundary=X, and that result seems broken, especially since boundary=X seems to be shorthand for certain tags on the area. Probably the root of the issue is that OSM blurs closed linear features and areas. pgpvVwVx8NshA.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
Perhaps we can both be correct simultaneously, while holding in reserve multiple foci about what we mean. For example, Paul Norman shares with me that his greater meaning in his previous post includes that it depends what you mean by boundary. He goes on to describe (Paul Norman writes): A type=boundary relation is generally interpreted to be an area by all software I am aware of that makes the distinction between a LINESTRING and a POLYGON (linear vs area). I have some code that treats it as a linear feature, but then it treats everything as a linear feature or a point at that stage because it only cares about building bounding boxes. Keep in mind that just because a feature is an area doesn't mean you display it like one. For example, no one would disagree that a closed building=yes way is an area, but many renderings put a line around the outside. Similarly, if you're only rendering the outside line of the area it doesn't matter if you represent it as a linear feature or an area because it looks the same. A way with boundary=* is completely different. These are generally is not closed and therefore obviously cannot be an area. The standard reference for a tag describing a polygon or a linear feature is http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.stylehttp://svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.style but it does not apply to type=* which is handled at a lower level. In short, these are muddy waters. Nobody should start to assert absolutes, unless simultaneous perspectives have been eliminated. In the context of type being one thing (and handled e.g. as a software implementation along a path to render mapnik) and boundary meaning (in a wide semantic sense) another, we do indeed have multiple perspectives. So my or any other absolutism is likely premature. I'm not sure it's useful to continue, but (ignoring wiki and existing practice) I think of a boundary as closed line, not as an area. Yes, you can talk about inside and outside, but really that's it. The notion of all land inside this closed way has this property is distinct from this line is a boundary (which the two-relation approach makes very clear). What I don't like about the boundary tag is that I don't see any reason why this area has property X won't end up with boundary=X, and that result seems broken, especially since boundary=X seems to be shorthand for certain tags on the area. Probably the root of the issue is that OSM blurs closed linear features and areas. You've summed up nicely a perspective which is valuable. I think the big take-away we blur much, and there now exist (as implied behavior by the mapnik visual-render path) shorthand for certain tags on the area. Succinctly: tags which imply semantic meaning must be untangled from the syntax of what we do mean. So, a better direction for this thread to continue might be for it to examine and discuss the syntax of park tagging. What might be an ideal tagging today (for various park entities upon which we agree have a standardized semantic understanding), what might we expect from tagging but do not get with mapnik today, and what might we posit as slight changes to mapnik style sheets which cause to happen interesting, consensus-reached and beautiful renderings which visually convey a lot more than is conveyed today? Terrific thread so far! SteveA California___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
It might be useful to look at existing GIS practice to see how boundary objects are treated in terms of being LINESTRING vs POLYGON (thanks Paul for reminding us of OGC simple features defined terminology). But, I suspect that the GIS world has a layer and a text description of it, and that has let them avoid what OSM is doing: building a coherent representation of everything (which leads to all the trouble). pgp3_DeBjdknT.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
stevea stevea...@softworkers.com writes: So, a better direction for this thread to continue might be for it to examine and discuss the syntax of park tagging. What might be an ideal tagging today (for various park entities upon which we agree have a standardized semantic understanding), what might we expect from tagging but do not get with mapnik today, and what might we posit as slight changes to mapnik style sheets which cause to happen interesting, consensus-reached and beautiful renderings which visually convey a lot more than is conveyed today? I suggest that the tags for parks/etc. be defined so that if there are no boundary tags, everything still makese sens. (I'll further suggest that once this is done, there is no need for boundary tags.)) I'll start with landuse=conservation (because at least a co-primary purpose is to preserve the land for the future, and usually this is primary.) leisure=nature_reserve (because a co-primary, but really not quite-as-high-as-conservation is to allow access to the public) Then we get into tags that refer to the administrator of an area. One can consider a tag that is administrator=government:admin_level=2 administrator_name=National Park Service (for a national park) administrator=government:admin_level=4 administrator_name=Massachusetts Department of Conservation and Recreation or administrator=charitable:admin_level=2 (for a national-level charitable non-profit) administrator=charitable:admin_level=8 administrator_name=Westborough Community Land Trust (for a local non-profit) Or perhaps break that up into two. And of course name of the park. My bias is that the nature of the land use is more important than the identity of the manager. Another similar area is a wildlife refuge. Ones that allow humans are perhaps appropriately tagged as above. Ones that do not allow humans as perhasp landuse=conservation and some other special wildlife_refuge tag. pgpa2bCcfX84b.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
There are some anomalous cases that are of particular concern to me. Consider the Adirondack and Catskill Parks in New York. These are enormous tracts of land with intensive conservation restrictions placed on them - but many lands within the parks remain in private hands; in fact, there are entire villages within the confines of these huge parks. These areas are often shown on New York State maps with a blue outline - in fact, the Blue Line is the conventional name for the boundary. Mostly within these areas, and sometimes but not always coterminous with them, are a collection of Wilderness Area, Wild Forest, State Reforestation Area, Wildlife Management Area, Canoe Area, Primitive Bicycle Corridor, State Campground, State Unique Area, and so on, that are actually State-owned lands allowing public access for different types of activity. There are also similar conserved lands outside the Adirondack and Catskill Parks. Certainly in the Catskills, and likely elsewhere, there are Wild Forest and State Reforestation Area parcels that cross the Blue Line. Entirely separate from this system and administered by a different arm of the State government are a set of State Park, State Historic Site, State Recreation Area, and so on. These range from sites that would be best described as recreation ground to backcountry preserves that take days to hike across. There is a possible administrative hierarchy here, too: for instance, the Anthony Wayne recreation area is entirely within the confines of the Harriman State Park. What's the point of all this? Merely to indicate that the tagging scheme: - most likely ought not to presume that all 'state parks' are entirely state-owned: in New York, the two large parks are partially private, and the public's right of access varies. - must not assume that state parks do not overlap, nor that overlap among them is a strict containment relationship. - must not assume that a state park has a single purpose (e.g., leisure=nature_reserve): many of New York's large state parks contain campgrounds, youth camps, recreation grounds, swimming beaches, and other developed amenities as well as large tracts of backcountry reserve. By the way, these lands must not be dismissed as insignificant: the Adirondack park is larger than Yellowstone, Glacier, Cascade, and Everglades National Parks - combined. The Catskill Park is about of a size with the larger National Parks. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
While Greg describes what might be, I'll describe what is. I'm only scratching a surface or two as I do. I described uploading both Forest Service boundaries for National Forests and Wilderness areas. As we were using USFS data from a particular source: source=http://fsgeodata.fs.fed.us/vector/lsrs.php For Wilderness, these tags: leisure=nature_reserve boundary=national_park boundary:type=protected_area protect_class=1b protection_title=Wilderness ownership=national And change WILDERNE_1 tag to: name=Name of Wilderness For National Forests, these tags: landuse=forest boundary=national_park boundary:type=protected_area protect_class=6 protection_title=National Forest ownership=national Adding a tag like: park:type=national_forest;wilderness is optional, but park:type is a tag gaining widespread use (starting in California) to distinguish between national_forest, state_park, state_beach, county_park, city_park, etc. When doing this, use the correct value, with underscores for spaces, and separating with semicolon any conflated areas (such as national_forest and wilderness). For example, you might add (for a National Grassland): park_type=national_grassland I suggest that the tags for parks/etc. be defined so that if there are no boundary tags, everything still makese sens. (I'll further suggest that once this is done, there is no need for boundary tags.) I'm OK with positing that we need not use the boundary tag. But then what will render a boundary, if any? Yes, we can point to mapnik rules that say if name key of a polygon or multipolygon = a value, display it being the reason that you see black text saying Sequoia National Park. But it is key=value pair boundary=national_park that renders pretty green text out to z=6. We also notice that if leisure=park mapnik renders a nice light-green fill color or if landuse=forest we get dark-green with little trees. Likewise leisure=nature_reserve gives us the little NR overlay. Yes, landuse=forest (on national forest) and leisure=nature_reserve (on wilderness) yields dark-green + NR (to pleasing effect) and well-represents a wilderness inside of a national forest. But the edge between these is difficult to see without a boundary (=national_park) tag. So, I like using it, and think it is a good idea to do so, as it sharpens that boundary where it is appropriate to see that boundary. But I am open to better tags to achieve these or similar desired results. landuse=conservation (because at least a co-primary purpose is to preserve the land for the future, and usually this is primary.) leisure=nature_reserve (because a co-primary, but really not quite-as-high-as-conservation is to allow access to the public) The landuse and leisure keys are separate, and they have multiple possible values. Before we get into the specifics (or maybe AS we get into them, so that we may untangle them properly) let us ask first if there are any mutually exclusive values. Then we get into tags that refer to the administrator of an area. I will temporarily ask us to conflate administrator into administrator + operator + ownership as it may be possible that we can agree upon certain tag groups for certain semantically identical objects. (Though I could be wrong). Tangled up is admin_level but that may (strongly?) imply boundary=administrative. I'd like to see what happens with mapnik rendering when admin_level is used with other boundary values, like boundary=national_park. Maybe I'll play a bit with some boundary values and admin_levels, non-destructively of course. I just want to see what mapnik is doing, vs. what we mean to happen. And of course name of the park. Agreed, this seems fairly straightforward as a text string in the name= key. Just a caution that what paints the name of an object (polygon, multipolygon) might be distinct from what its boundary tags (if any) do. My bias is that the nature of the land use is more important than the identity of the manager. Another similar area is a wildlife refuge. Ones that allow humans are perhaps appropriately tagged as above. Ones that do not allow humans as perhasp landuse=conservation and some other special wildlife_refuge tag. So, a short catalog for possible tags to untangle semantics regarding parks: landuse [forest, wood, conservation...] leisure [park, nature_reserve...] name=[Text String for name of park] boundary=[administrative, national_park] boundary:type=[protected area] protect_class=[many alphanumeric values possible, among them 1b=US Wilderness, 6=US National Forest) protection_title=[] ownership=[national, state, county, city, neighborhood_association, private] park:type=[state_park, county_park, city_park, private_park, state_beach, county_beach, national_forest, national_wilderness, state_wilderness, national_monument, state_historic_monument, many others] I already see a slight problem with
Re: [Talk-us] Park Boundary tagging
Most know this, but it can't hurt to point out some distinctions. When I say semantic(s) I mean what we wish to convey. Or, higher-level meaning. When I say syntax I mean how we say it; the grammar and characters we type to utter it in a well-formed way. Here, it is a particular semantic thing to convey. So, semantic structures include: various ways humans use land and groupings of vegetative or rocky/sandy/muddy/watery land coverings and category-names that political bodies give to areas of land for human, plant or animal conservation Syntactic structures include: The : as a way for the more general tag park (not used as an OSM key to the best of my knowledge) to be extended into park:type as the name of a key holding values like county_park or state_wilderness. Grouping, in general. So, landuse=[farm, forest, meadow, industrial...] is a syntactic structure for putting RELATED things into a container that holds them, BECAUSE they are related. Numbering, but with some careful distinctions: integers used as values in a key-value pair are syntax, AND have semantic meaning. An example: 2, 4, 6 and 8 are admin_level values to mean nation, state, county and city. The numbers in the key-value pair are syntax, but what they mean are semantic. Also helpful to keep in mind is the concept of a rendering toolchain that starts with a semantic idea in the mind of a human (I want to see Acme Park on the map), this falls into one (and should be only one) semantic bucket of means this and only this, this gets turned into a syntactic sentence (grammatically correct in OSM-speak), like landuse=forest + name=Acme Park as tags on a simply polygon, this utterance goes through some behind-the-scenes server magic (like how osm2pgsql allows OSM - PostgreSQL - mapnik) and eventually Acme appears as named, colored park on rendered map. Item in real world - sensible semantic object - syntactic OSM utterance - toolchain - map rendering. Again, I know it may be obvious, but we are talking about many things on many levels here. This is a useful hierarchy/nomenclature, and these paths really do exist. Let's try to keep them straight. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
stevea stevea...@softworkers.com writes: Each of those seven values for key boundary is documented to be of element area (with the exception of boundary=user defined, where it is given greater freedom to be assigned to primitives of points and open polylines). So for Greg to assert that if it is a boundary, it should be tagging the line feature, and it's a bug for that to affect the rendering of the area just flatly contradicts our wiki. To summarize, the boundary tag absolutely positively defines areas, not line features (ways as open polylines). I completely disagree with Greg's conclusion above, but I'm still listening to and participating in this discussion. I will concede that my view is contradictory to what's documented. But I think there's a fundamental semantic confusion lurking, in that boundaries are linear features, and properties of land belong as area features. But, I see that admin_level=8 boundaries around towns also let one define which town a particular point is in. What I am uncomfortable with is a proliferation of boundary= which is really trying to set properties of the area. If boundary=national_park is ok, why not boundary=shopping_mall, etc.? (not directed at you in parricular:) As for landuse=conservation, I agree that it's not well supported in the wiki. But I see a principle that every bit of land, more or less separated by ownership or adminstrative control, should have one landuse denoting the primary purpose. For many parcels/etc., 'conservation' more or less sums up the purpose. In general, I think we have a patchwork of tags with confusing semantics. It's a strength of OSM that tag usage grows organically without process constraints, but the other side of the coin is this sort of rethinking and rearranging. pgptzggkEhkPx.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
On Mar 2, 2013, at 10:58 AM, Greg Troxel g...@ir.bbn.com wrote: I will concede that my view is contradictory to what's documented. But I think there's a fundamental semantic confusion lurking, in that boundaries are linear features, and properties of land belong as area features. welcome to osm. forget clean semantic and strict definitions. Yes it doesn't make any sense for someone with a understanding of traditional systems and technology. take the path vc. footway discussion as an example. It's still not unified and about every couple months someone starts the discussion again with no progress. almost all tags in osm are a mess but data consumers have learned to live with it. Don't change a running system ... But, I see that admin_level=8 boundaries around towns also let one define which town a particular point is in. What I am uncomfortable with is a proliferation of boundary= which is really trying to set properties of the area. If boundary=national_park is ok, why not boundary=shopping_mall, etc.? why boundary=national_park it's in use it's rendered in mapnik and other tools. why not boundary=shopping_mall. because it's not established. If you and others decide it makes sense and start to do it then maybe in a couple months the answer will be a different one. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
Greg Troxel g...@ir.bbn.com wrote: I will concede that my view is contradictory to what's documented. But I think there's a fundamental semantic confusion lurking, in that boundaries are linear features, and properties of land belong as area features. Apollinaris Schoell ascho...@gmail.com answered: welcome to osm. forget clean semantic and strict definitions. Yes it doesn't make any sense for someone with a understanding of traditional systems and technology. take the path vc. footway discussion as an example. It's still not unified and about every couple months someone starts the discussion again with no progress. almost all tags in osm are a mess but data consumers have learned to live with it. Don't change a running system ... I'm not sure about a fundamental semantic confusion lurking, and I hereby ask Greg to share with us an existence proof of such a thing regarding boundaries. Consider boundary and you might think of the very local one-dimensional act of crossing it or there is this side of it and that side of it. To my mind's understanding of geometry, OSM's wiki documenting boundary as areas seems 100% correct: name a boundary that does not actually describe the inside vs. the outside of an area. You can't do it, can you? We live on the surface of a planet, making what maps describe essentially two-dimensional. Sure, there are objects on Earth we might agree it is convenient to describe as one-dimensional. You might find a fence on a boundary that runs only part way around it, meaning that the fence has endpoints. But though that allows us to agree the fence is one-dimensional, the boundary isn't, it is two-dimensional: it describes an area. What semantic confusion? Well, OK: our wiki page for Boundaries (plural) says The original accepted usage was to apply this tag to areas. However, there now seems to be a consensus of using the boundary key also on linear ways, with relations used to aggregate these ways. (Like that fence?) So guess what I'm going to bring up now! I'm glad Apo chimed in here, as it highlights something he did in his State Parks upload a few years back s germane to this discussion. In his upload of Anza-Borrego Desert State Park, he uploaded two relations: one (relation 184199) to describe the boundary, another (relation 181095) which described the area inside. Specific tags are: Relation 184199: type=boundary boundary=national_park admin_level=4 Relation 181095: type=multipolygon leisure=park (Of course, both relations also have additional, identical tags, like name=Anza-Borrego Desert State Park). This seems odd from a what the wiki says perspective: supposedly, only when boundary=administrative is defined is the associated combo tag of admin_level also allowed to be used. Yet here, Apo instead uses boundary=national_park + admin_level=4 (+ type=boundary to describe the type of relation). In mapnik, it works: this combination produces admin_level=4 green-dashing AROUND the park: its boundary. It seems what is going on is admin_level is paid attention to (by JOSM, by mapnik...) even when boundary=administrative is not present, but boundary=national_park is present. OK, now we know that. The other relation draws the AREA of the INSIDE of the park: the leisure=park tag in this second relation renders the light-green park fill color. (I'm pretty sure I'm getting this right; I don't want to go yanking out tags and playing around, but maybe I should. Maybe Ian sets up a sandbox server where Dane allows mapnik style sheet changes for some experimentation. That is an off-list email conversation I'm part-having). In short, Apo has discovered that using two relations, one to draw the boundaries (of the members), the other to fill in the areas (of the members) is both effective (two relations, two items drawn as we might like to see them) and efficient (a couple of relations with a dozen or so tags, most shared/duplicated, yes, but not a terrible amount of excess storage. Oh, yes, plus polygons as members of both relations, but that should go without saying). Crucial is that two relations draw two things: edge and inside. In simple cases where no multipolygon is required, Apo puts these (germane, there are others) tags on the simple closed polyline way (polygon): leisure=park boundary=national_park admin_level=4 No need to say either type=boundary or type-multipolygon since there is no relation needing its type specified, just a polygon. So leisure paints the fill-color, and boundary and admin paint the color and dashing of the edge. And it appears mapnik gives us a pass using admin_level without boundary=administrative, as long as another rendering boundary= key-value pair is included -- though boundary=national_park seems to be the only other one that renders in a particular color. I think I understand Greg's perspective that a boundary is the crusty edge of
Re: [Talk-us] Park Boundary tagging
Both of those relations describe areas. In fact, I believe osm2pgsql uses the exact same code for building type=boundary as type=multipolygon. From: stevea [mailto:stevea...@softworkers.com] Sent: Saturday, March 02, 2013 3:38 PM To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Park Boundary tagging I'm glad Apo chimed in here, as it highlights something he did in his State Parks upload a few years back s germane to this discussion. In his upload of Anza-Borrego Desert State Park, he uploaded two relations: one (relation 184199) to describe the boundary, another (relation 181095) which described the area inside. Specific tags are: Relation 184199: type=boundary boundary=national_park admin_level=4 Relation 181095: type=multipolygon leisure=park (Of course, both relations also have additional, identical tags, like name=Anza-Borrego Desert State Park). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
Greg Troxel g...@ir.bbn.com writes: I agree that boundary=national_park is confused, and to first order I think we should get rid of it. The first question is whether it's tagging a boundary, which is a line feature, or whether it is tagging the polygon. If it's a boundary, it should be tagging the line feature, and it's a bug for that to affect the rendering of the area. But that's how it is used now. OSM's wiki lists elements (primitives) as points, ways (open polyline, closed polyline or area), and relations, all of which can have tags, plus relations have members with optional roles. OK, we understand this. OSM's wiki lists seven values for the boundary key: administrative (where admin_level is an associated key), maritime, national_park, political, postal_code, protected_area, and user defined, where taginfo lists all of the above being used (administrative makes up over 91% of boundary= usage), plus hundreds of others. Also, taginfo lists boundary=national_park as being used about 11,000 times (1.25% of the ~one million times the boundary tag is used): boundary=national_park is both documented and well-used. Each of those seven values for key boundary is documented to be of element area (with the exception of boundary=user defined, where it is given greater freedom to be assigned to primitives of points and open polylines). So for Greg to assert that if it is a boundary, it should be tagging the line feature, and it's a bug for that to affect the rendering of the area just flatly contradicts our wiki. To summarize, the boundary tag absolutely positively defines areas, not line features (ways as open polylines). I completely disagree with Greg's conclusion above, but I'm still listening to and participating in this discussion. I think national parks should have landuse=conservation leisure=nature_reserve like all other conservation/human-use-also areas. The wiki page for tag Conservation is just a stub and points right back to boundary=national_park and boundary=protected_area. The latter is actually a fairly well-developed scheme, though new-ish to OSM, even if it is not well-supported by the standard (mapnik) renderer. As I mentioned, the former (boundary=national_park) IS well-supported by mapnik. If we do want to tag park boundaries, I think we should step back and ask why, and then have a coherent park boundary scheme. national parks, state parks, municipal parks are in some sense really all the same, except different levels of government own and administer them. I agree that national parks are a bigger deal socially, but I don't see a big enough distinction to have a special top-level tag. Here, Greg and I agree: a coherent park boundary scheme is what we are discussing, and it needs improvement in both development of a sensible tagging syntax, and support for that in mapnik render rules. That tagging syntax will likely include harmonization of the following top-level tags: boundary (including the combo tag admin_level), leisure, and possibly landuse, though by no means is this list meant to be complete. Accordingly, I have changed this thread title from Wilderness Data to Park Boundary tagging. I think it's also confusing for our international comrades that we use park in two totally different senses: national park, which is about a balance conservation/preservation and access local park, which is often a leisure=recreation_ground and not necessarily conservation (ball fields, etc.) local consevation area, which is not called park, even though it's far more like a national park in character (but not scale) compared to a local park So let's collect tags and do a here's what's used vs. here's what we want to convey matrix. I won't start that more technical aspect now, because I agree with you (again) that we should step back and ask why we want to tag park boundaries. So, why do we? Well, one, to show that we conserve land. Two, to delineate boundaries where we might recreate on that land. Beyond those, it blurs into nearly endless detail. Well, OK, three: we might also discuss (again I'm agreeing with Greg) that different levels of government own and administer (parks). If we stick to those basic tenets, I think we can do this. The new thread begins. Let's discuss. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
