ärz 2011 09:45
>> An: Ziegler Stefan
>> Cc: ivan.mincik; qgis-developer
>> Betreff: Re: Re: [Qgis-developer] Raster providers
>>
>> Yes, it was explained in one of my previous mails:
>>
>> On Sat, Mar 5, 2011 at 11:21 AM, Radim Blazek
>> wrote:
>> >
On Mon, Mar 14, 2011 at 1:42 PM, Alexander Bruy
wrote:
> Hi Radim
>
> I found some issues with new raster providers (tested on r15453).
>
> 1. Applying a style to layer triggers statistic calculation. If I apply
> one style and then another statistics calculates twice.
>
> 2. In Metadata tab (Laye
On Thu, Mar 31, 2011 at 11:32 AM, Jürgen E. wrote:
> That shouldn't be a problem projectionwise.
>
> It found EPSG:4148 because that has the same projection parameters as
> EPSG:4326
> and the WKT string doesn't have any information about which EPSG is desired.
> Otherwise the description and aut
On Fri, Mar 11, 2011 at 9:35 AM, Giovanni Manghi
wrote:
> What it does not seem to work correctly now is the "zoom to best scale"
> menu in a reprojected image: the raster disappear as QGIS probably try
> to zoom using the wrong crs?
Fixed
Radim
___
Qg
On Thu, 31. Mar 2011 at 11:12:42 +0200, Radim Blazek wrote:
> On Wed, Mar 9, 2011 at 12:24 PM, Giovanni Manghi
> wrote:
> > Regardless their CRS, GRASS rasters are always added to qgis with WGS84 CRS.
>
> For me, QGIS sets CRS to raster's CRS but some info seems to be lost
> in createFromWkt().
>
On Wed, Mar 9, 2011 at 12:24 PM, Giovanni Manghi
wrote:
> Regardless their CRS, GRASS rasters are always added to qgis with WGS84 CRS.
For me, QGIS sets CRS to raster's CRS but some info seems to be lost
in createFromWkt().
GRASS gives:
GEOGCS["wgs84",DATUM["WGS_1984",SPHEROID["WGS_1984",637813
Dnia sobota 19 marca 2011 o 16:57:11 Radim Blazek napisał(a):
> On Wed, Mar 9, 2011 at 12:32 AM, Borys Jurgiel
wrote:
> > Finally! :-) It's impressing. I observe two issues only:
>
> > 2. GDAL TMS layers don't work. I get a warning messageBox:
> It seems to work. I have not done any particular f
On Mon, Mar 14, 2011 at 1:42 PM, Alexander Bruy
wrote:
> 3. On Histogram tab progress bar is inactive during statistics calculation.
> This is a bit confusing especially when raster has many bands
I have added progress signal to GDAL provider. Histogram progress is
updated only when histogram is
On Wed, Mar 9, 2011 at 12:32 AM, Borys Jurgiel wrote:
> Finally! :-) It's impressing. I observe two issues only:
> 2. GDAL TMS layers don't work. I get a warning messageBox:
It seems to work. I have not done any particular fix for this, but it
was possibly fixed by one of many other fixes I have
Hi,
> the problem seem to be incorrect / inconsistent
> handling of geotransforms with positive y-axis
> scale. I have the feeling that at some place the
> raster extent calculation is performed using
> a negative y-axis (probably because the CRS is
> not valid), but some other routines from
> th
Hi Radim,
> That fix is was already superseded by complete
> QgsGdalProvider::readBlock rewrite.
>
> I'll look at it.
the problem seem to be incorrect / inconsistent
handling of geotransforms with positive y-axis
scale. I have the feeling that at some place the
raster extent calculation is perfo
Thanks for testing,
everything added to my list of bugs.
Radim
On Mon, Mar 14, 2011 at 1:42 PM, Alexander Bruy
wrote:
> Hi Radim
>
> I found some issues with new raster providers (tested on r15453).
>
> 1. Applying a style to layer triggers statistic calculation. If I apply
> one style and then
You have already reported that problem and I have already explained
where the problem is.
That is on my list and I'll let you know once i fix that.
I am trying to fix and response all related bug reports.
Radim
On Sun, Mar 13, 2011 at 8:43 PM, Giovanni Manghi
wrote:
> Hi Radim,
>
> just notived
That fix is was already superseded by complete
QgsGdalProvider::readBlock rewrite.
I'll look at it.
On Fri, Mar 11, 2011 at 8:54 PM, Giovanni Manghi
wrote:
> Hi Radim,
>
> unfortunately the "temporary? ugly fix for not georeferenced images", as
> you call in the commit, does not seem to work fin
Hi Radim
I found some issues with new raster providers (tested on r15453).
1. Applying a style to layer triggers statistic calculation. If I apply
one style and then another statistics calculates twice.
2. In Metadata tab (Layer properties dialog) there is no raster
statistics even when it calcu
Hi again,
> just notived that also r.colors have no effect on GRASS rasters.
not totally true. It does not have immediately effect even if you hit
the "refresh" button. But if you remove the raster and then add it again
the new colormap will show ok. Not very handy.
Cheers
-- Giovanni --
_
Hi Radim,
just notived that also r.colors have no effect on GRASS rasters.
Cheers
-- Giovanni --
On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote:
> Merged to trunk.
>
> Radim
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
Hi Radim,
unfortunately the "temporary? ugly fix for not georeferenced images", as
you call in the commit, does not seem to work fine with the
georeferencer.
If you open a non-georeferenced image in the georeferencer it will not
show in the tool window.
Cheers
-- Giovanni --
On Wed, 2011-03-
Hi Radim,
On Thu, 2011-03-10 at 20:13 +0100, Radim Blazek wrote:
> I have changed how GDAL provider reads the data, it should be fast again.
thanks for the fix! it works very well. I tested (under both Linux and
Windows) a 2.7GB image with internal tiles and overviews. It opens in a
blink of an
Jef fixed that by qRound.
Thank you Jef and sorry for various problems I am introducing.
How do you indent the code? If I run scripts/prepare-commit.sh (which
existence I just noticed) it does too many not desired indentations.
Radim
On Thu, Mar 10, 2011 at 11:58 PM, G. Allegri wrote:
> Radim, t
Radim, the round() you added in qgsgdalprovider causes problems for me on
VC++ (
http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp#L664
).
Should we add something like:
#define round(dbl) dbl >= 0.0 ? (int)(dbl + 0.5) : ((dbl - (double)(int)dbl)
<= -0.5 ? (int)db
I fact, I forgot to write a piece of logic, there is a shift.
Radim
On Thu, Mar 10, 2011 at 8:13 PM, Radim Blazek wrote:
> I have changed how GDAL provider reads the data, it should be fast again.
>
>
> BUT! I am not absolutely sure that resampling is perfect and the
> nearest neighbour is alway
I have changed how GDAL provider reads the data, it should be fast again.
BUT! I am not absolutely sure that resampling is perfect and the
nearest neighbour is alway nearest. I dont think however that anybody
could notice that in normal work. I would appreciate however if
somebody with fresh brai
The reason is, that GDALCreateGenImgProjTransformer() does not accept
source data sources which are not georeferenced. As an ugly
workaround, I set the first item in GeoTransform (x offset) to
DBL_MIN. In theory it can cause a shift in georeferencing. I don't
believe however that it could be really
Hi,
On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote:
> Merged to trunk.
I'm testing the new raster capabilities of QGIS and I would like to have
your opinion on a certain matter before eventually filing a ticket.
I have a bunch of big tiff rasters (> 1gb, sometimes > 2gb), with
internal t
Dnia środa 09 marca 2011 o 17:42:08 Ziegler Stefan napisał(a):
> I get some Messageboxes with warnings when adding a TMS [1] with GDAL
> minidriver:
>
> "Cannot ChunkAndWarpImage: Integer overflow: nSrcXSize=8388608,
> nSrcYSize=8388608"
>
> The image is completely black or just fuzzy. OTF is dis
w.gdal.org/frmt_wms_openstreetmap_tms.xml
regards
Stefan
> -Ursprüngliche Nachricht-
> Von: Radim Blazek [mailto:radim.bla...@gmail.com]
> Gesendet am: Mittwoch, 9. März 2011 09:45
> An: Ziegler Stefan
> Cc: ivan.mincik; qgis-developer
> Betreff: Re: Re: [Qgis-developer] Raster providers
&
> -Ursprüngliche Nachricht-
> Von: Radim Blazek [mailto:radim.bla...@gmail.com]
> Gesendet am: Mittwoch, 9. März 2011 09:45
> An: Ziegler Stefan
> Cc: ivan.mincik; qgis-developer
> Betreff: Re: Re: [Qgis-developer] Raster providers
>
> Yes, it was explained in
On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote:
> Merged to trunk.
Regardless their CRS, GRASS rasters are always added to qgis with WGS84
CRS.
Changing manually the CRS to the correct one allows to reproject as
expected.
The region is not reprojected (I don't know if this should be expec
One more crash loading a very large raster.
Warning: QMetaObject::connectSlotsByName: No matching signal for
on_ok_clicked()
Warning: QMetaObject::connectSlotsByName: No matching signal for
on_cancel_clicked()
0...10...20...30...40...50...60...70...80...90...100 - done.
0...10...20...30...40...50.
On Sun, 2011-03-06 at 11:01 -0800, Bob and Deb wrote:
> I know that the Value Tool is a 3rd party plugin, but it would be nice
> if the raster-provider could work with it. All of my rasters are
> reported as being "out of extent".
confirmed: in reprojected rasters the value tool returns always "o
Radim wrote:
> Fixed.
Thanks!
Tim wrote:
> I will update the toolbar to use the same method - it should work for
> multiband imagery too. I think I copied the context menu one when I
> did the toolbar but maybe I am wrongI'll update it.
Thanks!
__
> I tried to load a simple jpg (without any projection information) into
> QGIS just to test ..
> It unfortunately leads to a segfault ..
confirmed, using Ubuntu 10.04
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.o
Hi all!
I tried to load a simple jpg (without any projection information) into
QGIS just to test ..
It unfortunately leads to a segfault ..
Then i thought to georeference the file first ... and opened the
georeferencer plugin .. but it seems the georeferencer plugin uses the
same mechanism to loa
eprojection is enabled but the server is able to serve the desired
> projection.
> regards
> Stefan
>> -Ursprüngliche Nachricht-
>> Von: Ivan Mincik [mailto:ivan.min...@gista.sk]
>> Gesendet am: Mittwoch, 9. März 2011 07:57
>> An: qgis-developer@lists.osgeo.org
Il giorno mar, 08/03/2011 alle 20.17 +0100, Radim Blazek ha scritto:
> Merged to trunk.
Thanks Radim.
Debian unstable user on amd64 can apt-get packages from
deb http://int.faunalia.it/~paolo/debian/ unstable/
All the best.
--
http://www.faunalia.it/pc
_
: Ivan Mincik [mailto:ivan.min...@gista.sk]
> Gesendet am: Mittwoch, 9. März 2011 07:57
> An: qgis-developer@lists.osgeo.org
> Betreff: Re: [Qgis-developer] Raster providers
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/08/2011 08:17 PM, Radim Bla
Hi
On Wed, Mar 9, 2011 at 8:33 AM, Radim Blazek wrote:
> On Wed, Mar 9, 2011 at 12:32 AM, Borys Jurgiel wrote:
>> 1. Histogram stretch doesn't work with OTFR enabled (both tools: the one in
>> layer context menu and the one in toolbar).
>
> Fixed.
>
>> By the way, why there are the two
>> tools
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/08/2011 08:17 PM, Radim Blazek wrote:
> Merged to trunk.
Congratulations,
I was testing WMS layer reprojection. It is working flawlessly. I am
impressed by speed.
Perfect work.
- --
Ivan Mincik, Gista s.r.o.
-BEGIN PGP SIGNATURE-
Vers
On Wed, Mar 9, 2011 at 12:32 AM, Borys Jurgiel wrote:
> 1. Histogram stretch doesn't work with OTFR enabled (both tools: the one in
> layer context menu and the one in toolbar).
Fixed.
> By the way, why there are the two
> tools for stretching? The one in toolbar works with grayscale rasters onl
Hi,
a bit more verbosity is necessary in this stage, I have commented the
matrix output however.
Radim
On Wed, Mar 9, 2011 at 1:08 AM, Carson Farmer wrote:
> Works beautifully (I'm looking at a reprojected alaska landcover test
> dataset as I type this)! One comment though: The Debug output is
>
Works beautifully (I'm looking at a reprojected alaska landcover test
dataset as I type this)! One comment though: The Debug output is
*extremely* verbose... as in... it looks like the matrix screen with
numbers running down my console ;-) Is this necessary?
Carson
On Tue, Mar 8, 2011 at 11:32 PM
Finally! :-) It's impressing. I observe two issues only:
1. Histogram stretch doesn't work with OTFR enabled (both tools: the one in
layer context menu and the one in toolbar). By the way, why there are the two
tools for stretching? The one in toolbar works with grayscale rasters only,
while th
\o/ \o/ \o/ \o/ <-- happy QGIS users everywhere
On Tue, Mar 8, 2011 at 9:17 PM, Radim Blazek wrote:
> Merged to trunk.
>
> Radim
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-deve
Merged to trunk.
Radim
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
+1
---
Paolo Cavallini http://faunalia.it/pc
- Reply message -
Da: "Borys Jurgiel"
A:
Oggetto: [Qgis-developer] Raster providers
Data: lun, mar 7, 2011 23:22
Dnia niedziela 06 marca 2011 o 21:18:59 Radim Blazek napisał(a):
> Hi,
> I am ready to merge raster-providers
Dnia niedziela 06 marca 2011 o 21:18:59 Radim Blazek napisał(a):
> Hi,
> I am ready to merge raster-providers branch to trunk. Are you ready too?
>
> Radim
Just to let you know, some of us are looking forward :-)
There's less and less time for testing :)
_
Hi Radim
Great! +1 for merging from me too.
Regards,
Marco
Am Sonntag, 6. März 2011, 21.18:59 schrieb Radim Blazek:
> Hi,
> I am ready to merge raster-providers branch to trunk. Are you ready too?
>
> Radim
> ___
> Qgis-developer mailing list
> Qgis-d
On Sun, 2011-03-06 at 11:01 -0800, Bob and Deb wrote:
> I know that the Value Tool is a 3rd party plugin, but it would be nice
> if the raster-provider could work with it. All of my rasters are
> reported as being "out of extent".
The value tool plugin is so useful (and fundamental) when doing ra
I tested your updates in the raster branch today. Things look real good from my
examination of the WMS capabilities. I did have a problem with the extents
occasionally jumping to some very different location, but I would not consider
this a show stopper. Again, this was with a WMS layer being re
Hi
On Sun, Mar 6, 2011 at 10:18 PM, Radim Blazek wrote:
> Hi,
> I am ready to merge raster-providers branch to trunk. Are you ready too?
>
+1 from me
Regards
Tim
> Radim
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http:/
Hi,
I am ready to merge raster-providers branch to trunk. Are you ready too?
Radim
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
On Sun, Mar 6, 2011 at 8:01 PM, Bob and Deb wrote:
> I know that the Value Tool is a 3rd party plugin, but it would be nice if
> the raster-provider could work with it. All of my rasters are reported as
> being "out of extent".
The Value Tool is using layer.identify(mapPos). The layer itself kno
I know that the Value Tool is a 3rd party plugin, but it would be nice if
the raster-provider could work with it. All of my rasters are reported as
being "out of extent".
-Bob
On Sun, Mar 6, 2011 at 10:29 AM, Radim Blazek wrote:
> On Tue, Mar 1, 2011 at 9:27 AM, Marco Hugentobler
> wrote:
> >
On Tue, Mar 1, 2011 at 9:27 AM, Marco Hugentobler
wrote:
> performance seems to be fast now even with reprojection turned on. The only
> thing with my test rasters that didn't work was the 'zoom to best resolution'
> function.
Fixed.
Radim
___
Qgis-de
Thanks for the update on this, Radim. I see that there will be some challenges
to work out with wms and reprojection. Thanks for you hard work and great dev
efforts,
John
On Mar 5, 2011, at 2:21 AM, Radim Blazek wrote:
> Hi,
> WMS reprojection should be fixed in sense that you get it rendered i
Hi,
WMS reprojection should be fixed in sense that you get it rendered in
the right place, but quality and even content is not the same like for
not project on the same scale. Of course.
To find the best resolution coefficient is one thing which has to be
done. Higher resolution in WMS request can
Il giorno mar, 01/03/2011 alle 09.27 +0100, Marco Hugentobler ha
scritto:
> function. However, this is a detail and I'm in favor of merging the branch to
> trunk soon and fixing the minor issues there.
Great. Looking forward for the merge. As soon as it will be merged, I'll
test it and prepare p
Hi,
I have to do the code cleanup definitely in the branch + wms fix.
Then I'll let you know before merge.
Radim
On Tue, Mar 1, 2011 at 9:27 AM, Marco Hugentobler
wrote:
> Hi Radim, Tim
>
>> That being the case, I would suggest we poll Marco and other devs to
>> see if it can move into trunk so
Hi Radim, Tim
> That being the case, I would suggest we poll Marco and other devs to
> see if it can move into trunk so that it can be more broadly tested
I briefly tested the raster provider branch today and it works great. The
performance seems to be fast now even with reprojection turned on.
On Mon, Feb 28, 2011 at 10:59 AM, Tim Sutton wrote:
> That being the case, I would suggest we poll Marco and other devs to
> see if it can move into trunk so that it can be more broadly tested
> before the release - I don't think it will be good to merge it at the
> last minute before the release
On Mon, Feb 28, 2011 at 9:01 AM, Radim Blazek wrote:
>
> BTW: The approximate reprojection could may be used also for vectors?
>
> Radim
Definitely. On-the-fly reprojection of vector layers takes ages, there
are no approximations right now.
Martin
___
Hi,
thanks for testing, I'll look at WMS again and let you know.
Openlayers are implemented as a plugin, not provider, they will not
become automatically reprojected.
Radim
On Mon, Feb 28, 2011 at 1:12 AM, John C. Tull wrote:
> Hi,
>
> I was testing a little today. It appears that WMS layers ar
Hi
On Mon, Feb 28, 2011 at 10:01 AM, Radim Blazek wrote:
> On Sun, Feb 27, 2011 at 9:54 PM, Tim Sutton wrote:
>> Do you have anything else left on your todo list before you can merge to
>> trunk?
>
> It looks like this:
> qgsrasterprojector.* qgsrasterdataprovider.* raster/qgsrasterlayer.* : 60
On Sun, Feb 27, 2011 at 9:54 PM, Tim Sutton wrote:
> Do you have anything else left on your todo list before you can merge to
> trunk?
It looks like this:
qgsrasterprojector.* qgsrasterdataprovider.* raster/qgsrasterlayer.* : 60 TODOs
qgsgdalprovider.*: 11 TODOs
qgsgrassrasterprovider.*: 8 TODOs
Hi,
I was testing a little today. It appears that WMS layers are not being
projected. I would imagine that needs to be corrected before a merge. Also,
openlayers are not correctly projecting based on some quick tests on my end.
I'm not sure if this is a problem with the branch or the plugin.
C
Hi
8<-snip-
>> - it would be nice if the 'collar' - the part outside the image data
>> area in rotated images was made transparent by default.
>
> Isn't it? The data outside source data extent are null. That is the source
> of all the troubles with null values handling and typ
On Sun, Feb 27, 2011 at 7:08 PM, Tim Sutton wrote:
> Thanks its working great now. The grayscale issue I was having I can't
> replicate with the data I have here at home - will try again tomorrow
> on my office pc with the original dataset - as far as I know that
> machine is already set to stretc
Hi Radim
On Sun, Feb 27, 2011 at 6:04 PM, Radim Blazek wrote:
> On Thu, Feb 24, 2011 at 10:00 AM, Tim Sutton wrote:
>> Also I noted that for greyscale images they always seem to load with
>> min 0 / max 0 and I have to manually go into properties to load them
>> from the layer.
>
> For me it loa
On Thu, Feb 24, 2011 at 10:00 AM, Tim Sutton wrote:
> Also I noted that for greyscale images they always seem to load with
> min 0 / max 0 and I have to manually go into properties to load them
> from the layer.
For me it loads with source data type range (tested with UInt16) and
it works the sam
Hi,
thanks for testing, there are really too many combinations of data types,
drawing styles, projections, resolutions etc. which I am not able to test all.
It is fixed now. The problem was not in the color handling but in
source resolution calculation.
Radim
On Thu, Feb 24, 2011 at 10:00 AM, Ti
Hi Radim
I did some testing too. Having otf projection is coool! Id did run
into some problems with my paletted image[1] though.
If I open the image in QGIS default session (i.e. no OTF projection)
it displays fine [2].
If I enabled OTF Projection (using 900913 Google Mercator) the image
displays
Hi have fixed some known problems:
- short data types are represented by longer types to get space for
nulls (the problem Marco found)
- avoid statistics calculation on raster load (reported by John C. Tull)
- properties are enabled according provider capabilities
Please test.
Radim
_
On Fri, Nov 5, 2010 at 11:35 AM, G. Allegri wrote:
> What about GDAL? It's 'hard-coded' inside the rasterlayer, but I
> suppose it will become a raster provider implementation. Isn'it?
Yes, that is one aim.
Radim
___
Qgis-developer mailing list
Qgis-de
No problem Radim. I think having a rasterprovider layer is of big
interest to be able to bind other kind of raster sources (i.e. VTK).
What about GDAL? It's 'hard-coded' inside the rasterlayer, but I
suppose it will become a raster provider implementation. Isn'it?
2010/11/5 Radim Blazek :
> I appr
I appreciate your interest, but as I said, it is not usable at the moment,
with a lot of luck you can display GRASS integer map, but you have to
set min/max manually
to get reasonable colors.
Radim
On Fri, Nov 5, 2010 at 10:08 AM, G. Allegri wrote:
> Thanks Radim! That was a feature I hoped to s
Thanks Radim! That was a feature I hoped to see since the first time I
saw Qgis :)
I'm going to check it out rigth now.
giovanni
2010/11/5 Radim Blazek :
> Hi,
> I have created new branch 'raster-providers' for true raster providers
> support development which is my main task for the upcoming hac
Hi,
I have created new branch 'raster-providers' for true raster providers
support development which is my main task for the upcoming hackfest.
It is not yet ready for testing. I have only submitted some initial
work for passing data for rendering from providers to raster layer.
I will appreciate,
78 matches
Mail list logo
