Hi Even,
It looks like I am running into another checksum issue on ppc64le.
Output on ppc64le:
gdalchksum.py ../autotest/gdrivers/data/nwt_grd.grd
28093
32304
19624
25856
Output on x86:
gdalchksum.py ../autotest/gdrivers/data/nwt_grd.grd
28093
33626
20260
25856
There is a mismatch for bands 2 an
-co tfw=yes -t_srs epsg:3857 -te 10018754.17
> -7361866.11 20037508.34 -0.00
> /storage/sat_data/20150824/IDE00422.201508240100.tif
> /storage/tmp/IDE00422.201508240100.tif
>
>
>
> Using gdalinfo reveals the following about the newly created GeoTIFF file:
>
>
>
&
Hi,
I try to create a vrt-datasource using this sintax:
gdalbuildvrt /path-to/dataset.vrt \
/path-ti-tiffs/tiff_1.tif
It was correctly created.
After,
I do this other command:
gdalbuildvrt /path-to/dataset.vrt \
/path-ti-tiffs/tiff_2.tif
The new dataset.vrt I notice is containing the
Le lundi 24 août 2015 10:28:38, Jean-Claude Repetto a écrit :
> Le 2015-08-24 10:11, Jukka Rahkonen a écrit :
> > Wouldn't it be time to bury 900913 permenently? There is also an open
> > ticket
> > about that https://trac.osgeo.org/gdal/ticket/5622
> >
> > -Jukka Rahkonen-
>
> +1
I've just modi
Raised ticket at: https://trac.osgeo.org/gdal/ticket/6082#ticket
On Mon, Aug 24, 2015 at 2:32 PM, Even Rouault
wrote:
> Le lundi 24 août 2015 10:58:49, Gawade P a écrit :
>> Thanks, Even!
>> This change solved the issue I was seeing. Appreciate your help on this!
>
> Great. Could you please file
Le lundi 24 août 2015 10:58:49, Gawade P a écrit :
> Thanks, Even!
> This change solved the issue I was seeing. Appreciate your help on this!
Great. Could you please file a ticket about that on
https://trac.osgeo.org/gdal/newticket ?
>
> On Mon, Aug 24, 2015 at 1:18 PM, Even Rouault
>
> wrote
Thanks, Even!
This change solved the issue I was seeing. Appreciate your help on this!
On Mon, Aug 24, 2015 at 1:18 PM, Even Rouault
wrote:
> Hi,
>
> Looking at the first difference, 371 - 115 = 256. Those gaps of +256 appear
> each
> time a value at col n+1 is lesser than the value at col n (wh
Le 2015-08-24 10:11, Jukka Rahkonen a écrit :
>
> Wouldn't it be time to bury 900913 permenently? There is also an open
> ticket
> about that https://trac.osgeo.org/gdal/ticket/5622
>
> -Jukka Rahkonen-
>
+1
Jean-Claude
___
gdal-dev mailing list
gd
Even Rouault spatialys.com> writes:
>
> 2 possible workarounds :
> - download https://svn.osgeo.org/gdal/trunk/gdal/data/cubewerx_extra.wkt and
> copy it to /usr/share/gdal/1.10 so as to get 900913
> - edit /usr/bin/gdal2tiles.py and replace all occurences of 900913 by 3857
Hi,
Wouldn't it b
epsg:3857 -te 10018754.17
> -7361866.11 20037508.34 -0.00
> /storage/sat_data/20150824/IDE00422.201508240100.tif
> /storage/tmp/IDE00422.201508240100.tif
>
>
>
> Using gdalinfo reveals the following about the newly created GeoTIFF file:
>
>
>
> #
Hi,
Looking at the first difference, 371 - 115 = 256. Those gaps of +256 appear
each
time a value at col n+1 is lesser than the value at col n (when looking the
reference x86 data). Knowing that HF2 data is delta encoded and that for this
row the delta between consecutive values is in the [-12
11 matches
Mail list logo