towgs84 values for EPSG:27700

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

towgs84 values for EPSG:27700

peifer
Hi,

I am working with PROJ Rel. 4.7.1 and GDAL/OGR from trunk.

testepsg and gdalsrsinfo tell me that the towgs84 values for EPSG:27700
are 375,-111,431,0,0,0,0 whereas cs2cs reports for the same EPSG code:
446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894

Is this expected behaviour?

Hermann


$ testepsg epsg:27700 | grep PROJ.4
PROJ.4 rendering of [epsg:27700] = +proj=tmerc +lat_0=49 +lon_0=-2
+k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy
+towgs84=375,-111,431,0,0,0,0 +units=m +no_defs


$ gdalsrsinfo epsg:27700 | grep PROJ.4
PROJ.4 : '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000
+y_0=-100000 +ellps=airy +towgs84=375,-111,431,0,0,0,0 +units=m +no_defs '


$ cs2cs -v +init=epsg:27700 +to +proj=latlong +datum=WGS84
# ---- From Coordinate System ----
#Transverse Mercator
#       Cyl, Sph&Ell
# +init=epsg:27700 +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717
+x_0=400000
# +y_0=-100000 +ellps=airy +datum=OSGB36 +units=m +no_defs
# +towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894
#--- following specified but NOT used
# +ellps=airy
# ---- To Coordinate System ----
#Lat/long (Geodetic alias)
#
# +proj=latlong +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
^C

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: towgs84 values for EPSG:27700

support.mn
Hello,

Spatial Reference Org

http://spatialreference.org/ref/epsg/27700/
http://spatialreference.org/ref/epsg/27700/proj4/

gives:

+proj=tmerc
+lat_0=49
+lon_0=-2
+k=0.9996012717
+x_0=400000
+y_0=-100000
+ellps=airy
+datum=OSGB36
+units=m
+no_defs

which is the OSGB 1936 / British National Grid. The
OSGB36 datum is defined differently in both
applications. There are several different definitions
for the OSGB36 and more are added as people need
definitions for different purpose.

So the reason for the difference is that the OSGB36
datum is not any standard value.

Regards: Janne.

------------------------------------------------------------------------

Hermann Peifer [[hidden email]] kirjoitti:

> Hi,
>
> I am working with PROJ Rel. 4.7.1 and GDAL/OGR from trunk.
>
> testepsg and gdalsrsinfo tell me that the towgs84 values for EPSG:27700
> are 375,-111,431,0,0,0,0 whereas cs2cs reports for the same EPSG code:
> 446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894
>
> Is this expected behaviour?
>
> Hermann
>
>
> $ testepsg epsg:27700 | grep PROJ.4
> PROJ.4 rendering of [epsg:27700] = +proj=tmerc +lat_0=49 +lon_0=-2
> +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy
> +towgs84=375,-111,431,0,0,0,0 +units=m +no_defs
>
>
> $ gdalsrsinfo epsg:27700 | grep PROJ.4
> PROJ.4 : '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000
> +y_0=-100000 +ellps=airy +towgs84=375,-111,431,0,0,0,0 +units=m +no_defs '
>
>
> $ cs2cs -v +init=epsg:27700 +to +proj=latlong +datum=WGS84
> # ---- From Coordinate System ----
> #Transverse Mercator
> #       Cyl, Sph&Ell
> # +init=epsg:27700 +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717
> +x_0=400000
> # +y_0=-100000 +ellps=airy +datum=OSGB36 +units=m +no_defs
> # +towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894
> #--- following specified but NOT used
> # +ellps=airy
> # ---- To Coordinate System ----
> #Lat/long (Geodetic alias)
> #
> # +proj=latlong +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> ^C
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
>

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: towgs84 values for EPSG:27700

hamish-2
Janne wrote:

> Hello,
>
> Spatial Reference Org
>
> http://spatialreference.org/ref/epsg/27700/
> http://spatialreference.org/ref/epsg/27700/proj4/
>
> gives:
>
> +proj=tmerc
> +lat_0=49
> +lon_0=-2
> +k=0.9996012717
> +x_0=400000
> +y_0=-100000
> +ellps=airy
> +datum=OSGB36
> +units=m
> +no_defs
>
> which is the OSGB 1936 / British National Grid. The
> OSGB36 datum is defined differently in both
> applications. There are several different definitions
> for the OSGB36 and more are added as people need
> definitions for different purpose.
>
> So the reason for the difference is that the OSGB36
> datum is not any standard value.


see http://trac.osgeo.org/proj/ticket/122

(7 term is by not "by definition better" than 3 term +towgs84;
for any given datum there may be a dozen or more transform terms
which are valid/used in differing particular regions; sometimes
you want to match what was used in an earlier dataset rather than
what is today considered ideal; the official EPSG.org db does not
define datum transform terms, those are added by end users (pj4);
if the proj4 epsg code defines +towgs84 terms then tacking a
+nadgrids file at the end creates a conflict which needs string
substitution to fix, but because +datum is now removed from
proj4's copy of epsg you can't automate that process from a
lookup table; qgis is patching around this on a per-datum basis,
grass gis's datum support is more heavily dependent on proj/gdal
and is just plain broken by this; ...)


thanks,
Hamish
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: towgs84 values for EPSG:27700

peifer
In reply to this post by support.mn
On 19/02/2012 21:06, [hidden email] wrote:
>
> So the reason for the difference is that the OSGB36
> datum is not any standard value.
>

I am aware that there always might be many values for a single EPSG
code. I also don't want to debate in how far the values of the "ETRS89
(WGS84) to OSGB36/ODN Helmert transformation", on p. 33 of [1], can be
considered as "standard values". My simple (slightly rephrased) question
was:

ogr2ogr -s_srs epsg:27700 # expands to something
cs2cs -v +init=epsg:27700 # expands to something else

Is this expected behaviour?

Hermann

[1]
http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf 

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: towgs84 values for EPSG:27700

Mikael Rittri

> Is this expected behaviour?

I can say that I, for one, didn't expect it. Because as far as I know,
the default datum shifts in both Proj.4 and GDAL/OGR come from the
gcs.csv file that is part of libgeotiff.

However, the gcs.csv file is changed now and then. The default datum
shift of OSGB 1936 was changed from the 7-parameter (epsg:1314) to the
3-parameter (epsg:1195) in the libgeotiff changeset 2023, of May 23, 2011.
The changeset message was just "upgrade to EPSG 7.6 database".

http://trac.osgeo.org/geotiff/changeset/2023/trunk/libgeotiff/csv/gcs.csv

(And I just happened to notice that in the same changeset, the default
 datum shift for Qornoq 1927 was changed from the 7-parameter epsg:1798,
 accuracy 1 m, to the 3-parameter epsg:1797, accuracy 48 m.)

I don't know in what libgeotiff release this changeset was (or will be)
included. But it seems that when you used GDAL/OGR from trunk, this changeset was included, whereas when you used Proj version 4.7.1,
it wasn't.

See also Frank's blog:
http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html

and

http://trac.osgeo.org/geotiff/ticket/33

Best regards,

Mikael Rittri
Carmenta
Sweden
http://www.carmenta.com

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Hermann Peifer
Sent: Monday, February 20, 2012 6:56 AM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] towgs84 values for EPSG:27700

On 19/02/2012 21:06, [hidden email] wrote:
>
> So the reason for the difference is that the OSGB36
> datum is not any standard value.
>

I am aware that there always might be many values for a single EPSG
code. I also don't want to debate in how far the values of the "ETRS89
(WGS84) to OSGB36/ODN Helmert transformation", on p. 33 of [1], can be
considered as "standard values". My simple (slightly rephrased) question
was:

ogr2ogr -s_srs epsg:27700 # expands to something
cs2cs -v +init=epsg:27700 # expands to something else

Is this expected behaviour?

Hermann

[1]
http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf 

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: towgs84 values for EPSG:27700

Martin Desruisseaux
Just for information purpose, EPSG make an interesting note about "early binding" and "late binding" coordinate transformation softwares. Quoting:

Some software resolves the so-called ‘multiplicity’ problem by associating one coordinate transformation only with each CRS. The relevant coordinate transformation is even treated as part of the definition of the CRS. This solution to the problem of multiplicity is referred to as ‘early binding’, as it binds a coordinate transformation to the CRS before it is associated with any geospatial data.

‘Late-binding’ software solutions to the multiplicity problem will only require the specification of a coordinate transformation at the time the coordinates are required to be transformed, i.e. after the association of geospatial data and CRS has taken place.

The solution that has been chosen for any given geoscience software package is fundamental to its behaviour with respect to geospatial integrity. Both solutions have advantages and disadvantages and both are valid ways of controlling geospatial integrity. In this guidance note preference is expressed for the late-binding solution, provided the specific disadvantage of this solution, is resolved in the software.


Source: http://www.epsg.org/gigs.html (Geospatial Integrity of Geoscience Software)
Document: ‘Part 1 – Guidelines’ (OGP report number 430-1), describing the GIGS process
Section 3.4 at page 11.


Since the EPSG database does not associate TOWGS84 values to any particular CRS (instead, it associates TOWGS84 values to different pair of "sourceCRS to targetCRS" transformations), the EPSG database is a "late binding" model. However some (not all) coordinate transformation libraries convert the EPSG model into some form of "early binding" model. I would said that the "TOWGS84 multiplicity" issue come from this conversion...

    Martin


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: towgs84 values for EPSG:27700

peifer
In reply to this post by Mikael Rittri
On 20/02/2012 10:45, Mikael Rittri wrote:

>
>> Is this expected behaviour?
>
> I can say that I, for one, didn't expect it. Because as far as I know,
> the default datum shifts in both Proj.4 and GDAL/OGR come from the
> gcs.csv file that is part of libgeotiff.
>
> However, the gcs.csv file is changed now and then. The default datum
> shift of OSGB 1936 was changed from the 7-parameter (epsg:1314) to the
> 3-parameter (epsg:1195) in the libgeotiff changeset 2023, of May 23, 2011.
> The changeset message was just "upgrade to EPSG 7.6 database".
>
> http://trac.osgeo.org/geotiff/changeset/2023/trunk/libgeotiff/csv/gcs.csv
>

Thanks for the hint, I should have known. I keep forgetting that there
is a variety of gcs.csv and pcs.csv files around: as part of libgeotiff,
GDAL/OGR and GRASS, plus the epsg file which comes with PROJ. I have to
pay more attention to keeping them in sync.

Hermann

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj