scaling issue question

Bernhard Reiter bernhard at intevation.de
Fri Aug 14 11:00:49 CEST 2009


Am Donnerstag, 13. August 2009 14:12:33 schrieb Didrik Pinte:
> Wouldn't it be interesting to split the problem in two ?
>
> First, there is a user experience that make thuban looks buggy. You zoom
> and it does not. So we should solve it and it is quiet simple.

Yes, this is something that should be fixed one way or the other.

> Second, there is this artifacts problem at high scale. IMHO I would try
> to let the graphical toolkit manage it. I have to admit that looking at
> the code, I do not clearly see how we could prevent drawings that create
> artifacts. We could simply add a check to have all the (x,y) being int16
> values (wxproj.cpp and baserenderer.py would the only point to check).

In general this used to be a speed vs. ease of implementation issue,
you cannot simply have unlimited zoom level and a small data representation
and fast processing at the same time.

When I thought about it last time I guess I wanted to introduce buffered 
layers with already projected coordinates to speed up thuban. So once you are 
changing the zoom level too much, you will need a new calculation which is 
more costly.

Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20090814/f0d9d3aa/attachment.bin


More information about the Thuban-devel mailing list

This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)