[Talk-us] Park Boundary tagging
steveaOSM at softworkers.com
Mon Mar 4 00:37:48 UTC 2013
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
>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
>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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-us