[OSM-talk] Topology (was: OSM the mediocre alternative)

[Frederik Ramm]

Hi,

 > OSM uses topology as its base storage. Topology is good for making
 > graphs, which is important when you need to do routing. For this
 > reason, (it seems to me) that OSM was built towards the goal of
 > creating driving directions. Great.

Until now I was a big fan of topology and thought it was not only a 
requirement for routing or other logical analysis, but also richer in 
information.

If you have a junction described in "features", what you get are two 
roads that somehow happen to meet in one place (two lines crossing, or 
meeting). Right? In terms of storage, both lines will usually have their 
own coordinates in the data base; the information that they intersect, 
or meet, is not there explicitly, it just comes from the maths applied 
when drawing them, and if your database has spatial support you can ask 
the database for the point where they intersect.

However if someone wants to move that intersection, he will have to edit 
each feature separately - if you move one road away from the junction, 
then the junction is no more.

This is not a problem in read-only environments like the interim PostGIS 
database created for Mapnik rendering - nobody can move a node there. 
But in our live data we need the functionality, and we cannot allow a 
junction to cease to exist just because one of the roads is moved a bit.

How would you deal with things like that in FeatureServer, or any 
feature-based approach? Would you not have to add a topology component 
to allow editing without accidentally breaking stuff?

Jochen and I tried to outline the probem in our paper with suggestions 
for a new data model (here: 
http://www.remote.org/frederik/tmp/towards-a-new-data-model-for-osm.pdf, 
it was meant as an input for Essen and hasn't been changed since but the 
stuff about topology is still valid).

As far as I understand, Oracle actually has a database that has combined 
GIS and topology support, and PostGIS tried to add it but hasn't 
succeeded yet (albeit I heard that they're still working on it).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'