[OSM-dev] all things to all people

Tom Hughes tom at compton.nu
Tue Apr 22 14:59:56 BST 2008

In message <480DE97B.8090609 at frankieandshadow.com>
        David Earl <david at frankieandshadow.com> wrote:

> On 22/04/2008 14:21, SteveC wrote:
>> Really, the existing boxes should be throwing out as many tiles and  
>> API calls as possible. We should buy a new box for export and it  
>> shouldn't be a priority in terms of memory, disk, uptime etc.
> I agree. I think the functionality is great in principle, just what I 
> would have liked to have had for doing some of the printed maps I've 
> done, but looking at again, for serious use I really think I'd need to 
> get larger areas - not massive, but more than the load would bear at 
> present.

The area limit is not really to do with load as such, at least for
the mapnik interface. It is partly memory, as rendering a large area
at high resolution uses a reasonable amount of memory. It is also in
part just that doing anything with the result is virtually impossible
if you render larger areas - you can go a bit bigger but it quickly
starts to get vary hard to do anything with the files.

The current limit for mapnik is a 2000x2000 pixel image (or equivalent
area) and once you get to 4000x4000 even a dual core machine with 4G
of memory struggles to render the resulting PDF or SVG.

> That doesn't mean the interface can't be where it is now, but instead of 
> doing it there and then, it could queue the job and process them one by 
> one and offer a URL to check for completion. (Logged in users could pick 
> them up from their user account pages, using RSS and/or get an email 
> sent to them).

I explained in an email yesterday why I choose not too add queueing
functionality at the moment.

Implementing queueing makes the whole an order of magnitude more
complicated and raises all sorts of questions, especially when the
work is (more or less by necessity) distributed over different 
machines depending on the format.

> This would then allow us to serve larger areas, which will be much more 
> useful than what's there now.

The major requirement for rendering large areas with mapnik is memory
and queueing doesn't help much there beyond ensuring that you only have
one job running at a time.

> One of the GSOC projects is a 'make me a map' online application, yes? 
> This will have the same load problems presumably, but it could use the 
> same queue, you just get a more customized map at the end.

Ah... I'd forgotten about including some sort of "embedded map" export
option... That was always in my plan somewhere.


Tom Hughes (tom at compton.nu)

More information about the dev mailing list