Recent improvements to the editing applet

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Recent improvements to the editing applet

Christian van den Bosch
[moving from openstreetmap to openstreetmap-dev per Mikel's suggestion]

Mikel Maron wrote:
> Good recommendations -- it's worth getting some solid metrics, and determine an optimal tile size. And looking at the load order of tiles, vectors.
>
> I believe the editor/viewer is requesting 5 x 4 tiles, since the bounding box does not overlap the pre-tiling precisely.

Hmmm. Would it be worthwhile moving some of the tile processing into the
applet? Given that at levels of zoom that are useful for editing, tiles
look like they're generated by magnifying and gaussian-blurring tiles
from lower levels of zoom - for higher zoom levels, could the applet
cache tiles from lower zoom levels, and magnify/blur those itself as
appropriate? This should cut down significantly on both CPU and
bandwidth usage on the server, and hopefully make the applet seem more
responsive too.

Feel free to shoot this idea down in flames if it's idiotic :)

Christian / cjb

http://www.cjb.ie/

_______________________________________________
Openstreetmap-dev mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent improvements to the editing applet

Steve Coast
* @ 31/12/05 12:56:30 PM [hidden email] wrote:

> Hmmm. Would it be worthwhile moving some of the tile processing into the
> applet? Given that at levels of zoom that are useful for editing, tiles
> look like they're generated by magnifying and gaussian-blurring tiles
> from lower levels of zoom - for higher zoom levels, could the applet
> cache tiles from lower zoom levels, and magnify/blur those itself as
> appropriate? This should cut down significantly on both CPU and
> bandwidth usage on the server, and hopefully make the applet seem more
> responsive too.
>
> Feel free to shoot this idea down in flames if it's idiotic :)

In theory the applet could grab the points directly. It used to with the
old applet but there are two constraints. Firstly bandwidth, which you
can mitigate with gzip-encoding. The other is that an applet is allowed
some arbitrary small amount of memory and something I ran in to was
java.lang.OutOfMemoryException's with too many (eg a reasonable number)
of points in memory. Even as doubles in a simple array.

If someone knows the size allowances for code / data and whether these
are seperate and change between jvm's...

have fun,

SteveC [hidden email] http://www.asklater.com/steve/

_______________________________________________
Openstreetmap-dev mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap-dev