[OSM-talk] Segments, ways and order
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
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!
More information about the talk