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

[Frederik Ramm]

Hi,

On 05/09/11 11:36, Jukka Rahkonen wrote:
> 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.

Roughly like this:

http://wiki.openstreetmap.org/wiki/The_Future_of_Areas/Areas_on_Ways

> 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.

That would, in an OSM scenario, happen e.g. in an osm2pgsql database, 
where osm2pgsql takes care of updating the geometries when primitives 
are updated. It isn't done by a database trigger - I guess it could be 
but who likes triggers anyway ;)

> 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.

It would be very hard to implement that OSM server-side. Firstly we're 
not storing geometries (we use Postgres without PostGIS) at the moment. 
Secondly, this would effectively mean that every single "move a node" 
operation would trigger a "list all ways that use this node, then list 
all area relations that use one of these ways, then compute polygon, 
then check if valid" operation. This would probably make node location 
updates very expensive in terms of computing time (especially when a 
node is part of a way that is part of, say, the "Germany" boundary or so).

> 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.

I've thought about that too, and for a while we had a huge polygon file 
on the Geofabrik download server that was essentially a SQL dump 
containing all the polygons. Not the most user-friendly version to do 
it, we'll have to think of something better ;) but it would not need to 
be part of the core service, it could be done separately.

> 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

If one likes GML, that's certainly a possibility ;)

Bye
Frederik