[OSM-dev] getnodes query optimization

[Lars Aronsson]

Christopher Schmidt wrote:

> (The 'order by nodes.timestamp' probably makes a difference, but most
> apps should hopefully not depend on the order of nodes.)

We had exactly this question on the table some months ago.  I 
think the trick here is to get the most recent (current) version 
of each element.  Editing history and current versions are stored 
together. Try your query on some area were nodes have been moved 
around, so that they have a history.  Just loading the planet.osm 
dump doesn't help, because that dump contains no history.

Storing current versions together with history is a mistake in 
itself.  History should be kept away in a separate ("archive") 
table, to speed up everyday operations on current data.  But now 
you were asking about the retrieval query, not the table 
structure.

Then again, if we were to reorganize the database, it probably 
would make sense to switch from line segments to polylines and 
PostGIS.  So far, the reason against is that PostGIS doesn't 
natively handle editing history, because it was designed for 
traditional GIS, not for a map wiki.  If you are going to propose 
this change and be successful, you have to come from inside the 
wiki world.  GIS experience is not enough.  People won't listen.

While I'm dissenting the current technical platform, I'm focusing 
on gathering more line segments for Sweden.  Without the data, it 
doesn't matter what data structures or algorithms we use.  With 
the data, we can change the structure and algorithms later.


-- 
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se