[OSM-dev] amazon AMIs for a full blown openstreetmap.org-like server

[jamesmikedupont at googlemail.com]

I dont know all the details of mapnik, but from what I have seen,
using the postgres database is not needed in all cases.
I am thinking about


> I would find it difficult to believe that with for example a memorymapped
> file, that allocates for example 4k for a node would outperform a database
> method. I would see a better future in automatic analysing a stylesheet,
> determing enums, and using databases.

Well you mean a 4k page in memory. But you dont need to have all that
data memory mapped.
It could be just 4k of data on disk in an array. It could also just be
a tiny osm file that is parsed when needed.


>> It will depend on your architecture, but I think on a distributed
>> system where you have many processors,
>> that lots of files , if connected to the processors will work well.
>> Ideally you would have a set of processors to deal with a set of data
>> and any requests would come to them and the whole thing would be in
>> cache all the time...
>
> That would assume a big disk cache. For NL, it would be theoretically
> possible to use multiple renderd instances out of the box. But that would
> require to run renderd on an TCP/IP socket, instead of a Unixsocket.
>
> In my perspective the query time can be reduced anyway significantly if we
> want it. Mapnik is much harder to optimise, unless you want to go GPU
> accelerated rendering.

Well again, I have not really gotten into mapnik. But I can.

But lets try and define the problem as rendering an osm file to a
tile. That osm file is updated , and rerendered.
All the data needed to render is just stored in osmxml in a nice
sorted way. You never need all the data at once because you only
render a tile at a time.

I think that you could optimize some... there are ways to store that
data so it is just copied into memory and does not need parsing.. you
could use shared memory as discussed before to store the tiles....

but you dont need a full postgres database functionality, you just
have very basic update of pages of data.

I think that a multile user postgis is a bit overkill for a simple
rendering process...

or am I missing something, cause I have not looked at the code in detail.

mike