[Talk-us] Landuse polygons within landuse polygons
gdt at ir.bbn.com
Mon Feb 11 23:26:06 GMT 2013
stevea <steveaOSM at softworkers.com> writes:
> I have questions about landuse polygons. For example, barracks, where
> soldiers are quartered (housed) inside of a military base. A polygon
> surrounding the military base (where the boundary is) with the tag
> landuse=military seems correct, indeed there are many examples. For
> the barracks specifically, do I draw the buildings and tag them
> building=residential? Sure, that seems correct, too.
> But, do I also add a polygon with landuse=residential to the "zone" or
> "neighborhood" where the barracks are clustered? This would be a
> double-overlap of landuse polygons, residential "on top of" or
> "within" military. Sure, I could make the landuse=military a
> multipolygon (outer member) and punch a hole in it with the barracks
> neighborhood as an inner polygon, but in so doing we lose the semantic
> that barracks are BOTH military AND housing. At the same time, we
> don't want to approach or achieve coding for the renderer.
Here, I would suggest stepping back and talking about the intended
semantic representation of the world we are trying to achieve. I think
what you're running into is a clash of two goals:
1) every bit of land has a single landuse=, describing overall purpose
for the zone of control, usually a parcel boundary. This is a simple
(not simplistic!) view of the world. A base with housing is first and
foremost a base.
2) sometimes #1 doesn't quite make sense, and multiple landuse values
can apply. In particular, landuse=military is not about purpose, but
ownership, and the military has residential, commercial, industrial,
ranges, etc. So landuse=military is confused, and we need some sort
of higher-level ownership and purpose tag. The same can be said of
places like Disney.
Overall, I come down on there being a published taxonomy of landuse, and
picking one. If one were going to use landuse=residential on barracks,
I would use a multipolygon for the outer =military with a hole. But I
would just leave it all =military (were I to map military bases, which I
haven't); military housing on a base doesn't act like residential in
terms of access.
> Similar questions arise with "other" (non-landuse) tags which might
> logically be applied "over" one another. An example is a (say,
> largely wooded) leisure=park polygon with several landuse=meadow
> polygons sprinkled about it. In this case, leisure and landuse ARE
> distinct tags, so no double-overlap is strictly happening. And in
> mapnik, the effect is rather pleasing. (See, for example,
In this case, I think the basic issue is confusion between landuse and
landcover. meadow isn't a landuse, but a description of the state of
vegetation on the ground. If the park is primarily for conservation,
with human access, it should get landuse=conservation. If it's
primarily for recreation, it should get some kind of landuse=recreation
tag. Then, various areas can get natural=wood, natural=meadow,
natural=grass, etc. landcover tags and landuse are orthogonal and thus
don't overlap with each other.
> In a nearby case, a leisure=park is so largely wooded that a
> natural=wood tag is ALSO applied to the entire park multipolygon, but
> there are also some landuse=meadow polygons sprinkled about. Here, we
> have three different polygon tags: leisure, landuse and
> natural. Mapnik handles this well, again with a pleasing effect
natural=wood should have multipolygon holes, and landuse=meadow seems
wrong, but the *landcover* meadow tag could go on the holes.
I think your question was a good one - the hard case is military
housing. But overall I think each bit of ground should have at most one
landuse value and at most one landcover value, and it should be a
validation error to be >1, and this consistency is more important than
permitting double landuse.
(I realize my landuse/landcover distinction is at odds with the wiki.
But I think it makes more sense than what is on the wiki.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: not available
More information about the Talk-us