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

[the.promenader at gmail.com]

The transition would be a stickler for sure. I think the best thing to do would be to a) define the new schema in a concrete way, b) create a new dataset with data 'translated' from the old version c) 'freeze' the old dataset (no new contributions there) and d) have both run parallelly to give end users time modify their rendering software to the new version. All the same, ouch.

On Apr 25, 2011, at 11:30 , Frederik Ramm wrote:

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