[OSM-dev] Area support

[Brett Henderson]

Karl Newman wrote:
> On Wed, Jul 9, 2008 at 4:00 AM, Frederik Ramm <frederik at remote.org 
> <mailto:frederik at remote.org>> wrote:
>
>     Hi,
>
>     > No need for ids or ordering.
>     >
>     > <area id="1234">
>     >     <tag k="landuse" v="industrial" />
>     >     <outer>
>     >         <nd ref="1"/>
>     >         <nd ref="2"/>
>     >         <nd ref="3"/>
>     >     </outer>
>     >     <inner>
>     >         <nd ref="4"/>
>     >         <nd ref="5"/>
>     >         <nd ref="6"/>
>     >     </inner>
>     [...]
>
>     True, but at least internally some kind of ID would be required to use
>     it in the area_nodes table.
>
>     Bye
>     Frederik
>
>
> But it would be best to keep that sort of detail hidden from the OSM 
> XML file. When an area is uploaded, the area_nodes can just be 
> numbered sequentially, with the outer ring as 0 and the inner rings 
> starting at one and incrementing as a new inner section is discovered.
>
> I've recently been contemplating writing a plugin for Osmosis that 
> would transform OSM data into more of a linestring format (i.e., 
> include the lat and lon of each point in a way along with the ref) and 
> consolidate the multipolygons into single entities such as this. It 
> would make a lot of operations a lot easier to perform without having 
> to first store the node locations...
>
> Karl
This representation looks neat.  The ordering and any internal ids could 
be easily derived based on the xml ordering.  It has strong similarities 
to the osmosis maproom'ish polygon file format in terms of layout (if 
not structure) which makes it easier for me :-)  The Java 2D libraries 
make it very easy to perform geometry tests with this type of data (ie. 
intersects, overlaps, etc).