On Sat, Mar 26, 2011 at 9:29 PM, Giovanni Manghi
<giovanni.manghi@gmail.com> wrote:
It works pretty good with *non* GRASS rasters, while with GRASS rasters
is very slow (on Windows, acceptable on linux)
Explanation for GRASS list: he is talking about "Value tool" which is
displaying a raster value under cursor.
In the GRASS provider, I have followed the recommended use of GRASS in
applications, that means, if a value on certain pixel is requested, it
runs GRASS module (executable) with coordinates as parameter and
receives a value from stdout.
If a user moves cursor over the whole map, it may run the GRASS module
some 1000 times on medium size screen. If there are 10 maps open in
QGIS, it starts 10000 executables in about 1 second. That is probably
a bit slow.
We could add some delay in the Value tool plugin to avoid too many
requests, but that is not solution if the values have to be logged
somehow, for example to draw a chart.
It seems that instead of running the GRASS module each time, we have
to keep it running and send coordinates to the module via stdin.
Can GRASS developers give us any suggestion how to solve this?
If there are 10 maps open in QGIS, it starts 10000 executables
in about 1 second. That is probably a bit slow.
maybe a little
I do not suggest this as a correct solution, but fyi r.what can
take multiple input maps in a single call. It can also take
multiple input coords in a single call, so you can at least
queue you queries into bigger sized chunks if you like, which
would ease the pain a little.
as a long term solution, would a from-scratch LGPL native GDAL
driver help? ... Possible Summer of Code project for someone?
On Mon, Mar 28, 2011 at 9:38 AM, Hamish <hamish_b@yahoo.com> wrote:
Radim wrote:
If there are 10 maps open in QGIS, it starts 10000 executables
in about 1 second. That is probably a bit slow.
maybe a little
I do not suggest this as a correct solution, but fyi r.what can
take multiple input maps in a single call.
That is impossible in QGIS, where the functionality is implemented in
data providers, one per layer, which know nothing about other layers.
It can also take multiple input coords in a single call, so you can at least
queue you queries into bigger sized chunks if you like, which
would ease the pain a little.
Maybe, but probably source of other problems, because it has to be
implemented in GRASS provider, and that means to add a little delay to
find if there are more values requested and that is not desired for
all tasks.
BTW the Value Tool with WCS via GDAL or WMS in QGIS (currently
disabled right?) could also be interesting, anybody tested? Does GDAL
WCS cancel running requests if another comes? Does it keep list of all
opened requests with an id?
as a long term solution, would a from-scratch LGPL native GDAL
driver help? ... Possible Summer of Code project for someone?
Do you mean de facto new GRASS raster library? Thread safe, exceptions
support etc... That could help.
On Mon, Mar 28, 2011 at 10:12 AM, Jürgen E. <jef@norbit.de> wrote:
Hi Radim,
On Mon, 28. Mar 2011 at 09:31:24 +0200, Radim Blazek wrote:
Can GRASS developers give us any suggestion how to solve this?
Wouldn't it be possible to do the request on the cached image of the last draw
request?
That would be possible. Do you mean a cache on driver level? Is it a
cache used in QGIS for rendering somewhere at this moment? Is it
desired? 1000x800x8 = 64MB / layer, 10 layers ~ 0.6GB. What about
threads (map composer, globe)?
Rasters in fact, are not drawn as a single block, the picture is split
into more pieces, and that would also complicate caching.
Radim
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
--
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
If there are 10 maps open in QGIS, it starts 10000 executables
in about 1 second. That is probably a bit slow.
Hamish:
> It can also take multiple input coords in a single call, so
> you can at least queue you queries into bigger sized chunks
> if you like, which would ease the pain a little.
Maybe, but probably source of other problems, because it has to
be implemented in GRASS provider, and that means to add a
little delay to find if there are more values requested and
that is not desired for all tasks.
To be honest I doubt there's much point in queuing a burst of
queries, but a 100-500ms delay between individual queries would
both greatly cut down on the number of process calls and not be
very noticeable to the user. Doesn't totally solve the problem,
but it would help to mitigate it.
what tasks is that not desired for? It can't be restricted to the
mouse-over bits?
> as a long term solution, would a from-scratch LGPL native GDAL
> driver help? ... Possible Summer of Code project for someone?
Do you mean de facto new GRASS raster library? Thread safe,
exceptions support etc... That could help.
Not really, I mean re-writing the GDAL grass6 raster plugin from
scratch to not depend on the existing GRASS GPL libraries.
We want this in place anyway so we change change the raster
format/file structure in GRASS 7 but still allow users to access
old GRASS 6 maps seamlessly using the r.external module (which is
a live frontend to GDAL). Also, it has been a long-time wish to
donate such a thing to GDAL but under LGPL license so that GDAL
could in future have less trouble with competing plugin licenses
(see http://trac.osgeo.org/gdal/wiki/rfc34_license_policy).
If it happened to be tread safe, etc, well, all the better.
