Re: [gdal-dev] define netcdf time dimension
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 to define the bands as the time dimension, in this case 4416 hourly timesteps? Or is there another tool that can convert this? gdal_translate -of NetCDF swe.mdl swe.nc Can you list the metadata printed out by gdalinfo swe.mdl? What driver is used? Does that source file have time-metadata inside it each subdataset or do you need to assign it? Generally, the subdatasets are not considered as a time series - they are more like multiple variables for the same observation (whereas a 3rd and higher dimension/s are often unrolled into a multi-attributed 2D layer and the time/z step is stored on each band - it's a bit of a mix/clash of worlds). Can you point to and example file somewhere? I imagine you'll need a programmed solution, but it should be pretty easy with R or python or similar. If R is of interest you can try this and take your question to the R community: library(raster) r - stack(swe.mdl) r - setZ(r, [whatever the vector of dates should be]) ## pseudocode writeRaster(r, swe.nc) That all assumes quite a lot, including available NetCDF versions and packages, required structure in the output, interpretation of the data read in, - so it's just included as an indication how it might be done. Cheers, Mike. Thanks Dominik ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MotionS: adopt RFC 56 and RFC 57
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: 64-bit bucket counts for histograms https://trac.osgeo.org/gdal/wiki/rfc57_histogram_64bit_count Starting with my +1 I declare both motions passed with +1 from DanielM, JukkaR and me. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.0 release plans
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 through and revising the whole Perl API. I'm maybe 70 % done so April 30th may come a bit soon but it is probably doable. Thanks, Ari And if things go well with this beta (and potentially other beta(s) needed), we could try a release candidate for end of May. One month of beta phase might seem a bit short, but I'm not sure extending the beta testing period more will bring significant additional feedback (and things tend to slip, so better aim for a tight schedule). Thoughts ? Anyone using GDAL intensively and/or interesting in 2.0 should already track trunk closely ;-) I can wear the hat of 2.0 release manager, but I'm happy to let it to any other volunteer. Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL NuGet Package
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 there are no VS .proj files to auto-generate the package from? The good news is that there seems to be much better support for native code in NuGet now (from v2.5). I don't know if this was already used or if something else like CoApp was used? Regards, Peet Whittaker -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDAL-NuGet-Package-tp5201018p5201267.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Better way to use GPKG from SpatiaLite
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't recognize well the vgpkg_ tables when listing layers (it doesn't recognize the database as being a spatialite one or a OGR-style one). When issuing direct SQL, it works better. If recognizing database/layers was fixed, an extra workaround would have to be done since the driver would try to request idx_vgpkg_foo_geometry as the spatial index for table foo / vgpkg_foo, whereas the GPKG name is rtree_foo_geometry. If manually doing the spatial request (i.e. not using the SpatialIndex syntaxic sugar), I guess that should work. In both cases there's however a cost to pay due to the virtual table mechanism, and probably suboptimal/lack of use of attribute indices, etc... I think the best user friendly, and best performing, solution would be: - libspatialite: to accept GPKG geometries transparently in all the functions that take geometries as argument (and still return a spatialite geometry) - OGR GPKG driver: to accept spatialite geometries as valid values for results of SQL requests. Even 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(), GeomFromGPB() are required. It is also possible to use with any Spatialite version, but in a slower way, by specifying the INDIRECT_SQLITE dialect. In which case, GeoPackage geometries appear as Spatialite geometries after translation by OGR. I did also read this https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html#p16gpkg and made some experiments and there is another way to query GeoPackage databases from SpatiaLite and for me it feels very much more convenient if there is a need to do spatial queries. How it works is to execute first AutoGPKGStart(). Before that it would be good to check if SpatiaLite is recognizing GPKG by executing CheckGeoPackageMetaData() and since today in the SpatiaLite trunk the check can also be done with CheckSpatialMetaData(). The expected result is 4. Successful AutoGPKGStart() creates virtual GPKG tables which can be queried transparently without casting to/from GPB. The names of the virtual tables have vgpkg_ added before the main table name. I can't say if selecting -dialect SQLite could turn on the AutoGPKGStart automatically, of if the GPKG database should be opened with SQLite/SpatiaLite driver instead of GPKG driver from the beginning. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] define netcdf time dimension
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 that the 4416 bands are hourly timesteps from 0:00 March 1 to 23:00 Aug 31 I could do this in R but was trying to avoid it because R is always so frustratingly slow for these things…the gdal commandline utilities are much more awesome! iMac:~/Downloads $ gdalinfo swe.mdl Driver: ENVI/ENVI .hdr Labelled Files: swe.mdl swe.hdr Size is 352, 190 Coordinate System is: PROJCS[UTM_Zone_13N, GEOGCS[GCS_North_American_1983, DATUM[North_American_Datum_1983, SPHEROID[GRS_1980,6378137.0,298.257222101]], PRIMEM[Greenwich,0.0], UNIT[Degree,0.0174532925199433]], PROJECTION[Transverse_Mercator], PARAMETER[False_Easting,50.0], PARAMETER[False_Northing,0.0], PARAMETER[Central_Meridian,-105.0], PARAMETER[Scale_Factor,0.9996], PARAMETER[Latitude_Of_Origin,0.0], UNIT[Meter,1]] Origin = (444345.0816298,4436145.28000260770) Pixel Size = (30.000,-30.000) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 444345.080, 4436145.280) (105d39' 9.74W, 40d 4'25.45N) Lower Left ( 444345.080, 4430445.280) (105d39' 7.97W, 40d 1'20.58N) Upper Right ( 454905.080, 4436145.280) (105d31'43.92W, 40d 4'27.72N) Lower Right ( 454905.080, 4430445.280) (105d31'42.49W, 40d 1'22.85N) Center ( 449625.080, 4433295.280) (105d35'26.03W, 40d 2'54.21N) Band 1 Block=352x1 Type=Float32, ColorInterp=Undefined Band 2 Block=352x1 Type=Float32, ColorInterp=Undefined Band 3 Block=352x1 Type=Float32, ColorInterp=Undefined Band 4 Block=352x1 Type=Float32, ColorInterp=Undefined Band 5 Block=352x1 Type=Float32, ColorInterp=Undefined Band 6 Block=352x1 Type=Float32, ColorInterp=Undefined Band 7 Block=352x1 Type=Float32, ColorInterp=Undefined Band 8 Block=352x1 Type=Float32, ColorInterp=Undefined Band 9 Block=352x1 Type=Float32, ColorInterp=Undefined Band 10 Block=352x1 Type=Float32, ColorInterp=Undefined ... Band 4416 Block=352x1 Type=Float32, ColorInterp=Undefined Dominik Schneider o 303.735.6296 | c 518.956.3978 On Tue, Apr 14, 2015 at 12:07 AM, Michael Sumner mdsum...@gmail.com wrote: 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 to define the bands as the time dimension, in this case 4416 hourly timesteps? Or is there another tool that can convert this? gdal_translate -of NetCDF swe.mdl swe.nc Can you list the metadata printed out by gdalinfo swe.mdl? What driver is used? Does that source file have time-metadata inside it each subdataset or do you need to assign it? Generally, the subdatasets are not considered as a time series - they are more like multiple variables for the same observation (whereas a 3rd and higher dimension/s are often unrolled into a multi-attributed 2D layer and the time/z step is stored on each band - it's a bit of a mix/clash of worlds). Can you point to and example file somewhere? I imagine you'll need a programmed solution, but it should be pretty easy with R or python or similar. If R is of interest you can try this and take your question to the R community: library(raster) r - stack(swe.mdl) r - setZ(r, [whatever the vector of dates should be]) ## pseudocode writeRaster(r, swe.nc) That all assumes quite a lot, including available NetCDF versions and packages, required structure in the output, interpretation of the data read in, - so it's just included as an indication how it might be done. Cheers, Mike. Thanks Dominik ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] define netcdf time dimension
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 version, so
maybe this is useful in a limited context.
I tried it so you might as well see the result:
library(raster)
r - stack(swe_sub.mdl)
r
#class : RasterStack
#dimensions : 190, 352, 66880, 1 (nrow, ncol, ncell, nlayers)
#resolution : 30, 30 (x, y)
#extent : 444345.1, 454905.1, 4430445, 4436145 (xmin, xmax, ymin,
ymax)
#coord. ref. : +proj=utm +zone=13 +datum=NAD83 +units=m +no_defs
#names : Band.1
dt0 - seq(as.POSIXct(2014-03-01 00:00:00, tz = UTC), by = 1 hour,
length = nlayers(r))
r - setZ(r, as.character(dt0))
writeRaster(r, swe_sub.nc)
system(gdalinfo swe_sub.nc)
Warning 1: dimension #2 (easting) is not a Longitude/X dimension.
Warning 1: dimension #1 (northing) is not a Latitude/Y dimension.
Driver: netCDF/Network Common Data Format
Files: swe_sub.nc
Size is 352, 190
Coordinate System is `'
Origin = (444345.0816298,4436145.28000260770)
Pixel Size = (30.000,-30.000)
Metadata:
easting#long_name=easting
easting#units=meter
layer#_FillValue=-3.4e+38
layer#long_name=layer
layer#max=3.695244550704956
layer#min=0
layer#missing_value=-3.4e+38
layer#projection=+proj=utm +zone=13 +datum=NAD83 +units=m +no_defs
layer#projection_format=PROJ.4
NC_GLOBAL#Conventions=CF-1.4
NC_GLOBAL#created_by=R, packages ncdf and raster (version 2.3-33)
NC_GLOBAL#date=2015-04-14 04:29:01
NETCDF_DIM_EXTRA={time}
NETCDF_DIM_time_DEF={1,6}
NETCDF_DIM_time_VALUES=1393632000
northing#long_name=northing
northing#units=meter
time#long_name=time
time#units=seconds since 1970-01-01 00:00:00
Corner Coordinates:
Upper Left ( 444345.080, 4436145.280)
Lower Left ( 444345.080, 4430445.280)
Upper Right ( 454905.080, 4436145.280)
Lower Right ( 454905.080, 4430445.280)
Center ( 449625.080, 4433295.280)
Band 1 Block=352x1 Type=Float32, ColorInterp=Undefined
NoData Value=-3.39996e+38
Metadata:
_FillValue=-3.4e+38
long_name=layer
max=3.695244550704956
min=0
missing_value=-3.4e+38
NETCDF_DIM_time=1393632000
NETCDF_VARNAME=layer
projection=+proj=utm +zone=13 +datum=NAD83 +units=m +no_defs
projection_format=PROJ.4
## context of the R session
sessionInfo()
R version 3.1.3 (2015-03-09)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.2 LTS
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] raster_2.3-33 sp_1.0-17
loaded via a namespace (and not attached):
[1] grid_3.1.3 lattice_0.20-31 ncdf4_1.13 rgdal_0.9-2
On Wed, 15 Apr 2015 at 00:20 Dominik Schneider
dominik.schnei...@colorado.edu wrote:
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 that the 4416 bands are
hourly timesteps from 0:00 March 1 to 23:00 Aug 31
I could do this in R but was trying to avoid it because R is always so
frustratingly slow for these things…the gdal commandline utilities are much
more awesome!
iMac:~/Downloads $ gdalinfo swe.mdl
Driver: ENVI/ENVI .hdr Labelled
Files: swe.mdl
swe.hdr
Size is 352, 190
Coordinate System is:
PROJCS[UTM_Zone_13N,
GEOGCS[GCS_North_American_1983,
DATUM[North_American_Datum_1983,
SPHEROID[GRS_1980,6378137.0,298.257222101]],
PRIMEM[Greenwich,0.0],
UNIT[Degree,0.0174532925199433]],
PROJECTION[Transverse_Mercator],
PARAMETER[False_Easting,50.0],
PARAMETER[False_Northing,0.0],
PARAMETER[Central_Meridian,-105.0],
PARAMETER[Scale_Factor,0.9996],
PARAMETER[Latitude_Of_Origin,0.0],
UNIT[Meter,1]]
Origin = (444345.0816298,4436145.28000260770)
Pixel Size = (30.000,-30.000)
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 444345.080, 4436145.280) (105d39' 9.74W, 40d 4'25.45N)
Lower Left ( 444345.080, 4430445.280) (105d39' 7.97W, 40d 1'20.58N)
Upper Right ( 454905.080, 4436145.280) (105d31'43.92W, 40d 4'27.72N)
Lower Right ( 454905.080, 4430445.280) (105d31'42.49W, 40d 1'22.85N)
Center ( 449625.080, 4433295.280) (105d35'26.03W, 40d 2'54.21N)
Band 1
Re: [gdal-dev] define netcdf time dimension
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
ok depending what your target environment will need). Using gdal_translate
you could augment the netcdf created here with a proper WKT version, so
maybe this is useful in a limited context.
I tried it so you might as well see the result:
library(raster)
r - stack(swe_sub.mdl)
r
#class : RasterStack
#dimensions : 190, 352, 66880, 1 (nrow, ncol, ncell, nlayers)
#resolution : 30, 30 (x, y)
#extent : 444345.1, 454905.1, 4430445, 4436145 (xmin, xmax, ymin,
ymax)
#coord. ref. : +proj=utm +zone=13 +datum=NAD83 +units=m +no_defs
#names : Band.1
dt0 - seq(as.POSIXct(2014-03-01 00:00:00, tz = UTC), by = 1 hour,
length = nlayers(r))
r - setZ(r, as.character(dt0))
writeRaster(r, swe_sub.nc)
system(gdalinfo swe_sub.nc)
Warning 1: dimension #2 (easting) is not a Longitude/X dimension.
Warning 1: dimension #1 (northing) is not a Latitude/Y dimension.
Driver: netCDF/Network Common Data Format
Files: swe_sub.nc
Size is 352, 190
Coordinate System is `'
Origin = (444345.0816298,4436145.28000260770)
Pixel Size = (30.000,-30.000)
Metadata:
easting#long_name=easting
easting#units=meter
layer#_FillValue=-3.4e+38
layer#long_name=layer
layer#max=3.695244550704956
layer#min=0
layer#missing_value=-3.4e+38
layer#projection=+proj=utm +zone=13 +datum=NAD83 +units=m +no_defs
layer#projection_format=PROJ.4
NC_GLOBAL#Conventions=CF-1.4
NC_GLOBAL#created_by=R, packages ncdf and raster (version 2.3-33)
NC_GLOBAL#date=2015-04-14 04:29:01
NETCDF_DIM_EXTRA={time}
NETCDF_DIM_time_DEF={1,6}
NETCDF_DIM_time_VALUES=1393632000
northing#long_name=northing
northing#units=meter
time#long_name=time
time#units=seconds since 1970-01-01 00:00:00
Corner Coordinates:
Upper Left ( 444345.080, 4436145.280)
Lower Left ( 444345.080, 4430445.280)
Upper Right ( 454905.080, 4436145.280)
Lower Right ( 454905.080, 4430445.280)
Center ( 449625.080, 4433295.280)
Band 1 Block=352x1 Type=Float32, ColorInterp=Undefined
NoData Value=-3.39996e+38
Metadata:
_FillValue=-3.4e+38
long_name=layer
max=3.695244550704956
min=0
missing_value=-3.4e+38
NETCDF_DIM_time=1393632000
NETCDF_VARNAME=layer
projection=+proj=utm +zone=13 +datum=NAD83 +units=m +no_defs
projection_format=PROJ.4
## context of the R session
sessionInfo()
R version 3.1.3 (2015-03-09)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.2 LTS
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] raster_2.3-33 sp_1.0-17
loaded via a namespace (and not attached):
[1] grid_3.1.3 lattice_0.20-31 ncdf4_1.13 rgdal_0.9-2
On Wed, 15 Apr 2015 at 00:20 Dominik Schneider
dominik.schnei...@colorado.edu wrote:
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 that the 4416 bands
are hourly timesteps from 0:00 March 1 to 23:00 Aug 31
I could do this in R but was trying to avoid it because R is always so
frustratingly slow for these things…the gdal commandline utilities are much
more awesome!
iMac:~/Downloads $ gdalinfo swe.mdl
Driver: ENVI/ENVI .hdr Labelled
Files: swe.mdl
swe.hdr
Size is 352, 190
Coordinate System is:
PROJCS[UTM_Zone_13N,
GEOGCS[GCS_North_American_1983,
DATUM[North_American_Datum_1983,
SPHEROID[GRS_1980,6378137.0,298.257222101]],
PRIMEM[Greenwich,0.0],
UNIT[Degree,0.0174532925199433]],
PROJECTION[Transverse_Mercator],
PARAMETER[False_Easting,50.0],
PARAMETER[False_Northing,0.0],
PARAMETER[Central_Meridian,-105.0],
PARAMETER[Scale_Factor,0.9996],
PARAMETER[Latitude_Of_Origin,0.0],
UNIT[Meter,1]]
Origin = (444345.0816298,4436145.28000260770)
Pixel Size = (30.000,-30.000)
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 444345.080, 4436145.280) (105d39' 9.74W, 40d 4'25.45N)
Lower Left ( 444345.080, 4430445.280) (105d39' 7.97W, 40d 1'20.58N)
Upper
Re: [gdal-dev] Trouble with French Ecw map
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 +lat_0=46.8 +lon_0=0 +k_0=0.99987742 +x_0=60 +y_0=20 +a=6378249.2 +b=6356515 +to wgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs ' OGC WKT : PROJCS[NTF (Paris) / Centre France (deprecated), GEOGCS[NTF (Paris), DATUM[Nouvelle_Triangulation_Francaise_Paris, SPHEROID[Clarke 1880 (IGN),6378249.2,293.4660212936265, AUTHORITY[EPSG,7011]], TOWGS84[-168,-60,320,0,0,0,0], AUTHORITY[EPSG,6807]], PRIMEM[Paris,2.33722917, AUTHORITY[EPSG,8903]], UNIT[grad,0.01570796326794897, AUTHORITY[EPSG,9105]], AUTHORITY[EPSG,4807]], PROJECTION[Lambert_Conformal_Conic_1SP], PARAMETER[latitude_of_origin,52], PARAMETER[central_meridian,0], PARAMETER[scale_factor,0.99987742], PARAMETER[false_easting,60], PARAMETER[false_northing,20], UNIT[metre,1, AUTHORITY[EPSG,9001]], AXIS[X,EAST], AXIS[Y,NORTH], AUTHORITY[EPSG,27592]] if i use this proj4 (from another map) (+proj=lcc +lat_1=45.898919 +lat_2=47.696014 +lat_0=46.8 +lon_0=2.33722916754 +x_0=60 +y_0=220 +a=6378249.2 +b=6356515.00472 +units=m +no_defs) it is somehow better. The false northing of both projection definitions differs by 2000 km. That is probably the reason why you get the shift. HTH, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Trouble with French Ecw map
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 the metadata (ECW) : PROJ= ? DATUM= ? Jean-Claude ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Better way to use GPKG from SpatiaLite
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(), GeomFromGPB() are required. It is also possible to use with any Spatialite version, but in a slower way, by specifying the INDIRECT_SQLITE dialect. In which case, GeoPackage geometries appear as Spatialite geometries after translation by OGR. I did also read this https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html#p16gpkg and made some experiments and there is another way to query GeoPackage databases from SpatiaLite and for me it feels very much more convenient if there is a need to do spatial queries. How it works is to execute first AutoGPKGStart(). Before that it would be good to check if SpatiaLite is recognizing GPKG by executing CheckGeoPackageMetaData() and since today in the SpatiaLite trunk the check can also be done with CheckSpatialMetaData(). The expected result is 4. Successful AutoGPKGStart() creates virtual GPKG tables which can be queried transparently without casting to/from GPB. The names of the virtual tables have vgpkg_ added before the main table name. I can't say if selecting -dialect SQLite could turn on the AutoGPKGStart automatically, of if the GPKG database should be opened with SQLite/SpatiaLite driver instead of GPKG driver from the beginning. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL NuGet Package
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 get involved in the NuGet package creation, I'd help in providing all details about the gisinternals packaging details and the build process. Best regards, Tamas 2015-04-14 13:45 GMT+02:00 drp33t peet.whitta...@gmail.com: 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 there are no VS .proj files to auto-generate the package from? The good news is that there seems to be much better support for native code in NuGet now (from v2.5). I don't know if this was already used or if something else like CoApp was used? Regards, Peet Whittaker -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDAL-NuGet-Package-tp5201018p5201267.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Trouble with French Ecw map
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 +y_0=20 +a=6378249.2 +b=6356515 +to wgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs ' OGC WKT : PROJCS[NTF (Paris) / Centre France (deprecated), GEOGCS[NTF (Paris), DATUM[Nouvelle_Triangulation_Francaise_Paris, SPHEROID[Clarke 1880 (IGN),6378249.2,293.4660212936265, AUTHORITY[EPSG,7011]], TOWGS84[-168,-60,320,0,0,0,0], AUTHORITY[EPSG,6807]], PRIMEM[Paris,2.33722917, AUTHORITY[EPSG,8903]], UNIT[grad,0.01570796326794897, AUTHORITY[EPSG,9105]], AUTHORITY[EPSG,4807]], PROJECTION[Lambert_Conformal_Conic_1SP], PARAMETER[latitude_of_origin,52], PARAMETER[central_meridian,0], PARAMETER[scale_factor,0.99987742], PARAMETER[false_easting,60], PARAMETER[false_northing,20], UNIT[metre,1, AUTHORITY[EPSG,9001]], AXIS[X,EAST], AXIS[Y,NORTH], AUTHORITY[EPSG,27592]] if i use this proj4 (from another map) (+proj=lcc +lat_1=45.898919 +lat_2=47.696014 +lat_0=46.8 +lon_0=2.33722916754 +x_0=60 +y_0=220 +a=6378249.2 +b=6356515.00472 +units=m +no_defs) it is somehow better. I didn't have this problem with the previous gdal version we used, but it's an old one , 1.7.2 used in Nasa Worldwind. so now, what can i say, is there something wrong with my source file? do i have to provide gdal with clue to how interpret this srs? Is there an issue with old ECW plugin? Regards Nicolas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
