Thanks for the tips Kyle and Even and for the quick fix!
Not a big netCDF user myself, but have noticed that it seems to be the
standard format for many of my colleagues who work in climatology. So good
to get this fixed!
Cheers,
Simon
On Tue, Oct 27, 2015 at 6:08 PM, Even Rouault
wrote:
> Le
Hi,
Just to mention that trunk has received 2 new virtual file systems
/vsis3/ and /vsis3_streaming/ to handle files stored on Amazon S3.
They are specializations of well known /vsicurl/ and /vsicurl_streaming/
to deal with S3 authentication and other particularities. In addition to
reading, /vsi
Le mardi 27 octobre 2015 16:54:56, Kyle Shannon a écrit :
> Simon,
>
> On Mon, Oct 26, 2015 at 5:04 PM, Simon Lyngby Kokkendorff
>
> wrote:
> > Hello list,
> >
> >Just observed a puzzling behaviour of the netCDF driver. When creating
> >a
> >
> > netCDF dataset of Byte type, the netCDF
Simon,
On Mon, Oct 26, 2015 at 5:04 PM, Simon Lyngby Kokkendorff
wrote:
> Hello list,
>
>Just observed a puzzling behaviour of the netCDF driver. When creating a
> netCDF dataset of Byte type, the netCDF driver seems to interpret the nodata
> value as a signed byte.
> For example a nodata va
Hi,
I am just a regular gdal user but can offer some answers.
1:Are you aware the global 1sec SRTMGL1 data is available world wide? Only use the 3 sec data if you need it a lower rez. Google SRTMGL1.
2: two programs, 2 lines. But you can just write it in a txt file with a .bat extension and both
Hello to GDAL community,
Lately I have been trying to use the SRTM 3 arc second elevation data in a form
of ASCII grid (.asc file) downloaded freely from opentopography.org.
The problem is that, decimal degrees for .asc files downloaded from
opentopography.org are unprojected.
I have been told
