[OSM-dev] API 0.5 is on the way

Jon Burgess jburgess777 at googlemail.com
Tue Sep 11 22:29:43 BST 2007

On Tue, 2007-09-11 at 08:58 +0000, Gabriel Ebner wrote:
> On Tue, Sep 11, 2007 at 10:44:30AM +0200, Håkon Enger wrote:
> > On Tue, 11 Sep 2007, Frederik Ramm wrote:
> >
> >> Current ways will be split into several parts where the new model cannot
> >> accomodate their complexity
> >
> > I suppose this means that a relationship grouping the different parts of a 
> > way split in this fashion will be added as well? (To accomodate for lakes 
> > with islands and other areas with "holes" in them, etc.)
> Yeah, that's how it's going to happen.  The migration script just adds a
> relation like the following:
>   <relation id="123">
>     <member type="way" ref="1001" role=""/>
>     <member type="way" ref="1002" role=""/>
>     <member type="way" ref="1003" role=""/>
>     <tag k="type" v="multipolygon"/>
>   </relation>

In regular geometry terms, a polygon with holes is still called a
polygon. A multipolygon consists of several polygons with
non-intersecting interiors. 

If the example above represents something like a lake with some island
holes then it would be better to name it a polygon instead of a

Perhaps multipolygons should be represented as having multiple
sub-relations as members. Each sub-relation would be a polygon type with
members for the ways forming the exterior and interior rings.

The total number of polygons in the planet dump is quite small. Only
49061 according to the mapnik Postgres DB. The total number of 'holes'
is only 351. I can not count the multipolygons since these are not
currently handled properly by osm2pgsql.

> If you have a better idea of how to do these relations (e.g. put the
> natural=water tag on the relation instead of the ways) then please voice it
> now before we're doing the automated migration.

Taking the mapnik osm2pgsql process as an example. The code would need
take each relation and lookup all the contained ways in order to emit
the appropriate POLYGON() type to the Postgres DB. The code would have
to decide on one set of tags for the whole geometry. These could either
come from the ways or the relation, but having different tags on the
ways could confuse the renderer.

I think we'll end up with tags on both the ways and on some relations
e.g. multiple buildings and some car parks might make up some relation
describing a particular site. The tags on the site relation may be of no
relevance to the rendering of the individual polygons. Perhaps the rules
need to be defined for each specific relation type.


More information about the dev mailing list