[OSM-talk] Segments, ways and order

Nicola Ranaldo ranaldo at unina.it
Tue Jul 31 21:18:48 BST 2007

On Friday 20 July 2007 01:35:03 Lars Aronsson wrote:
> On Monday July 16, Matthias Julius wrote:
> > Another solution would be to do away with segments and have ways
> > reference nodes directly. (I know this has been discussed before
> > and a transition would not be trivial.)
> This is a myth that we have to kill.  Some seem to believe this
> would be a good idea, a kind of utopia, but assume the change-over
> would be too hard and so nobody dares to try it.  I'd like to
> challenge the latter assumption.
> What you actually can do is to download the planet.osm, convert it
> to some other schema, populate your own database and build some
> application on top of that -- maybe a smarter tile renderer.  You
> don't have to change OSM's central database to try the idea.  If
> there are any important improvements in performance or otherwise,
> such a conversion should be able to demostrate this.

Actually if you want to get from api motorways in UK, you have two methods, 
the first is to get all nodes from UK, all segments connecting those nodes, 
and all ways belonging to those segments. After that you have to filter ways 
with tags. The second is to get *all* motorways from *all* over the world, 
get all segments, all nodes and finally filter them in the UK bounding box. 
As data are no spatial clustederd this operation is very very slow. With a 
model based on Gis multilinestrings you adopt a GiST spatial index to locate 
fast object in an area. You combine this index with another (tag-based, or a 
special index for highways), and collecting DB statistics the planner may 
choose to use first the gist index and after the second or viceversa. As the 
multilinestring is a "piece" of data in a database tuple, it's pyhisically 
clustered (or less depending on size). This is sufficient to think a 
different model may be better for the central database too. A second issue 
may be in exporting, reusing data. Actually you must have a ram lookup table 
for nodes and segments. This is not  a problem now, but as osm is growing up 
fast i think in the next months it will be a problem. How much it will big 
planet.osm when TIGER, AND, and spanish data will be imported? Ok you may use 
a db to lookup data, but the problems is that the import of planet.osm will 
be slower.
A third issue is about data exchange. If we want to convert osm in shapes to 
use it in other tools we have a problem. Shall we export data in linestrings? 
multilinestrings? multipolygons? Our model permits to have unordered 
segments, renderers reorder them with ways and reorder them very hard with 
areas. To have a consistent export you have to know before if a way is used 
as a way or as an area! As this is based on tags and not on differents model 
objects it seems to be not very much professional.
Adopting a gis model would resolve ordering problem too.

> This is very similar to the population of a PostgreSQL database
> for mapnik tile rendering.

Every week, an export, an import, and so on... again, with a gis model, we can 
use mapnik in near-real time.

just my opinion!


	Nicola Ranaldo

More information about the talk mailing list