maposmatic-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Maposmatic-dev] Outstanding points before releasing MapOSMatic


From: Thomas Petazzoni
Subject: Re: [Maposmatic-dev] Outstanding points before releasing MapOSMatic
Date: Wed, 11 Apr 2012 09:35:34 +0200

Le Wed, 11 Apr 2012 09:28:16 +0200,
David MENTRE <address@hidden> a écrit :

> >  * Many translations are still out of date, though I will not
> > consider this as a blocker for the release. See attached file for
> > the current status of the translations.
> 
> Yes, this is non blocking.

Agreed.

> >  * Gaël patches on the scale problem has also changed significantly
> > the scale of booklets.
> 
> Non blocking for me. Of course we should fix that but we should not
> target a perfect release.

To me, it is. As is, the booklets generates way too many pages for a
given geographic area, which makes them quite useless. As shown by my
example, the number of pages required to render Chavagne has almost
doubled (from 16 pages to 28 pages).

The reason why the rendering of Paris is exhausting our timeout is
maybe also because the number of pages has almost doubled compared to
the previous rendering I did of Paris. For the record, on my previous
rendering of Paris, 78 pages were needed to render the map.

> >  * The automated updates of the planet database have stopped, and we
> >   don't know how to start them again. We have hit the period during
> >   which the OSM database was read-only and things seem to have
> > changed with regard to the upgrade process. So our replication lag
> > is growing again, and we don't know how to fix it,
> 
> This one is a real issue I think.

I have been talking about that just this morning with people on #osm.
They gave me some hints on how to continue the database update.

However, apparently, we will no longer be able to continue to do
incremental updates with our CC-BY-SA database. Once they will have
switched to ODBL (in the coming days/weeks), they will stop releasing
incremental updates for the old database, and we will therefore have to
do a new planet import. So it looks like we'll have to do a new full
planet import in the near future (but maybe we can start this import on
gcc10 while we run the production site on gcc20).

> >  * The MapQuest stylesheets on the server are broken.
> 
> I think this is non blocking. We can even deactivate this style sheet,
> and reactivate it once it is fixed.

Well, having multiple stylesheets is one of the new features of
MapOSMatic v2, it would be a shame to disable the MapQuest stylesheets
and have only the normal OSM stylesheet and our own printable
stylesheet.

> >  * We have a regular Out-of-memory issue on the rendering server,
> > but unfortunately, the kernel seems to be unable to kill the
> >   memory-hungry process and simply crashes the VM. This is the
> > reason for the last 2/3 outages of the maposmatic.org site. A
> > potential solution would be to start the rendering daemon with a
> > fixed ulimit so that the process gets killed when it consumes too
> > much memory.
> 
> This is also a blocking issue. Hopefully the memory issue is related
> to our rendering daemon. Let's try the ulimit approach.

I hope too.

Regards,

Thomas
-- 
Thomas Petazzoni                http://thomas.enix.org
MapOSMatic                      http://www.maposmatic.org
Logiciels Libres à Toulouse     http://www.toulibre.org
Embedded Linux                  http://www.free-electrons.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]