On Tue, 14 Apr 2015 at 05:46 Dominik Schneider
dominik.schnei...@colorado.edu wrote:
Hi -
I have some .mdl files from IDL with .hdr header files that I’d like to
convert to netcdf.
The following code produces a netcdf file with a subdataset for each band
in the mdl file. Is there any way
Le jeudi 09 avril 2015 20:39:34, Even Rouault a écrit :
Hi,
Motion 1 : I move to adopt RFC 56: OFTTime/OFTDateTime millisecond accuracy
https://trac.osgeo.org/gdal/wiki/rfc56_millisecond_precision
Starting with my +1
-
Motion 2: I move to adopt RFC 57:
13.04.2015, 15:01, Even Rouault kirjoitti:
Hi,
Some time ago, I mentionned my proposal of issuing a first GDAL 2.0 beta
version for the end of this month (April 30th). Are there objections to
sticking with that plan ? Does someone need a bit more time to finish an
ongoing work ?
I'm going
Certainly keen to help out! Disclaimer: I'm fairly familiar with NuGet, but
only as a consumer, never as a package creator / contributor, so let me know
if I'm way off the mark with anything ;)
How were the existing packages created? Looking at the
gisinternals/buildsystem on GitHub, I assume
Jukka,
From the GPKG driver, it would mean that the user would have to think to
change its layer names to prefix them with vgpkg_ in his requests and the GPKG
driver should be modified to accept Spatialite geometries being returned as
column values.
From the SQLite driver, currently it
Hi Mike - Thanks for the response and sorry this wasn’t quite clear. IDL
data cubes are of the ENVI format and thus also have an associated ascii
.hdr file. A dataset with 10 bands is here:
https://dl.dropboxusercontent.com/u/5962491/IDLENVIswe.zip
There is no time data in the .mdl file, but I
Well, FWIW -
Here the CRS doesn't round-trip properly, partly as the PROJ.4 string in R
is not sufficient, and the date type gets recorded as raw integer (that's
ok depending what your target environment will need). Using gdal_translate
you could augment the netcdf created here with a proper WKT
Sorry, edit - the setZ line should be:
r - setZ(r, dt0)
On Wed, 15 Apr 2015 at 00:40 Michael Sumner mdsum...@gmail.com wrote:
Well, FWIW -
Here the CRS doesn't round-trip properly, partly as the PROJ.4 string in R
is not sufficient, and the date type gets recorded as raw integer (that's
Am 15.04.2015 um 01:23 schrieb Nicolas Ragg:
Hello all
I have a french map in ECW format, i guess it is from IGN. Srs seems ok
but when i import
the thing in qgis or try to warp the file it is all shifted to north
(Around
Sweden).
The output from gdalinfo 1.11 is
PROJ.4 : '+proj=lcc
Le 15/04/2015 01:23, Nicolas Ragg a écrit :
Hello all
I have a french map in ECW format, i guess it is from IGN. Srs seems ok
but when i import
the thing in qgis or try to warp the file it is all shifted to north
(Around
Sweden).
Please run the command : gdalinfo -mdd ECW file.ecw
What are
Hi,
I am reading from http://www.gdal.org/drv_geopackage.html the following
Starting with GDAL 2.0, SQL SELECT statements passed to ExecuteSQL() are
also executed directly against the database. If Spatialite is used, a recent
version (4.2.0) is needed and use of explicit cast operators AsGPB(),
As far as I remember the current packages have been produced by: Felix
Obermaier o...@ivv-aachen.de based on the gisinternals packages.
It is interesting that 2.5+ provides better native code support. I'd be
interested in looking into that but I have no spare time in short term.
If you with to
Hello all
I have a french map in ECW format, i guess it is from IGN. Srs seems ok but
when i import
the thing in qgis or try to warp the file it is all shifted to north (Around
Sweden).
The output from gdalinfo 1.11 is
PROJ.4 : '+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.99987742
13 matches
Mail list logo
