[Talk-us] Park Boundary tagging

stevea steveaOSM at softworkers.com
Sat Mar 2 23:38:15 UTC 2013


>Greg Troxel <gdt at 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 <aschoell at 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 "something" but I still say that that something is a 
two-dimensional entity we can always say is an area (otherwise you 
are "being too local" and ignoring away something that would truly 
show it as an area).  I mean always:  I don't think there are any 
one-dimensional boundaries anywhere on Earth (I'm listening, though 
-- and there is that consensus of key boundary on linear 
ways...where?).  Plus, if you want mapnik to show you this 
distinction between "the edge" and "the inside area" for parks, Apo 
has shown us a pretty, succinct and effective method for doing so.

Many questions still remain, but this is too long already.  And I'm 
not sure I've clarified anything, just given some concrete tagging 
examples which allow mapnik a distinction between "crusty edge" and 
"gooey filling."

SteveA
California
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20130302/d4d7feaf/attachment.html>


More information about the Talk-us mailing list