How does Survex translate between GPS and UK grid?

[Tarquin Wilton-Jones]

Hi Olli,

Thanks for the pointer!

>> 1. Does Survex use Helmert transforms to get between them, or OSTN15?
>> (or OSTN02)
> 
> Survex uses PROJ for all the heavy lifting here, so that's the place to
> look for details.  I think how it converts probably depends on the pair
> of coordinate systems it is converting between.

I think it can be summarised by this:
https://gis.stackexchange.com/questions/364871/why-does-pyproj-give-a-different-point-location-compared-to-ordnance-survey-when

By default, Proj will use Helmert transformations. It can use OSTN15,
but it will not in the case of Survex, because you most likely do not
install the OS's OSTN15 package, since it is non-free (from an open
source perspective).

Technically, you could make it work. Legally the Survex project cannot.
Maybe this is something users can install for themselves, but obviously
this has limitations on systems where everything is pre-compiled (Windows).

Unless I missed something.

>> 2. Does Survex translate between WGS84 and ETRS89 (based on the survey
>> date) before converting to grid, or does it treat them as the same?
>>
>> I know right now, the difference for #1 is about 2.5 m on average, and
>> for #2 it is about 79 cm in 2020, both of which are more accurate than a
>> typical GPS, so I will not be surprised if you use basic Helmert and
>> equate WGS84 and ETRS89. In fact I fully expect you to.
> 
> We don't currently pass the survey date to PROJ (because our code
> was written for an older version of the PROJ API which didn't allow
> passing the date and nobody's update it yet), so coordinate systems
> that vary with time will presumably be effectively pinned at some
> arbitrary date.

The arbitrary date will be 1989 - the date that ETRS89 uses as its
origin. Sadly, this means that continental drift is ignored.

It might again be possible to give proj the generic drift data from
IETF2008 (that's what GPS uses) and ETRF2000 (the current recommended
ETRS89 frame) or ETRF2014 (its likely replacement) with their epochs set
to the survey date. However, OS use a weird combination of ETRF89 with
an epoch of 2009.756 (they act like all maps were created on that date),
which would require access to the EUREF plate velocity database to
perform the calculation. Therefore I cannot see it happening.

So basically, Survex will be forced to - unless something changes in the
Proj project - ignore continental drift, and also ignore the
inaccuracies of Helmert transformations.

If you supply a location using GPS coordinates, the cave location will
be wrong by continental drift. If you ask Survex to export OSGB36 grid
references, the coordinates will also be wrong by up to 3 metres due to
Helmert transformations not being a perfect replica of OSTN15. If you
supply a location as OSGB36 grid references and export KML, the position
will be wrong by up to 3 metres plus continental drift since 1989.

(This is not a criticism - most conversion tools use this approach, and
have the same limitations. I just wanted to write this limitation
somewhere for anyone else who is looking for the information.)

Cheers again for the pointer.

Tarquin