[OSM-dev] "The Future of Areas" - open discussion?

Jukka Rahkonen jukka.rahkonen at latuviitta.fi
Mon May 9 10:36:57 BST 2011

Frederik Ramm wrote:

> Stefan Keller wrote:
>> Right. In fact - it's currently a programmers nightmare: It took us in
OSM-in-a-box several months of development.
>> I already argued earlier for an own geometry type. I proposed (and
still do) to choose the "Simple Features" geometry schema from OGC.
> This roughly translates to
> http://wiki.openstreetmap.org/wiki/The_Future_of_Areas/Areas_on_Nodes
> and would have the disadvantages listed on that page (e.g. no re-using
of edges; difficulties in handling very large polygons).

I do not know if there is anything reusable, but we are using a mixed
solution in one production system. The system is handling land parcels and
natively polygon geometries are stored as a set of linestrings (elements),
mainly because it is not enough to give all the attributes for a polygon
but the lines must carry some own attributes as well. Linestrings are
identified with entity-ID.

Polygons are formed from the linestrings through a middle table. Polygon
table contains polygon-IDs and the attributes which belong for the polygon
features. The middle table is taking care of handling the many-to-many
relationships by connecting polygon-IDs with entity-IDs. In our case we
are building a network of polygons belonging to a same layer and therefore
the many-to-many relation is restricted so that a polygon can consist of
however many linestrings but one linestring can belong only to one or two

In addition to these native relation based polygons we have them also as
true polygon features. Polygons are created automatically from the
linestrings by a database operation. Polygons are automatically updated if
the lines are edited and topology checks are preventing the operation if
edits would lead to a non-valid polygon topology.

As a result we have parcels in the database both as linestring collections
and true polygons. In vast majority of use cases we are utilising only
polygon geometries. Sometimes we include also the lines as a separate
layer either for visualization or because we need to do some queries by
the line attributes and not only by polygon attributes.

What might be reusable in OSM is the idea of building the polygon versions
of area objects as early as possible and serve them for the end users from
the OSM infrastructure. It would not be necessary to have true polygons in
the main database but there could be some data warehouse service or
something in the middle. After having ready made polygons available there
would be no need to implement the complicated polygon handling into every
single client. Internally OSM could continue to handle the polygons in
whatever way but only OSM data editors should be aware of that.

This link offers entertaining reading about handling OSM polygons on the
client side

It should not really be so complicated. It should rather be something we
can do now by ordering a thousand ready interpreted OSM polygons from a
WFS service

-Jukka Rahkonen-

More information about the dev mailing list