[gdal-dev] Request for reintroduction of an override line into gcs.override.csv
Schmid Andreas
Andreas.Schmid at bd.so.ch
Wed Jan 7 09:43:15 PST 2015
Even,
Thank you a lot for digging so deep. It seems indeed quite tricky.
>I'm not sure if the intent was really to change the override with the
>refactoring or if it is more or less accidental
I also realized that it was during a refactoring that this (and other) overrides were removed. So I rather felt like the removal was accidental. (Or that the overrides are solved in a different way now, but I couldn't find out how.)
>So basically you would want datum shift for CH1903+ to be applied as well to
>CH1903.
Exactly. The reason is: Even though the transformed coordinates can be false up to 1.6 meters when using this datum shift, they won't become any better when using the rounded datum shift values. However they will become worse in a way, as using the rounded datum shift values adds some additional noise to the transformation results. For example, performing a transformation from CH1903+ to CH1903 should not modify the coordinates at all. But working with the current two different sets of parameters modifies the coordinates slightliy, which is not correct and may confuse the end user.
>If you can still think the previous override should be applied in the
>CH1903==>WGS84 case, it would be great to find clear references about that.
I unfortunately couldn't find a more clear reference until now than the document from swisstopo already given. But to sum it up, the following points indicate that applying the previous override again would be reasonable:
* according to an older version of the gcs.override.csv file, the override obviously has been approved at some point in the past
* it rather looks like the removal of the override was accidental
* even if the transformed coordinates can be false up to 1.6 meters, transformations from CH1903+ to CH1903 should not arbitrarily modify the coordinates in order to not confuse the end user
* as the transformed coordinates can be false up to 1.6 meters anyway, we don't loose anything by using the unrounded parameters
>Isn't your issue that datasets should be referenced as EPSG:4150 instead of
>EPSG:4149 ?
Not really. While this would basically solve the issue, referencing EPSG:4150 instead of EPSG:4149 is wrong from a systematic point of view.
Best regards,
Andy
-----Ursprüngliche Nachricht-----
Von: Even Rouault [mailto:even.rouault at spatialys.com]
Gesendet: Dienstag, 6. Januar 2015 15:08
An: gdal-dev at lists.osgeo.org
Cc: Schmid Andreas
Betreff: 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
, "Without any restrictions they can also be used for the system ETRS89 and
for many applications also for CH1903. But in the case of CH1903, one must be
aware that because of the local distortions of this network the transformed
coordinates can be false by up to 1.6 meters compared to the official
coordinates in CH1903", which would seem to suggest that the CH1903+
parameters don't necessarily apply to CH1903.
If you can still think the previous override should be applied in the
CH1903==>WGS84 case, it would be great to find clear references about that.
Isn't your issue that datasets should be referenced as EPSG:4150 instead of
EPSG:4149 ?
Even
Le mardi 06 janvier 2015 14:02:33, Schmid Andreas a écrit :
> Help? Anyone?
>
>
> -----Ursprüngliche Nachricht-----
> Von: gdal-dev-bounces at lists.osgeo.org
> [mailto:gdal-dev-bounces at lists.osgeo.org] Im Auftrag von Schmid Andreas
> Gesendet: Mittwoch, 17. Dezember 2014 17:29
> An: gdal-dev at 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,1
> 5.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/swissprojec
> tionen.pdf [2]:
> https://github.com/OSGeo/gdal/blob/733829bf6f88530a92c25457a0f4d0ef0eb5f03
> a/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.schmid at bd.so.ch
> http://www.so.ch
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Spatialys - Geospatial professional services
http://www.spatialys.com
More information about the gdal-dev
mailing list