Hi,
I have roughly implemented approximate reprojection. It should work
for GDAL and GRASS, I have not tested WMS. Currently it is always
using approximation (even if error is too big).
Rendering with reprojection takes about 5 times more. You can get
some info about times grepping debug output, e
Hi Radim
> Why do you consider it problematic, because it occupies too much space?
> Regarding precision, int to double is OK, I believe, but long to
> double is not because double has only 52bits to store mantissa. GDAL
> however does not define long,
> the longest integer is GDT_Int32
My concer
On Tue, Jan 18, 2011 at 9:19 AM, Marco Hugentobler
wrote:
> oops, that should be 'Agreed, int to double conversion could be problematic'
Why do you consider it problematic, because it occupies too much space?
Regarding precision, int to double is OK, I believe, but long to
double is not because
> What about an approach where the out-of-bound values are assigned the last
> value only if reprojection is used (and if the layer does not have a null
> value)?
My two cents, from a user perspective.
We're facing this dilemma with Geotools, where reprojected color mapped
rasters (thorugh SLD) re
> Agreed, int to double conversion could be optimal.
oops, that should be 'Agreed, int to double conversion could be problematic'
Am Dienstag, 18. Januar 2011, um 09.19:23 schrieb Marco Hugentobler:
> > I thought that if data type of the source is integer the provider
> > could represent them as
> I thought that if data type of the source is integer the provider
> could represent them as floating point. Byte can be represented as
> integer. Bad solution however.
Agreed, int to double conversion could be optimal.
What about an approach where the out-of-bound values are assigned the last
On Mon, Jan 17, 2011 at 10:06 AM, Marco Hugentobler
> Using NaN sounds like a good idea
and Qt has platform independent support for
> it (qIsNan & co.).
> All other solutions I can think of seem to be more complicated (e.g. force a
> transparency value only if raster is reprojected).
>
>>float + N
Hi Radim
Using NaN sounds like a good idea and Qt has platform independent support for
it (qIsNan & co.).
All other solutions I can think of seem to be more complicated (e.g. force a
transparency value only if raster is reprojected).
>float + NaN for byte/int?
This is not clear to me. Could yo
Or we can just use NaN for float/double and float + NaN for byte/int?
Radim
On Sun, Jan 16, 2011 at 11:29 AM, Radim Blazek wrote:
> On Thu, Jan 13, 2011 at 9:04 AM, Marco Hugentobler
> wrote:
>> With one of my favorite test dataset, I noted a problem with automatic
>> assignment of nodata value
On Thu, Jan 13, 2011 at 7:06 PM, John C. Tull wrote:
> You might want to sync the branch to current trunk, although that could
> create new problems I suppose.
You are right, I should merge trunk more frequently.
> Not surprisingly, the raster transforms can be very costly with large
> dataset
On Thu, Jan 13, 2011 at 9:04 AM, Marco Hugentobler
wrote:
> With one of my favorite test dataset, I noted a problem with automatic
> assignment of nodata value and automatic insertion into the transparency list.
> In that case, the raster is a colortable map (byte) and has no nodata value.
> So 25
Hi Radim,
Turning off python bindings got it to build. Jürgen pointed out this patch from
last month that fixed that particular build problem:
http://trac.osgeo.org/qgis/changeset/14988
You might want to sync the branch to current trunk, although that could create
new problems I suppose. I appl
On Thu, Jan 13, 2011 at 9:04 AM, Marco Hugentobler
wrote:
> The approximate reprojection would be cool. Wouldn't it be better to implement
> it on rasterlayer level instead instead of QgsRasterDataProvider::readBlock?
> Like that, all providers would have reprojection capabilities (e.g. GRASS
> to
Hi Radim
> Hi Marco,
> the code is quite ugly at moment, I still keep old pieces of code
> commented.
That's fine. Like that, I won't get completely lost in the code :-)
> Regarding the reprojection, I would like to implement the approximate
> reprojection (similar to mapserver you showed me) i
Hi, thanks for testing.
Unfortunately I have no idea. QSet is not used in the code I touched.
I don't know much about Python bindings.
python/core/conversions.sip is generated somehow automaticaly?
Does it need to updated?
Radim
On Thu, Jan 13, 2011 at 4:53 AM, John C. Tull wrote:
> Hi Radim,
>
Hi Radim,
I tried building today on OS X. The build failed with the following output:
...
[ 20%] Building CXX object
src/analysis/CMakeFiles/qgis_analysis.dir/qgsrastercalcparser.cpp.o
Linking CXX shared library libqgis_analysis.dylib
[ 20%] Built target qgis_analysis
[ 20%] Generating analysis/s
Thanks for testing and sorry for inconvenience,
indeed , the callback function was left in raster layer, I have
commited temporary fix.
Later we have to add signals to providers.
Radim
On Mon, Jan 10, 2011 at 8:16 PM, Alexander Bruy
wrote:
> Hi Radim,
>
> I try to build raster providers branch o
Forgot to say, I use r15013
--
Alexander Bruy
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Hi Radim,
I try to build raster providers branch on Windows with MSVC Express 2008
against dependencies from OSGeo4W (gdal 1.7.3) and get next error:
Linking...
Creating library
D:\devel\raster\build\src\providers\gdal\RelWithDebInfo\gdalprovider.lib and
object D:\devel\raster\build\src\prov
Yes, it is. I've told the same to the Geotools guys ;)
Nice because during holidays you remembered me about the approach Mapserer
uses, and again I was wondering if it will ever be abopted in Geotools...
Here it is :)
giovanni
2011/1/10 Martin Dobias
> On Mon, Jan 10, 2011 at 9:49 AM, Radim Bla
On Mon, Jan 10, 2011 at 9:49 AM, Radim Blazek wrote:
> Hi Marco,
> the code is quite ugly at moment, I still keep old pieces of code commented.
>
> Regarding the reprojection, I would like to implement the approximate
> reprojection (similar to mapserver you showed me) in
> QgsRasterDataProvider::
Hi Marco,
the code is quite ugly at moment, I still keep old pieces of code commented.
Regarding the reprojection, I would like to implement the approximate
reprojection (similar to mapserver you showed me) in
QgsRasterDataProvider::readBlock and overwrite it only in WMS
provider. GDAL warp is too
Hi Radim
Nice to see you are making good progresses with raster redesign!
Please give the dev team a bit time to review all the changes. I'd like to
have a closer look at the code. However, it's my first day back at work, so it
could take a few days until I can give feedback.
Regards,
Marco
A
Il giorno sab, 08/01/2011 alle 20.26 +0100, Radim Blazek ha scritto:
> Please test the raster providers branch and let me know about problems:
Packages are available for Debian unstable at the page:
http://int.faunalia.it/~paolo/qgis_raster/
All the best.
--
http://www.faunalia.it/pc
__
On Sun, Jan 9, 2011 at 1:56 PM, Jürgen E. wrote:
> The error excerpt is a bit short, don't you think? That happens when you
> build
> with python bindings. The debian packaging doesn't cause this.
>
> Anyway fixed in r15008. I accidently committed debian/control myself this
> time, but that sh
Il giorno dom, 09/01/2011 alle 13.56 +0100, Jürgen E. Fischer ha
scritto:
> The error excerpt is a bit short, don't you think?
Sorry, I couldn't find anything interesting before or after that.
> That happens when you build
> with python bindings. The debian packaging doesn't cause this.
>
>
Hi Paolo,
On Sun, 09. Jan 2011 at 13:04:27 +0100, Paolo Cavallini wrote:
> Il giorno sab, 08/01/2011 alle 20.26 +0100, Radim Blazek ha scritto:
> > Please test the raster providers branch and let me know about problems:
> >
> > svn co https://svn.osgeo.org/qgis/branches/raster-providers
> I tri
Il giorno sab, 08/01/2011 alle 20.26 +0100, Radim Blazek ha scritto:
> Please test the raster providers branch and let me know about problems:
>
> svn co https://svn.osgeo.org/qgis/branches/raster-providers
I tried to package it, to make wider testing easier, but failed:
make[1]: *** [all] Error
Hi all,
new raster providers are ready for testing. The work is not yet
finished but all the old functionality should be available. Current
status:
- GDAL: on-the-fly reprojection via gdal warp, quite slow, I have not
yet implemented the trick used in Mapserver Marco pointed me to.
Please let me k
Hi
On Mon, Nov 15, 2010 at 1:46 PM, Radim Blazek wrote:
> JFYI, news in raster-providers branch:
> - raster providers interface extended to support data values (instead
> of pictures)
> - gdal staff extracted to separate provider
> - grass provider modified to serve data values
> - wms switched f
JFYI, news in raster-providers branch:
- raster providers interface extended to support data values (instead
of pictures)
- gdal staff extracted to separate provider
- grass provider modified to serve data values
- wms switched from draw() to readBlock() passing picture as ARGB data
type block
The
31 matches
Mail list logo
