[OSM-talk] Osmarender 3.0

[Wollschaf]

On Thu, 28 Sep 2006 12:09:33 +0200, Thomas Walraet wrote:

>>>     Or would this hit the API too much?
> This is the sort of things that could run on another server from the
> weekly planet.osm

I agree on that. The live map needs to be fast and - even more important -
each tile (or in this case cached area) has to fit the next one. I think
it is far easier to have two map servers:

- one for the general public, updated on a daily basis. Read-only DB, fast
access, perhaps filtered data (things the map renderer cannot display can
be left out; Optimizations that speed up client-side rendering can be
done).

- one for developers and mappers, a bit hidden (in the wiki). This one
could use direct access to the database, accessable only with login - and
because of much less users, even work without caching.

The SVG map needs to be faster than the current osmarender interface,
though. I appreciate the beauty of the osmarender approach, but I'm not
sure if the slippy map for the general public should use the in-browser
conversion (because it's slow for dense areas). Especially for older
computers, this is a serious problem because SVG rendering alone takes
much time.

It might be best to generate (and optimize!) the SVG on the server and
store it in the database, instead of just shoveling OSM data around.
Perhaps I'm wrong and the conversion takes only a small percentage of the
time it takes to render the SVG. I can not measure that.

The developer map should use Osmarender, because speed does not matter
that much in this case, and tweaking can be done in real-time.

Wollschaf