<div dir="ltr">Schmid,<div><br></div><div>If you file a ticket against libgeotiff (<a href="http://trac.osgeo.org/geotiff/">http://trac.osgeo.org/geotiff/</a>) capturing the details of the above discussion, I'll review and consider reapplying the override.</div><div><br></div><div>I haven't looked into this issue in detail yet, but I'm concerned you want to apply a particular transform to CH1903+ that EPSG does not offer as one of the routes to WGS84. I have tried to move to the new approach where overrides are almost always just given priority to a particular EPSG transformation over others rather than providing transformations not included in the EPSG set. Hopefully that won't be the case here.</div><div><br></div><div>Best regards,</div><div>Frank</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 9:43 AM, Schmid Andreas <span dir="ltr"><<a href="mailto:Andreas.Schmid@bd.so.ch" target="_blank">Andreas.Schmid@bd.so.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Even,<br>
<br>
Thank you a lot for digging so deep. It seems indeed quite tricky.<br>
<span class=""><br>
>I'm not sure if the intent was really to change the override with the<br>
>refactoring or if it is more or less accidental<br>
<br>
</span>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.)<br>
<span class=""><br>
>So basically you would want datum shift for CH1903+ to be applied as well to<br>
>CH1903.<br>
<br>
</span>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.<br>
<span class=""><br>
>If you can still think the previous override should be applied in the<br>
>CH1903==>WGS84 case, it would be great to find clear references about that.<br>
<br>
</span>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:<br>
* according to an older version of the gcs.override.csv file, the override obviously has been approved at some point in the past<br>
* it rather looks like the removal of the override was accidental<br>
* 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<br>
* as the transformed coordinates can be false up to 1.6 meters anyway, we don't loose anything by using the unrounded parameters<br>
<span class=""><br>
>Isn't your issue that datasets should be referenced as EPSG:4150 instead of<br>
>EPSG:4149 ?<br>
<br>
</span>Not really. While this would basically solve the issue, referencing EPSG:4150 instead of EPSG:4149 is wrong from a systematic point of view.<br>
<br>
<br>
Best regards,<br>
Andy<br>
<br>
<br>
<br>
<br>
<br>
-----Ursprüngliche Nachricht-----<br>
Von: Even Rouault [mailto:<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>]<br>
Gesendet: Dienstag, 6. Januar 2015 15:08<br>
An: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
Cc: Schmid Andreas<br>
Betreff: Re: [gdal-dev] Request for reintroduction of an override line into gcs.override.csv<br>
<div class="HOEnZb"><div class="h5"><br>
Andreas,<br>
<br>
Datum shifts are always tricky. I've dug up that issue a bit.<br>
<br>
The GDAL EPSG related files are coming from libgeotiff, from where they are<br>
synchronized with at some time (when a new EPSG database is imported<br>
typically). The change in libgeotiff that made the override disappeared from<br>
gcs.override.csv is <a href="http://trac.osgeo.org/geotiff/changeset/1819" target="_blank">http://trac.osgeo.org/geotiff/changeset/1819</a><br>
The comment of the commit seems to suggest that the intent was just to do a<br>
refactoring on how overrides are handled, and an override was actually defined<br>
in the new file 1766<br>
<br>
<br>
####################################################################<br>
#<br>
# CH1903: Per <a href="http://bugzilla.remotesensing.org/show_bug.cgi?id=957" target="_blank">http://bugzilla.remotesensing.org/show_bug.cgi?id=957</a><br>
#<br>
4149,1766<br>
<br>
So it refers to coordinate operation 1766 which is defined in<br>
coordinate_operation.csv as :<br>
<br>
OGRFeature(coordinate_operation):751<br>
coord_op_code (String) = 1766<br>
coord_op_name (String) = CH1903 to WGS 84 (2)<br>
coord_op_type (String) = transformation<br>
source_crs_code (String) = 4149<br>
target_crs_code (String) = 4326<br>
coord_tfm_version (String) = BfL-CH 2<br>
coord_op_variant (String) = 2<br>
area_of_use_code (String) = 1286<br>
coord_op_scope (String) = Accuracy 1.5 metres.<br>
coord_op_accuracy (String) = 1.5<br>
coord_op_method_code (String) = 9603<br>
uom_code_source_coord_diff (String) =<br>
uom_code_target_coord_diff (String) =<br>
remarks (String) = These parameters are derive from CH1903+ to ETRS89 (code<br>
1647) and are used at lesser precision from CH1903 to WGS 84 as an<br>
approximation which is within the accuracy of the distortions in the CH1903<br>
network. Replaces CH1903 to WGS 84 (1) (code 1753).<br>
information_source (String) = Bundesamt für Landestopographie. Aufbau der<br>
Landesvermessung der Schweiz 'LV95' Teil 3: Terrestrische Bezugssysteme und<br>
Bezugsrahmen. L+T 1999.<br>
data_source (String) = OGP<br>
revision_date (String) = 2007/03/22<br>
change_id (String) = 2001.390 2006.992 2007.043<br>
show_operation (String) = 1<br>
deprecated (String) = 0<br>
<br>
And whose parameter values are in coordinate_operation_parameter_value.csv :<br>
<br>
1766,9603,8605,674.4,,9001<br>
1766,9603,8606,15.1,,9001<br>
1766,9603,8607,405.3,,9001<br>
<br>
So this explains why you get the values you see now.<br>
<br>
I'm not sure if the intent was really to change the override with the<br>
refactoring or if it is more or less accidental, but IMHO, it doesn't look so<br>
wrong since coord_op_code=1766 aboce description is "CH1903 to WGS 84" and<br>
"These parameters are derive from CH1903+ to ETRS89 (code 1647) and are used<br>
at lesser precision from CH1903 to WGS 84 as an approximation which is within<br>
the accuracy of the distortions in the CH1903 network."<br>
<br>
Digging more, the previous override you suggest reintroducing is :<br>
<br>
OGRFeature(coordinate_operation):494<br>
coord_op_code (String) = 1509<br>
coord_op_name (String) = CH1903+ to CHTRF95 (1)<br>
coord_op_type (String) = transformation<br>
source_crs_code (String) = 4150<br>
target_crs_code (String) = 4151<br>
coord_tfm_version (String) = BfL-CH<br>
coord_op_variant (String) = 1<br>
area_of_use_code (String) = 1286<br>
coord_op_scope (String) = For applications to an accuracy of 0.1 metres.<br>
coord_op_accuracy (String) = 0.1<br>
coord_op_method_code (String) = 9603<br>
uom_code_source_coord_diff (String) =<br>
uom_code_target_coord_diff (String) =<br>
remarks (String) = This transformation is also given as CH1903+ to ETRS89<br>
(1) (code 1647). CHTRF95 is a realisation of ETRS89. May be taken as<br>
approximate transformation CH1903+ to WGS 84 - see code 1676.<br>
information_source (String) = Bundesamt für Landestopographie. Aufbau der<br>
Landesvermessung der Schweiz 'LV95' Teil 3: Terrestrische Bezugssysteme und<br>
Bezugsrahmen. L+T 1999.<br>
data_source (String) = OGP<br>
revision_date (String) = 1999/10/20<br>
change_id (String) =<br>
show_operation (String) = 1<br>
deprecated (String) = 0<br>
<br>
With values :<br>
<br>
1509,9603,8605,674.374,,9001<br>
1509,9603,8606,15.056,,9001<br>
1509,9603,8607,405.346,,9001<br>
<br>
So basically you would want datum shift for CH1903+ to be applied as well to<br>
CH1903.<br>
<br>
GDAL actually has the right values for EPSG:4150 / CH1903+ :<br>
<br>
$ gdalsrsinfo EPSG:4150<br>
<br>
PROJ.4 : '+proj=longlat +ellps=bessel +towgs84=674.374,15.056,405.346,0,0,0,0<br>
+no_defs '<br>
<br>
OGC WKT :<br>
GEOGCS["CH1903+",<br>
DATUM["CH1903+",<br>
SPHEROID["Bessel 1841",6377397.155,299.1528128,<br>
AUTHORITY["EPSG","7004"]],<br>
TOWGS84[674.374,15.056,405.346,0,0,0,0],<br>
AUTHORITY["EPSG","6150"]],<br>
PRIMEM["Greenwich",0,<br>
AUTHORITY["EPSG","8901"]],<br>
UNIT["degree",0.0174532925199433,<br>
AUTHORITY["EPSG","9122"]],<br>
AUTHORITY["EPSG","4150"]]<br>
<br>
I'm not qualified enough to know if it is always appropriate to apply CH1903+<br>
datum shift for CH1903 and unfortunately the bugzilla ticket is no longer<br>
available (I think the bugzilla database crashed and couldn't be recovered).<br>
But looking at 1.4 "transformation parameters CHTRS95/ETRS89<br>
⇔ CH1903+" of the link you provide<br>
<a href="http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/sys/refsys.parsysrelated1.2487.downloadList.82881.DownloadFile.tmp/swissprojectionen.pdf" target="_blank">http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/sys/refsys.parsysrelated1.2487.downloadList.82881.DownloadFile.tmp/swissprojectionen.pdf</a><br>
, "Without any restrictions they can also be used for the system ETRS89 and<br>
for many applications also for CH1903. But in the case of CH1903, one must be<br>
aware that because of the local distortions of this network the transformed<br>
coordinates can be false by up to 1.6 meters compared to the official<br>
coordinates in CH1903", which would seem to suggest that the CH1903+<br>
parameters don't necessarily apply to CH1903.<br>
<br>
If you can still think the previous override should be applied in the<br>
CH1903==>WGS84 case, it would be great to find clear references about that.<br>
<br>
Isn't your issue that datasets should be referenced as EPSG:4150 instead of<br>
EPSG:4149 ?<br>
<br>
Even<br>
<br>
Le mardi 06 janvier 2015 14:02:33, Schmid Andreas a écrit :<br>
> Help? Anyone?<br>
><br>
><br>
> -----Ursprüngliche Nachricht-----<br>
> Von: <a href="mailto:gdal-dev-bounces@lists.osgeo.org">gdal-dev-bounces@lists.osgeo.org</a><br>
> [mailto:<a href="mailto:gdal-dev-bounces@lists.osgeo.org">gdal-dev-bounces@lists.osgeo.org</a>] Im Auftrag von Schmid Andreas<br>
> Gesendet: Mittwoch, 17. Dezember 2014 17:29<br>
> An: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> Betreff: [gdal-dev] Request for reintroduction of an override line into<br>
> gcs.override.csv<br>
><br>
> Hi<br>
><br>
> I hope this is the right mailing list to ask the following:<br>
><br>
> I've realized that in GDAL 1.9.2 the "towgs84" parameters of the Swiss<br>
> "CH1903" GCS (EPSG:4149) appear incorrectly. According to [1], they should<br>
> be 674.374,15.056,405.346,,,,<br>
> instead of<br>
> 674.4,15.1,405.3,,,,<br>
> It seems that the origin of these rounded values is the EPSG database. In<br>
> order to override them, I had to add the following line to the<br>
> gcs.override.csv file:<br>
> 4149,CH1903,6149,CH1903,6149,9122,7004,8901,1,0,6422,1766,1,9603,674.374,1<br>
> 5.056,405.346,,,,<br>
><br>
> The same (almost same) line used to be included in the gcs.override.csv<br>
> file until GDAL 1.7.3: [2] Would it be possible to re-include this<br>
> override line into the gcs.override.csv?<br>
><br>
> Thank you,<br>
> Andy<br>
><br>
><br>
> [1]: Formulas and constants for the calculation of the Swiss conformal<br>
> cylindrical projection and for the transformation between coordinate<br>
> systems, chapter 1.4:<br>
> <a href="http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/sys" target="_blank">http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/sys</a><br>
> /refsys.parsysrelated1.2487.downloadList.82881.DownloadFile.tmp/swissprojec<br>
> tionen.pdf [2]:<br>
> <a href="https://github.com/OSGeo/gdal/blob/733829bf6f88530a92c25457a0f4d0ef0eb5f03" target="_blank">https://github.com/OSGeo/gdal/blob/733829bf6f88530a92c25457a0f4d0ef0eb5f03</a><br>
> a/gdal/data/gcs.override.csv#L29-L31<br>
><br>
><br>
> Andreas Schmid<br>
> GIS-Informatiker<br>
><br>
><br>
> Amt für Geoinformation<br>
> SO!GIS-Koordination<br>
> Rötistrasse 4<br>
> 4501 Solothurn<br>
><br>
> Telefon <a href="tel:%2B41%2032%20627%2075%2093" value="+41326277593">+41 32 627 75 93</a><br>
> Telefax <a href="tel:%2B41%2032%20627%2075%2098" value="+41326277598">+41 32 627 75 98</a><br>
> <a href="mailto:andreas.schmid@bd.so.ch">andreas.schmid@bd.so.ch</a><br>
> <a href="http://www.so.ch" target="_blank">http://www.so.ch</a><br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush | Geospatial Software Developer<br></div>
</div>