Hi,
[email protected] 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 [email protected] ## N49°00'09" E008°23'33"
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev