Re: [gdal-dev] EPSG code not recognized from GeoTiff written by GDAL
> gdal_translate -a_srs EPSG:25832 in.tif out.tif adds the AUTHORITY parameter > to the GeoTIFF, while gdal_edit -a_srs EPSG:25832 does not. That's weird that gdal_edit does'nt set it correctly. I just tested it and it works for me. $ cp autotest/gcore/data/byte.tif tmp.tif; python gdal/swig/python/scripts/gdal_edit.py -a_srs EPSG:25832 tmp.tif $ gdalinfo tmp.tif Driver: GTiff/GeoTIFF Files: tmp.tif Size is 20, 20 Coordinate System is: PROJCS["ETRS89 / UTM zone 32N", GEOGCS["ETRS89", DATUM["European_Terrestrial_Reference_System_1989", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6258"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4258"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",9], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AXIS["Easting",EAST], AXIS["Northing",NORTH], AUTHORITY["EPSG","25832"]] > Kind regards, > Stefan > > P.S.: This is the output from listgeo > LC81980182015183LGN00_LST_const_LC.tif TIFFReadDirectory: Warning, Unknown > field with tag 42112 (0xa480) encountered. TIFFReadDirectory: Warning, > Unknown field with tag 42113 (0xa481) encountered. Geotiff_Information: >Version: 1 >Key_Revision: 1.0 >Tagged_Information: > ModelTiepointTag (2,3): > 0 0 0 > 4175856784515 0 > ModelPixelScaleTag (1,3): > 30300 > End_Of_Tags. >Keyed_Information: > GTModelTypeGeoKey (Short,1): ModelTypeProjected > GTRasterTypeGeoKey (Short,1): RasterPixelIsArea > GTCitationGeoKey (Ascii,30): "Universal Transverse Mercator" > GeographicTypeGeoKey (Short,1): User-Defined > GeogCitationGeoKey (Ascii,80): "GCS Name = grs80|Ellipsoid = > Geodetic_Refe rence_System_1980|Primem = Greenwich|" > GeogGeodeticDatumGeoKey (Short,1): > Datum_European_Reference_System_1989 GeogAngularUnitsGeoKey (Short,1): > Angular_Degree > GeogSemiMajorAxisGeoKey (Double,1): 6378137 > GeogInvFlatteningGeoKey (Double,1): 298.257222101 > GeogPrimeMeridianLongGeoKey (Double,1): 0 > ProjectedCSTypeGeoKey (Short,1): User-Defined > ProjectionGeoKey (Short,1): Proj_UTM_zone_32N > ProjLinearUnitsGeoKey (Short,1): Linear_Meter > End_Of_Keys. >End_Of_Geotiff. > > Projection = 16032 (UTM zone 32N) > Projection Method: CT_TransverseMercator >ProjNatOriginLatGeoKey: 0.00 ( 0d 0' 0.00"N) >ProjNatOriginLongGeoKey: 9.00 ( 9d 0' 0.00"E) >ProjScaleAtNatOriginGeoKey: 0.999600 >ProjFalseEastingGeoKey: 50.00 m >ProjFalseNorthingGeoKey: 0.00 m > Datum: 6258/European Terrestrial Reference System 1989 > Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31) > Projection Linear Units: 9001/metre (1.00m) > > Corner Coordinates: > Upper Left( 417585.000, 6784515.000) ( 7d28' 1.67"E, 61d11'11.02"N) > Lower Left( 417585.000, 6538485.000) ( 7d33'58.86"E, 58d58'40.77"N) > Upper Right ( 660915.000, 6784515.000) ( 11d59'28.13"E, 61d 9'43.28"N) > Lower Right ( 660915.000, 6538485.000) ( 11d47'51.98"E, 58d57'20.48"N) > Center( 539250.000, 6661500.000) ( 9d42'20.11"E, 60d 5'19.35"N) > > > > -Original Message- > From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Even > Rouault Sent: 27. mai 2016 14:28 > To: gdal-dev@lists.osgeo.org > Cc: Jukka Rahkonen > Subject: Re: [gdal-dev] EPSG code not recognized from GeoTiff written by > GDAL > On Friday 27 May 2016 11:46:14 Jukka Rahkonen wrote: > > > Blumentrath, Stefan nina.no> writes: > > > > > Hei, > > > > > > > > > > > > We are facing issues with GeoTiffs that were written by GDAL, after > > > > > > importing them to GeoServer or opening in Desktop GIS. > > > > > > > On file was produced in GRASS and exported using r.out.gdal (GDAL > > > 2.1dev), > > > > > > the other file in R, using rgdal (GDAL2.0.x) with EPSG code 25832. > > > > > > > The rasters seem to miss the AUTHORITY parameter... > > > > > > > > > > > > QGIS for example detects EPSG 3044 (which is technically identical), > > > and > > > > > > GeoServer considers the CRS as invalid (because of this: > > > > http://docs.geonode.org/en/master/tutorials/advanced/geonode_productio > > n/adv_ > > gsconfig/crs_handling.html). > > > > > > > > > > > Did anyone else experience the same? > > > > > > Hi, > > > > From my GDAL 2.1-dev > > > > gdalsrsinfo epsg:25832 > > > > PROJ.4 : '+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 > > +units=
Re: [gdal-dev] EPSG code not recognized from GeoTiff written by GDAL
Hi, And thanks Even and Jukka for your answers! Based on the info you provided I investigated a bit more and it seems to be an issue "downstreams" indeed. gdalsrsinfo epsg:25832 gave the same result for me than for Jukka (the result from listgeo further down, just for the record). In GRASS GIS 7.0.4 and 7.1.svn, g.proj -w gave me the projection information as in the GeoTIFF, though without any AUTHORITY parameters (as it is supposed to according to the manual). The AUTHORITY tags seem to be added by r.out.gdal, except for the authority parameter for the entire projection... Even if g.proj -g returns epsg=25832... gdal_translate -a_srs EPSG:25832 in.tif out.tif adds the AUTHORITY parameter to the GeoTIFF, while gdal_edit -a_srs EPSG:25832 does not. Kind regards, Stefan P.S.: This is the output from listgeo LC81980182015183LGN00_LST_const_LC.tif TIFFReadDirectory: Warning, Unknown field with tag 42112 (0xa480) encountered. TIFFReadDirectory: Warning, Unknown field with tag 42113 (0xa481) encountered. Geotiff_Information: Version: 1 Key_Revision: 1.0 Tagged_Information: ModelTiepointTag (2,3): 0 0 0 4175856784515 0 ModelPixelScaleTag (1,3): 30300 End_Of_Tags. Keyed_Information: GTModelTypeGeoKey (Short,1): ModelTypeProjected GTRasterTypeGeoKey (Short,1): RasterPixelIsArea GTCitationGeoKey (Ascii,30): "Universal Transverse Mercator" GeographicTypeGeoKey (Short,1): User-Defined GeogCitationGeoKey (Ascii,80): "GCS Name = grs80|Ellipsoid = Geodetic_Refe rence_System_1980|Primem = Greenwich|" GeogGeodeticDatumGeoKey (Short,1): Datum_European_Reference_System_1989 GeogAngularUnitsGeoKey (Short,1): Angular_Degree GeogSemiMajorAxisGeoKey (Double,1): 6378137 GeogInvFlatteningGeoKey (Double,1): 298.257222101 GeogPrimeMeridianLongGeoKey (Double,1): 0 ProjectedCSTypeGeoKey (Short,1): User-Defined ProjectionGeoKey (Short,1): Proj_UTM_zone_32N ProjLinearUnitsGeoKey (Short,1): Linear_Meter End_Of_Keys. End_Of_Geotiff. Projection = 16032 (UTM zone 32N) Projection Method: CT_TransverseMercator ProjNatOriginLatGeoKey: 0.00 ( 0d 0' 0.00"N) ProjNatOriginLongGeoKey: 9.00 ( 9d 0' 0.00"E) ProjScaleAtNatOriginGeoKey: 0.999600 ProjFalseEastingGeoKey: 50.00 m ProjFalseNorthingGeoKey: 0.00 m Datum: 6258/European Terrestrial Reference System 1989 Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31) Projection Linear Units: 9001/metre (1.00m) Corner Coordinates: Upper Left( 417585.000, 6784515.000) ( 7d28' 1.67"E, 61d11'11.02"N) Lower Left( 417585.000, 6538485.000) ( 7d33'58.86"E, 58d58'40.77"N) Upper Right ( 660915.000, 6784515.000) ( 11d59'28.13"E, 61d 9'43.28"N) Lower Right ( 660915.000, 6538485.000) ( 11d47'51.98"E, 58d57'20.48"N) Center( 539250.000, 6661500.000) ( 9d42'20.11"E, 60d 5'19.35"N) -Original Message- From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Even Rouault Sent: 27. mai 2016 14:28 To: gdal-dev@lists.osgeo.org Cc: Jukka Rahkonen Subject: Re: [gdal-dev] EPSG code not recognized from GeoTiff written by GDAL On Friday 27 May 2016 11:46:14 Jukka Rahkonen wrote: > Blumentrath, Stefan nina.no> writes: > > Hei, > > > > We are facing issues with GeoTiffs that were written by GDAL, after > > importing them to GeoServer or opening in Desktop GIS. > > > On file was produced in GRASS and exported using r.out.gdal (GDAL > > 2.1dev), > > the other file in R, using rgdal (GDAL2.0.x) with EPSG code 25832. > > > The rasters seem to miss the AUTHORITY parameter... > > > > QGIS for example detects EPSG 3044 (which is technically identical), > > and > > GeoServer considers the CRS as invalid (because of this: > > http://docs.geonode.org/en/master/tutorials/advanced/geonode_productio > n/adv_ > gsconfig/crs_handling.html). > > > > Did anyone else experience the same? > > Hi, > > From my GDAL 2.1-dev > > gdalsrsinfo epsg:25832 > > PROJ.4 : '+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 > +units=m > +no_de fs ' > > OGC WKT : > PROJCS["ETRS89 / UTM zone 32N", > GEOGCS["ETRS89", > DATUM["European_Terrestrial_Reference_System_1989", > SPHEROID["GRS 1980",6378137,298.257222101, > AUTHORITY["EPSG","7019"]], > TOWGS84[0,0,0,0,0,0,0], > AUTHORITY["EPSG","6258"]], > PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], > UNIT["degree",0.0174532925199433, > AUTHORITY["EPSG","9122"]], > AUTHORITY["EPSG","4258"]], > PROJECTION["Transverse_Mercator"], > PARAMETER["latitude_of_origin",0], > PARAMETER["central_meridian",9], > PARAMETER["scale_factor",0.9996], > PARAMETER["false_easting",50], > PARAMETER["false_northing",0], > UNIT["metre",1,
Re: [gdal-dev] Building GDAL on Windows 32 and 64 bit
Hi Alex, The work is done taking into considerations this link: https://trac.osgeo.org/gdal/wiki/CMake Also, there were some ideas about gdal source code reorganisation in dev-list. This is second turn of cmakefication of GDAL. The lib_gdal repository synced with gdal trunk periodically (there is a python script in etc folder (https://github.com/nextgis-borsch/lib_gdal/blob/master/etc/cmake-build-helpers/gdal_restructure.py) to do it). Now the sources are 2.1 release version. The different GDAL version support will be added in future. I think current lib_gdal is not ready to switch trunk (not all drivers ready, not all bindings ready, etc.), but very close (see https://github.com/nextgis-borsch/lib_gdal/blob/master/README.md about work status). Best regards, Dmitry 27.05.2016 14:56, alex пишет: [Alex] Is there a convention about where to place and how to name the win32 and x64 libraries and include directories when building for both platforms on Windows? Especially, I would like CMake's FindGDAL (https://cmake.org/cmake/help/v3.0/module/FindGDAL.html) to be able to find the correct paths automatically. [Dmitry Baryshnikov] Hi, It seems to me there is no standard install path on Windows, so search GDAL is tricky. CMake can register package in registry and so find GDAL, but GDAL have to be CMaked too. You may try our CMake GDAL (https://github.com/nextgis-borsch/lib_gdal). In your project only need to add find_anyproject(GDAL), see - https://github.com/nextgis-borsch/borsch. GDAL will be downloaded, build and linked with your project. Hi Dmitry, Thanks, that looks very useful and addresses a major headache. I am a bit reluctant to include further dependencies and straying from the 'official' GDAL repository and processes. Is there any chance that your efforts will make it to a future GDAL release? ___ 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] Spatial index to raster VRT
Even Rouault spatialys.com> writes: > > On Thursday 26 May 2016 13:26:38 Jukka Rahkonen wrote: > > > > VRT supports one overview, but that can itself be a VRT, which in turn can > > point to next VRT overview and so on. > Actually, this is not true (although I might have in the past say so). The doc > currently states : > """ > Overview: This optional element describes one overview level for the band. It > should have a child SourceFilename and SourceBand element. The SourceFilename > may have a relativeToVRT boolean attribute. Multiple elements may be used to > describe multiple overviews. > """ > > and I've verified it works (at least they are reported by gdalinfo) Confirmed by adding several tiff files with increasing pixel size as Overview elements into the same VRT. Works fine. Still missing the main thing - spatial index for making access to small region fast with thousands or images in VRT. -Jukka- > > Even > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to recognize FDO style SQLite db?
Even Rouault spatialys.com> writes: > This probably doesn't completely fullfil the requirement of "simple mean" , > but if you enable the debug messages from GDAL with "--debug on", you should > see : > "OGR style SQLite DB found !" > > whereas a Spatialite one will trigger : > "SpatiaLite v4 DB found !" (or "Spatialite DB found" for spatialite 2 or 3) Simple enough, I'll try to find some place to document that in http://www.gdal.org/drv_sqlite.html. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to recognize FDO style SQLite db?
On Friday 27 May 2016 12:09:42 Jukka Rahkonen wrote: > Hi, > > User in gis.stackoverflow tried to use SQL "select ST_Union(geometry)" for > the Natural Earth SQLite db file from > http://naciscdn.org/naturalearth/packages/natural_earth_vector.sqlite.zip. > > The query yields an empty geometry because the NE database is written with > FDO geometries instead of SpatiaLite geometries. What I wonder is that does > GDAL user have any simple mean for getting informed if SQLite db is FDO or > Spatialite. This probably doesn't completely fullfil the requirement of "simple mean" ;-), but if you enable the debug messages from GDAL with "--debug on", you should see : "OGR style SQLite DB found !" whereas a Spatialite one will trigger : "SpatiaLite v4 DB found !" (or "Spatialite DB found" for spatialite 2 or 3) > If SpatiaLite is present a clever enough user can use ogrinfo > and check from > https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html#p16fdo that > value 2 is returned in case when "both tables exist, and their layout is the > one used by FDO/OGR" > > ogrinfo -sql "select CheckSpatialMetaData()" > natural_earth_vector.sqlite > INFO: Open of `natural_earth_vector.sqlite' > using driver `SQLite' successful. > > Layer name: SELECT > Geometry: None > Feature Count: 1 > Layer SRS WKT: > (unknown) > CheckSpatialMetaData(): Integer (0.0) > OGRFeature(SELECT):0 > CheckSpatialMetaData() (Integer) = 2 > > > However, the one who knows to do that must be somewhat advanced GDAL and > Spatialite user. > > -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] EPSG code not recognized from GeoTiff written by GDAL
On Friday 27 May 2016 11:46:14 Jukka Rahkonen wrote: > Blumentrath, Stefan nina.no> writes: > > Hei, > > > > We are facing issues with GeoTiffs that were written by GDAL, after > > importing them to GeoServer or opening in Desktop GIS. > > > On file was produced in GRASS and exported using r.out.gdal (GDAL 2.1dev), > > the other file in R, using rgdal (GDAL2.0.x) with EPSG code 25832. > > > The rasters seem to miss the AUTHORITY parameter... > > > > QGIS for example detects EPSG 3044 (which is technically identical), and > > GeoServer considers the CRS as invalid (because of this: > > http://docs.geonode.org/en/master/tutorials/advanced/geonode_production/adv_ > gsconfig/crs_handling.html). > > > > Did anyone else experience the same? > > Hi, > > From my GDAL 2.1-dev > > gdalsrsinfo epsg:25832 > > PROJ.4 : '+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m > +no_de fs ' > > OGC WKT : > PROJCS["ETRS89 / UTM zone 32N", > GEOGCS["ETRS89", > DATUM["European_Terrestrial_Reference_System_1989", > SPHEROID["GRS 1980",6378137,298.257222101, > AUTHORITY["EPSG","7019"]], > TOWGS84[0,0,0,0,0,0,0], > AUTHORITY["EPSG","6258"]], > PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], > UNIT["degree",0.0174532925199433, > AUTHORITY["EPSG","9122"]], > AUTHORITY["EPSG","4258"]], > PROJECTION["Transverse_Mercator"], > PARAMETER["latitude_of_origin",0], > PARAMETER["central_meridian",9], > PARAMETER["scale_factor",0.9996], > PARAMETER["false_easting",50], > PARAMETER["false_northing",0], > UNIT["metre",1, > AUTHORITY["EPSG","9001"]], > AXIS["Easting",EAST], > AXIS["Northing",NORTH], > AUTHORITY["EPSG","25832"]] > > > Do you get the same result? If you do I wonder why AUTHORITY is not written > into GeoTIFF. For diagnosing, what is interesting is the output of the listgeo utility that comes with libgeotiff. Theoretically the EPSG code should be preserved in the geotiff keys if it is available in the source raster (gdal_translate use case), or if set with the SetProjection() API. I'm not sure about GRASS or R but perhaps they build the GDAL SRS object from a proj.4 string, in which case the EPSG code will be missing. > > -Jukka Rahkonen- > > > > > Kind regards, > > Stefan > > ___ > 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
[gdal-dev] How to recognize FDO style SQLite db?
Hi, User in gis.stackoverflow tried to use SQL "select ST_Union(geometry)" for the Natural Earth SQLite db file from http://naciscdn.org/naturalearth/packages/natural_earth_vector.sqlite.zip. The query yields an empty geometry because the NE database is written with FDO geometries instead of SpatiaLite geometries. What I wonder is that does GDAL user have any simple mean for getting informed if SQLite db is FDO or Spatialite. If SpatiaLite is present a clever enough user can use ogrinfo and check from https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html#p16fdo that value 2 is returned in case when "both tables exist, and their layout is the one used by FDO/OGR" ogrinfo -sql "select CheckSpatialMetaData()" natural_earth_vector.sqlite INFO: Open of `natural_earth_vector.sqlite' using driver `SQLite' successful. Layer name: SELECT Geometry: None Feature Count: 1 Layer SRS WKT: (unknown) CheckSpatialMetaData(): Integer (0.0) OGRFeature(SELECT):0 CheckSpatialMetaData() (Integer) = 2 However, the one who knows to do that must be somewhat advanced GDAL and Spatialite user. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Building GDAL on Windows 32 and 64 bit
>> [Alex] >> Is there a convention about where to place and how to name the win32 and >x64 >> libraries and include directories when building for both platforms on >> Windows? >> >> Especially, I would like CMake's FindGDAL >> (https://cmake.org/cmake/help/v3.0/module/FindGDAL.html) to be able to >find >> the correct paths automatically. >> > [Dmitry Baryshnikov] > >Hi, >It seems to me there is no standard install path on Windows, so search >GDAL is tricky. >CMake can register package in registry and so find GDAL, but GDAL have >to be CMaked too. > >You may try our CMake GDAL (https://github.com/nextgis-borsch/lib_gdal). >In your project only need to add find_anyproject(GDAL), see - >https://github.com/nextgis-borsch/borsch. >GDAL will be downloaded, build and linked with your project. > Hi Dmitry, Thanks, that looks very useful and addresses a major headache. I am a bit reluctant to include further dependencies and straying from the 'official' GDAL repository and processes. Is there any chance that your efforts will make it to a future GDAL release? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] EPSG code not recognized from GeoTiff written by GDAL
Blumentrath, Stefan nina.no> writes: > Hei, > > We are facing issues with GeoTiffs that were written by GDAL, after importing them to GeoServer or opening in Desktop GIS. > On file was produced in GRASS and exported using r.out.gdal (GDAL 2.1dev), the other file in R, using rgdal (GDAL2.0.x) with EPSG code 25832. > The rasters seem to miss the AUTHORITY parameter... > > QGIS for example detects EPSG 3044 (which is technically identical), and GeoServer considers the CRS as invalid (because of this: > http://docs.geonode.org/en/master/tutorials/advanced/geonode_production/adv_gsconfig/crs_handling.html). > > Did anyone else experience the same? Hi, From my GDAL 2.1-dev gdalsrsinfo epsg:25832 PROJ.4 : '+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_de fs ' OGC WKT : PROJCS["ETRS89 / UTM zone 32N", GEOGCS["ETRS89", DATUM["European_Terrestrial_Reference_System_1989", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6258"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4258"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",9], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AXIS["Easting",EAST], AXIS["Northing",NORTH], AUTHORITY["EPSG","25832"]] Do you get the same result? If you do I wonder why AUTHORITY is not written into GeoTIFF. -Jukka Rahkonen- > > Kind regards, > Stefan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] EPSG code not recognized from GeoTiff written by GDAL
Hei, We are facing issues with GeoTiffs that were written by GDAL, after importing them to GeoServer or opening in Desktop GIS. On file was produced in GRASS and exported using r.out.gdal (GDAL 2.1dev), the other file in R, using rgdal (GDAL2.0.x) with EPSG code 25832. The rasters seem to miss the AUTHORITY parameter... QGIS for example detects EPSG 3044 (which is technically identical), and GeoServer considers the CRS as invalid (because of this: http://docs.geonode.org/en/master/tutorials/advanced/geonode_production/adv_gsconfig/crs_handling.html). Did anyone else experience the same? Kind regards, Stefan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Building GDAL on Windows 32 and 64 bit
Hi, It seems to me there is no standard install path on Windows, so search GDAL is tricky. CMake can register package in registry and so find GDAL, but GDAL have to be CMaked too. You may try our CMake GDAL (https://github.com/nextgis-borsch/lib_gdal). In your project only need to add find_anyproject(GDAL), see - https://github.com/nextgis-borsch/borsch. GDAL will be downloaded, build and linked with your project. Best regards, Dmitry 27.05.2016 11:55, alex пишет: Hi, Is there a convention about where to place and how to name the win32 and x64 libraries and include directories when building for both platforms on Windows? Especially, I would like CMake's FindGDAL (https://cmake.org/cmake/help/v3.0/module/FindGDAL.html) to be able to find the correct paths automatically. Thanks, Alex ___ 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] Building GDAL on Windows 32 and 64 bit
Hi, Is there a convention about where to place and how to name the win32 and x64 libraries and include directories when building for both platforms on Windows? Especially, I would like CMake's FindGDAL (https://cmake.org/cmake/help/v3.0/module/FindGDAL.html) to be able to find the correct paths automatically. Thanks, Alex ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
