We have a development server running on a database holding the whole planet (as of today). Besides requiring 9h/day to keep the DB updated, the following usage issues arise on that “planet” development instance:
- looking up an administrative name such as “Paris” takes ages (typically 2 to 5 minutes). This is not really great: the rendering jobs are queued, but such queries are not queued and will run in parallel. Besides, we should not ask the user to wait 2 to 5 minutes before the server confirms that it’s queueing her rendering
- when rendering (ie. ocitysmap), finding out the city limits/boundaries of a city takes ages too. This is probably due to the same “feature” as above, but this time the problem is less critical as we are in the “qeueued” side of the force
- in overall, the whole rendering process takes around 8 times longer with a DB holding the planet, than with a DB holding just France. This was measured on “Rennes”: 10mn rendering vs. around 1.25mn.
The “funny” thing is that both the “mapnik” and street index rendering don’t seem to be that slower, but this needs to be confirmed by a more thorough profiling. If this proves correct, we have to find out what makes PostGIS so slow for the first queries. Is this our queries ? The structure of the DB which is lacking a few indexes ? And, in that case, how come mapnik rendering + street index seem almost as fast: is this because the previous queries did put most things in cache ?
But what a great pleasure to be able to map NYC, Palo Alto, !…
-
- Manhattan, NY
-
- Palo Alto, CA
-
- San Francisco, CA
Unfortunately, this will be our privilege, since we are decidedly not planning to open this to the public… for the time being, that is: with our current server (a “modest” dual core x86_64 2GHz / 2GB RAM). Donations or support for a new server are welcome !