Jorge ArĂŠvalo wrote:
> 2009/7/23 Mateusz Loskot :
>> Jorge Ar�Švalo wrote::
>>> Hello,
>>>
>>> Context: GDAL WKT Raster Driver
>>>
>>> While creating the Dataset, I execute this query:
>>>
>>> SELECT srid, ST_AsText(extent), pixelsize_x, pixelsize_y, blocksize_x,
>>> blocksize_y FROM raster_colu
Hello Mateusz,
2009/7/23 Mateusz Loskot :
> Jorge ArĂŠvalo wrote::
>> Hello,
>>
>> Context: GDAL WKT Raster Driver
>>
>> While creating the Dataset, I execute this query:
>>
>> SELECT srid, ST_AsText(extent), pixelsize_x, pixelsize_y, blocksize_x,
>> blocksize_y FROM raster_columns WHERE r_table_n
Jorge ArĂŠvalo wrote::
> Hello,
>
> Context: GDAL WKT Raster Driver
>
> While creating the Dataset, I execute this query:
>
> SELECT srid, ST_AsText(extent), pixelsize_x, pixelsize_y, blocksize_x,
> blocksize_y FROM raster_columns WHERE r_table_name = 'table' AND
> r_column = 'rast'
>
> I have load
Hello,
2009/7/23 Adam Nowacki :
> Jorge Arévalo wrote:
>>
>> fPixelSizeX = atof(PQgetvalue(hPGresult, 0, 2));
>>
>> I get 0.89976158142 instead of 0.9.
>
> 0.89976158142... is the value closest to 0.9 that a single precision
> float variable can store.
> Using 'double' should give 0.9
Hi All,
I have an oddity when trying to read a grib1 dataset.
When I extract the data using code:
hBand = GDALGetRasterBand(hSrcDS, 1 );
float *pafScanline;
int nXSize = GDALGetRasterBandXSize( hBand );
pafScanline = (float *) CPLMalloc(sizeof(float)*nXSize);
GDALRasterIO( hBand, GF_
Jorge Arévalo wrote:
fPixelSizeX = atof(PQgetvalue(hPGresult, 0, 2));
I get 0.89976158142 instead of 0.9.
0.89976158142... is the value closest to 0.9 that a single precision
float variable can store.
Using 'double' should give 0.90002220...
Hello,
Context: GDAL WKT Raster Driver
While creating the Dataset, I execute this query:
SELECT srid, ST_AsText(extent), pixelsize_x, pixelsize_y, blocksize_x,
blocksize_y FROM raster_columns WHERE r_table_name = 'table' AND
r_column = 'rast'
I have loaded a 3-band tiff file with gdal2tiles. It
Comments inline below:
Even Rouault wrote:
>
> Le Wednesday 22 July 2009 20:53:31 Jason Roberts, vous avez écrit :
>> It sounds like you have figured out the problem. Is now the moment that I
>> should contact the rgdal developers and ask them to build rgdal against
>> the
>> 1.6 branch?
>
> I
Le Wednesday 22 July 2009 20:53:31 Jason Roberts, vous avez écrit :
> It sounds like you have figured out the problem. Is now the moment that I
> should contact the rgdal developers and ask them to build rgdal against the
> 1.6 branch?
It's up to them. I don't know what their policy is. I doubt th
It sounds like you have figured out the problem. Is now the moment that I
should contact the rgdal developers and ask them to build rgdal against the
1.6 branch?
Currently it looks like rgdal is built against the 1.6.1 release. I'm not
sure if they'll want to build against the current 1.6 branch o
Le Wednesday 22 July 2009 20:17:43 Gregory, Matthew, vous avez écrit :
>
> > For people affected by the issue, not being able to build
> > GDAL from source and not interested in the raster attribute
> > table, they can just rename the 'info'
> > directory, so it won't be read at all and won't trigg
Hi Even,
Even Rouault wrote:
> I've pushed in trunk (r17430) and branches/1.6 (r17431) a
> workaround to enable users to open those datasets that
> trigger the error with binding languages.
> As Open() in swig/include/gdal.i checks that there is no
> failure returned by
> CPLGetLastErrorType()
Le Wednesday 22 July 2009 18:09:28 Gregory, Matthew, vous avez écrit :
> Hi Jason,
>
> Jason Roberts wrote:
> > Markus - thanks for the links to those tickets. Those tickets
> > seem to imply this is a minor annoyance. Unfortunately, for
> > me, it means I can't read the grids at all from R. Perhap
Thanks Matt, that is very interesting to know that the Python bindings fail
with the same problem. Which version of GDAL are you using with the Python
bindings?
> So it seems like either all bindings need to silently ignore this error
> or have it fixed in the GDAL source.
Even and other GDAL dev
Hi Jason,
Jason Roberts wrote:
> Markus - thanks for the links to those tickets. Those tickets
> seem to imply this is a minor annoyance. Unfortunately, for
> me, it means I can't read the grids at all from R. Perhaps if
> I was using the C interface there would be a workaround (just
> ignore
Scott - indeed, it turned out to be permissions issue with the module
gdal_array on our cluster.
Thanks and best regards,
Greg
-Original Message-
Date: Tue, 21 Jul 2009 08:14:05 +0200
From: Scott Sinclair
Subject: Re: [gdal-dev] Python bindings on RedHat cluster (was:
Attribut
Hi,
Would anyone be able to point me in the direction of a solution to my build
error on Solaris?
gmake libgdal.la
gmake[1]: Entering directory `gdal-1.6.0'
gmake[1]: *** No rule to make target `gdal-1.6.0/frmts/o/*.lo', needed by
`libgdal.la'. Stop.
gmake[1]: Leaving directory `gdal-1.6.0'
gm
Markus - thanks for the links to those tickets. Those tickets seem to imply
this is a minor annoyance. Unfortunately, for me, it means I can't read the
grids at all from R. Perhaps if I was using the C interface there would be a
workaround (just ignore the error?) but this is not possible using the
On Wed, Jul 22, 2009 at 2:57 AM, Jason Roberts wrote:
> I have some R code that reads ArcInfo binary grids using the rgdal package.
> This code has worked for a long time. Now, with the latest versions of
> everything it is failing with the message:
>
>
>
> GDAL Error 3: Attempt to read past EOF in
19 matches
Mail list logo
