[OSM-dev] proposal to kill areas

[Lars Aronsson]

Andy Robinson wrote:

> So my belief is that OSM only needs to find a simple way of 
> defining the container,

And then we just add an object-relational database engine, some 
Ruby on Rails and AJAX and the rest of the software automatically 
writes itself by feeding part 37 of Knuth's "Fundamental 
Algorithms" through an XSLT transformation.  Or what?

I believe that the more general you aim the solution to be, the 
more implementation problems you will have. You'll have to deal 
with performance and scalability issues (not mentioned in Knuth!) 
and complexity and that last little bug that turns out to hide 
deep inside that object-relational engine.  Instead of building 
the fully generic container solution, I propose things are kept 
extremely simple, providing slightly less functionality than we 
relly need.

I don't need areas right now.  I can be productive with the 
current solution, drawing linear roads the next three years, if I 
can afford the petrol.  Steve's proposed change sounds like 
simplicity, so I'm all for that.  What I'm turning against is 
these dreams of the fully general system that can do everything.

By the way, I'm convinced that it's the Landsat background images 
that take a constant 1.20 seconds of every tile generation.  I 
think tiles without Landsat backgrounds can be generated in 0.60 
seconds by our current hardware and software.  That is 3 times 
faster than the 1.80 seconds or more per tile we are seeing today. 
If that's correct, only improving the OSM API and SQL will never 
bring any real speed to tile generation.


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