[OSM-dev] proposal to kill areas
lars at aronsson.se
Sat Jul 22 23:44:43 BST 2006
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
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
More information about the dev