[OSM-dev] dropping segments

Frederik Ramm frederik at remote.org
Sat Jul 28 11:55:15 BST 2007


Hi,

>     >  2) Areas with 'holes' could be stored as an area with 2 child
>     >  areas, and appropriate tags on those areas to control which was the
>     >  bit being added and which was the bit being subtracted (the hole) -
>     >  (I hope that makes sense)
> 
>     Why can't layers be used for holes in an area?
> 
> 
> I hadn't considered layers - sounds a possibility. I don't even know if 
> 'areas with holes' are really needed - the only examples I can think of 
> are maybe donut-shaped parks? In any case, layers sound highly useful 
> anyway, for several reasons like :
> 
> 1) We could separate out layers to have areas like "country outlines", 
> "county outlines"
> 2) We could have separate layers for 'temporary' data (such as the 
> flooding information I think has already been mentioned)
> 3) You could export these layers into planet.osm files separately - 
> unchanged layers wouldn't even have to be exported again at all...

We have the concept of "layers" already, for denoting something built at 
another height level (i.e. a bridge over a stream would be layer=1, the 
stream, by default, layer=0).

Using this for areas with holes would be am ugly hack, because the 
clearing in the woods is not on another height level as the woods. If 
you have a donut-shaped park and a building in the middle, and you 
simply make the park a circular area and count on the building being 
"painted" above, you're creating a distorted model of reality. For example:

"Paint a map without buildings" - would show a circular park and not a 
donut-shaped park.

"Calculate the total parkland area" - would include the area of the 
donut hole.

"Tell me which objects are at lat=..., lon=..." - would return building 
AND park for a point inside the building.

As for flooding information and so on, you're talking about logical 
layers here not the existing ones. (But logical layers, too, are 
unsuitable for solving the donut-shaped-park problem.)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'




More information about the dev mailing list