[MapProxy] <Ext> Re: MapProxy OSM Configuration Question

[Paul Todd]

Yes Imposm :)

We are limiting the  -c option for mapproxy-seed to 1 for now and we are still running out of memory.  MapProxy doesn't appear to be the offender.  We seem to be running out of memory on the mapserver/postgresql side of things.  I'm wondering if you or others may have suggestions on the best strategy to seed a large area like this?  We don't have a lot of experience with this and I'm thinking that we may just be trying to seed to large a coverage at once.

Thanks for the tip on the reprojection.  That sounds like the issue we are experiencing.

Thanks!

Paul


-----Original Message-----
From: Oliver Tonnhofer [mailto:olt at omniscale.de] 
Sent: Friday, August 17, 2012 12:15 AM
To: Paul Todd
Cc: mapproxy at lists.osgeo.org
Subject: <Ext> Re: [MapProxy] MapProxy OSM Configuration Question


On 17.08.2012, at 02:02, Paul Todd wrote:
> I've been setting up an Ubuntu 10.04 OSM Mapserver with the planet loaded from IMPOSM.  We want to use MapProxy to cache the first several layers and are running into a few issues.  This is a reasonably big machine with 32 GB ram and 4 cores; 6 TB raid.


You mean Imposm? ;)
 
> 1)      Issues seeding low zoom caches - performance is pretty poor in general for low zoom levels using MapServer directly; however it still appears to work and render very nice transparent PNGs
> a.       We've divided the world into 4 caches to help split up the seeding job

You know about the -c option of mapproxy-seed?

> b.      When trying to seed these levels using the MapProxy seeder some areas work, other cause the system to run out of memory and kill the process (oom-killer)
> c.       We've tried seeding using WMS source and MapServer source; same issues either way.

What process gets killed? MapProxy? How much memory does MapProxy(-seed) use (top)?

> 2)      The PNGs served by MapProxy do not have nearly the quality that MapServer does.  The tiles that are cached in 900913 on the server look great but the client requests them in 4326 and the reprojection looks jagged.  We switched it to 24Bit PNG using the modified PIL that the MapProxy documentation suggested and it looks better but not as good.  However I would expect that using the modified imaging library we should be able to use 8 bit PNGs and get good results.

Reprojection works good for 900913 to UTM for example, but the difference between 900913 and 4326 is too large. You should create a dedicated cache for that if you need to access 4326. 



Regards,
Oliver

-- 
Oliver Tonnhofer    | Omniscale GmbH & Co KG    | http://omniscale.de
http://mapproxy.org | https://github.com/olt    | @oltonn