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 th
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 +lat_1=46.8
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
+x_0=60
As far as I remember the current packages have been produced by: Felix
Obermaier 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 get involved in the
Sorry, edit - the setZ line should be:
r <- setZ(r, dt0)
On Wed, 15 Apr 2015 at 00:40 Michael Sumner 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
> ok depending
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
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 know
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 doesn
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(),
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 that
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 RF
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 thro
12 matches
Mail list logo
