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

[Frederik Ramm]

Hi,

the.promenader at gmail.com wrote:
> I am extremely interested in the development of "Areas" in OSM - it
> seems to me to be an OSM lacking/logical necessity - yet there seems
> to be little discussion on the matter. Could we exchange some ideas
> on the main article's
> (http://wiki.openstreetmap.org/wiki/The_Future_of_Areas) discussion
> page? 

I would prefer to use the mailing list for discussion.

> I'd really like to learn more about what it would take to
> implement this sort of schema, and what effect it would have on the
> existing system.

This entirely depends on which schema one would choose. For example, if 
one were to choose the simplest version, where we have an area datatype like

<area>
<nd ref="1"/>
<nd ref="2"/>
<nd ref="3"/>
</area>

that is entirely built on nodes, the effect would probably be:

1. For the rails backend - implement new model and controller classes, 
create new database tables (or choose to re-use way tables for this and 
add an area flag...)

2. For osm2pgsql-based rendering systems - modify osm2pgsql to process 
area datatype properly.

3. For editors - add support for area datatype. For most editors this 
will probably be a relatively small change, even cleaning up code, since 
they already have some sort of internal distinction between 
ways-that-are-areas and ways-that-are-lines.

4. For everyone else - cope with a new data type in the XML; this would 
e.g. commonly used programs liike Osmosis, mkgmap, and a whole bunch of 
other tools.

(And note that the schema I have chosen here is not even one that gets 
rid of multipolygon relations - that might add extra complexity.)

A big question would be the transition from the old model to the new, 
things like:

a) For how long will the central database have to be offline to perform 
the change?

b) How exactly will we transform old-style areas into new-style areas? 
Can object history be preserved (very desirable!), and if so, how?

c) Can we offer some sort of proxy or converter that, for a limited 
time, makes our data available in a synthesized old format so that 
utilities that do not understand the new format can continue to work?

...

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"