<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Talk-us] Park Boundary
tagging</title></head><body>
<div>Perhaps we can both be correct simultaneously, while holding in
reserve multiple foci about what we mean.</div>
<div><br></div>
<div>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):</div>
<div><br></div>
<blockquote type="cite" cite>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.</blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite>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.</blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite>A way with boundary=* is completely
different. These are generally is not closed and therefore obviously
cannot be an area.</blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite>The standard reference for a tag
describing a polygon or a linear feature is <a
href=
"http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.style"><span
></span
>http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/def<span
></span>ault.style</a> but it does not apply to type=* which is
handled at a lower level.</blockquote>
<div> </div>
<div>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.</div>
<div><br></div>
<blockquote type="cite" cite>I'm not sure it's useful to continue, but
(ignoring wiki and existing<br>
practice) I think of a boundary as closed line, not as an area.
Yes,<br>
you can talk about inside and outside, but really that's it. The
notion<br>
of "all land inside this closed way has this property" is
distinct from<br>
"this line is a boundary" (which the two-relation approach
makes very<br>
clear). What I don't like about the boundary tag is that I don't
see<br>
any reason why "this area has property X" won't end up
with<br>
"boundary=X", and that result seems broken, especially since
boundary=X<br>
seems to be shorthand for certain tags on the area.<br>
</blockquote>
<blockquote type="cite" cite>Probably the root of the issue is that
OSM blurs closed linear features and areas.</blockquote>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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?</div>
<div><br></div>
<div>Terrific thread so far!</div>
<div><br></div>
<div>SteveA</div>
<div>California</div>
</body>
</html>