[gdal-dev] Request for reintroduction of an override line into gcs.override.csv
Frank Warmerdam
warmerdam at pobox.com
Wed Jan 7 09:51:39 PST 2015
Schmid,
If you file a ticket against libgeotiff (http://trac.osgeo.org/geotiff/)
capturing the details of the above discussion, I'll review and consider
reapplying the override.
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.
Best regards,
Frank
On Wed, Jan 7, 2015 at 9:43 AM, Schmid Andreas <Andreas.Schmid at bd.so.ch>
wrote:
> 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150107/22fa4b89/attachment-0001.html>
More information about the gdal-dev
mailing list