Re: [gdal-dev] Request for reintroduction of an override line into gcs.override.csv
Help? Anyone? -Ursprüngliche Nachricht- Von: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] Im Auftrag von Schmid Andreas Gesendet: Mittwoch, 17. Dezember 2014 17:29 An: gdal-dev@lists.osgeo.org Betreff: [gdal-dev] Request for reintroduction of an override line into gcs.override.csv Hi I hope this is the right mailing list to ask the following: I've realized that in GDAL 1.9.2 the towgs84 parameters of the Swiss CH1903 GCS (EPSG:4149) appear incorrectly. According to [1], they should be 674.374,15.056,405.346 instead of 674.4,15.1,405.3 It seems that the origin of these rounded values is the EPSG database. In order to override them, I had to add the following line to the gcs.override.csv file: 4149,CH1903,6149,CH1903,6149,9122,7004,8901,1,0,6422,1766,1,9603,674.374,15.056,405.346 The same (almost same) line used to be included in the gcs.override.csv file until GDAL 1.7.3: [2] Would it be possible to re-include this override line into the gcs.override.csv? Thank you, Andy [1]: Formulas and constants for the calculation of the Swiss conformal cylindrical projection and for the transformation between coordinate systems, chapter 1.4: http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/sys/refsys.parsysrelated1.2487.downloadList.82881.DownloadFile.tmp/swissprojectionen.pdf [2]: https://github.com/OSGeo/gdal/blob/733829bf6f88530a92c25457a0f4d0ef0eb5f03a/gdal/data/gcs.override.csv#L29-L31 Andreas Schmid GIS-Informatiker Amt für Geoinformation SO!GIS-Koordination Rötistrasse 4 4501 Solothurn Telefon +41 32 627 75 93 Telefax +41 32 627 75 98 andreas.sch...@bd.so.ch http://www.so.ch ___ 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] Motion: Appoint Even Rouault PMC Chair
Frank Warmerdam warmerdam at pobox.com writes: Folks, Motion: Appoint Even Roualt as GDAL Project Management Committee Chair +1 Frank +1 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Request for reintroduction of an override line into gcs.override.csv
Andreas, Datum shifts are always tricky. I've dug up that issue a bit. The GDAL EPSG related files are coming from libgeotiff, from where they are synchronized with at some time (when a new EPSG database is imported typically). The change in libgeotiff that made the override disappeared from gcs.override.csv is http://trac.osgeo.org/geotiff/changeset/1819 The comment of the commit seems to suggest that the intent was just to do a refactoring on how overrides are handled, and an override was actually defined in the new file 1766 # # CH1903: Per http://bugzilla.remotesensing.org/show_bug.cgi?id=957 # 4149,1766 So it refers to coordinate operation 1766 which is defined in coordinate_operation.csv as : OGRFeature(coordinate_operation):751 coord_op_code (String) = 1766 coord_op_name (String) = CH1903 to WGS 84 (2) coord_op_type (String) = transformation source_crs_code (String) = 4149 target_crs_code (String) = 4326 coord_tfm_version (String) = BfL-CH 2 coord_op_variant (String) = 2 area_of_use_code (String) = 1286 coord_op_scope (String) = Accuracy 1.5 metres. coord_op_accuracy (String) = 1.5 coord_op_method_code (String) = 9603 uom_code_source_coord_diff (String) = uom_code_target_coord_diff (String) = remarks (String) = These parameters are derive from CH1903+ to ETRS89 (code 1647) and are used at lesser precision from CH1903 to WGS 84 as an approximation which is within the accuracy of the distortions in the CH1903 network. Replaces CH1903 to WGS 84 (1) (code 1753). information_source (String) = Bundesamt für Landestopographie. Aufbau der Landesvermessung der Schweiz 'LV95' Teil 3: Terrestrische Bezugssysteme und Bezugsrahmen. L+T 1999. data_source (String) = OGP revision_date (String) = 2007/03/22 change_id (String) = 2001.390 2006.992 2007.043 show_operation (String) = 1 deprecated (String) = 0 And whose parameter values are in coordinate_operation_parameter_value.csv : 1766,9603,8605,674.4,,9001 1766,9603,8606,15.1,,9001 1766,9603,8607,405.3,,9001 So this explains why you get the values you see now. I'm not sure if the intent was really to change the override with the refactoring or if it is more or less accidental, but IMHO, it doesn't look so wrong since coord_op_code=1766 aboce description is CH1903 to WGS 84 and These parameters are derive from CH1903+ to ETRS89 (code 1647) and are used at lesser precision from CH1903 to WGS 84 as an approximation which is within the accuracy of the distortions in the CH1903 network. Digging more, the previous override you suggest reintroducing is : OGRFeature(coordinate_operation):494 coord_op_code (String) = 1509 coord_op_name (String) = CH1903+ to CHTRF95 (1) coord_op_type (String) = transformation source_crs_code (String) = 4150 target_crs_code (String) = 4151 coord_tfm_version (String) = BfL-CH coord_op_variant (String) = 1 area_of_use_code (String) = 1286 coord_op_scope (String) = For applications to an accuracy of 0.1 metres. coord_op_accuracy (String) = 0.1 coord_op_method_code (String) = 9603 uom_code_source_coord_diff (String) = uom_code_target_coord_diff (String) = remarks (String) = This transformation is also given as CH1903+ to ETRS89 (1) (code 1647). CHTRF95 is a realisation of ETRS89. May be taken as approximate transformation CH1903+ to WGS 84 - see code 1676. information_source (String) = Bundesamt für Landestopographie. Aufbau der Landesvermessung der Schweiz 'LV95' Teil 3: Terrestrische Bezugssysteme und Bezugsrahmen. L+T 1999. data_source (String) = OGP revision_date (String) = 1999/10/20 change_id (String) = show_operation (String) = 1 deprecated (String) = 0 With values : 1509,9603,8605,674.374,,9001 1509,9603,8606,15.056,,9001 1509,9603,8607,405.346,,9001 So basically you would want datum shift for CH1903+ to be applied as well to CH1903. GDAL actually has the right values for EPSG:4150 / CH1903+ : $ gdalsrsinfo EPSG:4150 PROJ.4 : '+proj=longlat +ellps=bessel +towgs84=674.374,15.056,405.346,0,0,0,0 +no_defs ' OGC WKT : GEOGCS[CH1903+, DATUM[CH1903+, SPHEROID[Bessel 1841,6377397.155,299.1528128, AUTHORITY[EPSG,7004]], TOWGS84[674.374,15.056,405.346,0,0,0,0], AUTHORITY[EPSG,6150]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4150]] I'm not qualified enough to know if it is always appropriate to apply CH1903+ datum shift for CH1903 and unfortunately the bugzilla ticket is no longer available (I think the bugzilla database crashed and couldn't be recovered). But looking at 1.4 transformation parameters CHTRS95/ETRS89 ⇔ CH1903+ of the link you provide http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/sys/refsys.parsysrelated1.2487.downloadList.82881.DownloadFile.tmp/swissprojectionen.pdf ,
Re: [gdal-dev] Motion: Appoint Even Rouault PMC Chair
On 2015-01-05 3:45 PM, Frank Warmerdam wrote: Folks, Motion: Appoint Even Roualt as GDAL Project Management Committee Chair +1 and big thanks Even for all your work for the project Daniel -- Daniel Morissette T: +1 418-696-5056 #201 http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Problems with GDAL 1.10.1 converting from NetCDF to Geotiff
Hello, I am running GDAL 1.10.1 on an Ubuntu 14.04 machine. When I try to create a Geotiff from a NetCDF file, I get the following error. The problem does not occur when using an earlier version of GDAL (e.g. 1.9.2). I have seen some discussion of this issue on the mailing lists, but it is unclear what the workaround is. I would appreciate any information about how to get around this issue. ERROR 1: nBlockYSize = 663, only 1 supported when reading bottom-up dataset ERROR 1: NETCDF:PM25_2004_06_average.nc:Data, band 1: IReadBlock failed at X offset 0, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 I use the following as an example: gdal_translate -ot Byte -of GTiff NETCDF:PM25_2004_06_average.nc:Data pm_2004.tif Thanks for any help... -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Problems-with-GDAL-1-10-1-converting-from-NetCDF-to-Geotiff-tp5180197.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] OGR: How to access Coded Value Domains in File Geodatabases?
Hi Stefan, I found this issue too and wrote an enhancement ticket: http://trac.osgeo.org/gdal/ticket/5741 The only workaround appears to be lots of work. The GDB_Items table (a0004.gdbtable) can be read with OGR, where the code/value pairs are in attributes of XML code, which can be used to either hash the values or do an SQL JOIN. -Mike On 7 January 2015 at 14:20, Stefan Keller sfkel...@gmail.com wrote: Hi, ArcGIS offers Coded Value Domains (short: coded domain) to specify a valid set of values (code+description) for an attribute [1]. Any clues on how to access this information using ogr2ogr, i.e. how to export this to a separate table when converting e.g. from a ESRI File Geodatabase (OpenFileGDB, .gdb directories) to Spatialite or GeoPackage? Yours, S. [1] http://resources.arcgis.com/en/help/main/10.1/index.html#//001s000100 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR: How to access Coded Value Domains in File Geodatabases?
Hi, ArcGIS offers Coded Value Domains (short: coded domain) to specify a valid set of values (code+description) for an attribute [1]. Any clues on how to access this information using ogr2ogr, i.e. how to export this to a separate table when converting e.g. from a ESRI File Geodatabase (OpenFileGDB, .gdb directories) to Spatialite or GeoPackage? Yours, S. [1] http://resources.arcgis.com/en/help/main/10.1/index.html#//001s000100 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problems with GDAL 1.10.1 converting from NetCDF to Geotiff
Dear Victoria,
You can try
export GDAL_NETCDF_BOTTOMUP=NO
just before launching gdal_translate
but note that this works only if your dataset is oriented north-south
For GDAL developpers: I have implemented a path on my version to force
blockYSize to 1 if bottomup dataset :
- gdal/frmts/netcdf/netcdfdataset.cpp -
index f9de39f..5b7a16a 100644 @@ -457,6 +457,15 @@
netCDFRasterBand::netCDFRasterBand( netCDFDataset *poNCDFDS,
}
}
#endif
+
+/* */
+/* Force block size to 1 scanline for bottom-up datasets if*/
+/* nBlockYSize != 1*/
+/* */
+if( poNCDFDS-bBottomUp nBlockYSize != 1 ) {
+nBlockXSize = nRasterXSize;
+nBlockYSize = 1;
+}
}
I have also implemented several other improvements on the netCDF Driver
(including full support of groups and netCDF4), I will provide them to the
community ASAP.
Best Regards,
Julien
-Message d'origine-
De : gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org]
De la part de VictoriaH
Envoyé : mardi 6 janvier 2015 16:11
À : gdal-dev@lists.osgeo.org
Objet : [gdal-dev] Problems with GDAL 1.10.1 converting from NetCDF to Geotiff
Hello,
I am running GDAL 1.10.1 on an Ubuntu 14.04 machine. When I try to create a
Geotiff from a NetCDF file, I get the following error. The problem does not
occur when using an earlier version of GDAL (e.g. 1.9.2). I have seen some
discussion of this issue on the mailing lists, but it is unclear what the
workaround is. I would appreciate any information about how to get around this
issue.
ERROR 1: nBlockYSize = 663, only 1 supported when reading bottom-up dataset
ERROR 1: NETCDF:PM25_2004_06_average.nc:Data, band 1: IReadBlock failed at X
offset 0, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 0, Y block
offset 0
I use the following as an example:
gdal_translate -ot Byte -of GTiff NETCDF:PM25_2004_06_average.nc:Data
pm_2004.tif
Thanks for any help...
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Problems-with-GDAL-1-10-1-converting-from-NetCDF-to-Geotiff-tp5180197.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
Re: [gdal-dev] Motion: Appoint Even Rouault PMC Chair
Congratulations Even and big thanks for your great efforts! Mateusz Łoskot (Sent from mobile) On 5 Jan 2015 21:45, Frank Warmerdam warmer...@pobox.com wrote: Folks, Motion: Appoint Even Roualt as GDAL Project Management Committee Chair +1 Frank --- For at least a couple years, if not longer, Even has been the leading contributor to the GDAL project. As we start a fresh year in the middle of the 2010s I think it is time for us to formally acknowledge Even as the project leader. The PMC chair doesn't really have many responsibilities, beyond ensuring that the PMC operates in an orderly fashion and acting as liason to the OSGeo board when needed. But it is also a recognition of Even's great work, technically and increasingly in other outward facing efforts such as his upcoming presentation on GDAL at FOSS4G NA in March. I am very pleased to have my project pass into his capable hands, and I trust his instincts on technical and collaborative matters. I will continue on as a member of the PMC and commiters list of course. Best regards, Frank -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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] Problems with GDAL 1.10.1 converting from NetCDF to Geotiff
Thank you,
Setting the environmental variable worked
V
On 01/06/2015 09:11 AM, Julien Demaria wrote:
Dear Victoria,
You can try
export GDAL_NETCDF_BOTTOMUP=NO
just before launching gdal_translate
but note that this works only if your dataset is oriented north-south
For GDAL developpers: I have implemented a path on my version to force
blockYSize to 1 if bottomup dataset :
- gdal/frmts/netcdf/netcdfdataset.cpp -
index f9de39f..5b7a16a 100644 @@ -457,6 +457,15 @@
netCDFRasterBand::netCDFRasterBand( netCDFDataset *poNCDFDS,
}
}
#endif
+
+/* */
+/* Force block size to 1 scanline for bottom-up datasets if*/
+/* nBlockYSize != 1*/
+/* */
+if( poNCDFDS-bBottomUp nBlockYSize != 1 ) {
+nBlockXSize = nRasterXSize;
+nBlockYSize = 1;
+}
}
I have also implemented several other improvements on the netCDF Driver
(including full support of groups and netCDF4), I will provide them to the
community ASAP.
Best Regards,
Julien
-Message d'origine-
De : gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org]
De la part de VictoriaH
Envoyé : mardi 6 janvier 2015 16:11
À : gdal-dev@lists.osgeo.org
Objet : [gdal-dev] Problems with GDAL 1.10.1 converting from NetCDF to Geotiff
Hello,
I am running GDAL 1.10.1 on an Ubuntu 14.04 machine. When I try to create a
Geotiff from a NetCDF file, I get the following error. The problem does not
occur when using an earlier version of GDAL (e.g. 1.9.2). I have seen some
discussion of this issue on the mailing lists, but it is unclear what the
workaround is. I would appreciate any information about how to get around this
issue.
ERROR 1: nBlockYSize = 663, only 1 supported when reading bottom-up dataset
ERROR 1: NETCDF:PM25_2004_06_average.nc:Data, band 1: IReadBlock failed at X
offset 0, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 0, Y block
offset 0
I use the following as an example:
gdal_translate -ot Byte -of GTiff NETCDF:PM25_2004_06_average.nc:Data
pm_2004.tif
Thanks for any help...
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Problems-with-GDAL-1-10-1-converting-from-NetCDF-to-Geotiff-tp5180197.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] OGR CSV Example Header Format
I'm running gdal 1.11.1 on OS X Mavericks. I was not able to get the OGR csv driver to work with the example header provided in the driver documentation and gdal_grid documentation. The SrcDataSource line in the vrt header needed to be changed from SrcDataSourcetest.csv/SrcDataSource to SrcDataSource relativeToVRT=1test.csv/SrcDataSource. I assume it is a typo. Regards, Mitch Mitch ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
