[Tagging] boundary relations and the subarea property

[Colin Smale]

I use the subarea member because it makes cross-checking easy. Have all
the lower-level boundaries in my higher-level admin area been added to
OSM? 

Unfortunately the various admin levels do not always form a strict
hierarchy. A small area at (lets say) admin_level=10 might be enclosed
spatially by entities at level 8, 7, 6, 5 etc but it only has a direct
administrative relationship with one of them, which might not be the
next-highest level (next-lower number). 

Finding the boundaries of all districts within a county (UK example)
becomes trivial with the explicit parent-child link. Otherwise its like
finding all boundaries with admin_level=8 which are at least 99%
contained by the higher-level boundary. That sounds computationally a
lot more complicated to me. Why not 100%? Because sometimes the
boundaries at different levels are not imported/drawn from the same
source, leading to the boundaries not being exactly coincident. So there
needs to be some tolerance in there. 

//colin 

On 2015-11-26 19:51, Martin Koppenhoefer wrote: 

> I just noticed that a lot of boundary relations have the lower ranking parts included as members with the "subarea" role. This role is documented here: 
> http://wiki.openstreetmap.org/wiki/Relation:boundary
> 
> But I wonder how it got on this definition page. Was this discussed anywhere? I don't think it's a good idea to add all those lower entities in nested relations (they are already spatially structured, this is redundant and makes the relations more complicated for no good reason).
> 
> I propose to remove this property from the definition page and move it to the talk page.
> 
> Comments? 
> Cheers, Martin 
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20151126/58878f91/attachment.html>