Re: [Gpsbabel-misc] Accuracy of BNG > GPX (WGS84) transformations

[tsteven4 <tst...@gm...>]

I have an implementation of the Helmert transform that is utilized for 
conversion between OSGB36 and WSG84.

Use Helmert transform for conversions between OSGB36 and WSG84 by 
tsteven4 · Pull Request #1311 · GPSBabel/gpsbabel (github.com) 
<https://github.com/GPSBabel/gpsbabel/pull/1311>

The results with this change for the points originally cited are shown 
below.  They are in close agreement with the cited conversion tools.

>   <wpt lat="50.827399509" lon="-2.050323375">
>     <time>2024-08-05T00:00:00Z</time>
>     <name>Badbury Rings Trig Point</name>
>     <cmt>Test Point 1</cmt>
>     <desc>Test Point 1</desc>
>   </wpt>
>   <wpt lat="50.816527458" lon="-2.122918364">
>     <time>2024-08-05T00:00:00Z</time>
>     <name>Spettisbury Rings Trig Point</name>
>     <cmt>Test Point 2</cmt>
>     <desc>Test Point 2</desc>
>   </wpt>
This PR requires correct WGS84 semi minor axis value. by tsteven4 · Pull 
Request #1310 · GPSBabel/gpsbabel (github.com) 
<https://github.com/GPSBabel/gpsbabel/pull/1310> which corrects a gross 
error in the semi-minor WGS84 axis that was only used when converting 
from ECEF to WGS84.  That PR has already been merged.

On 8/6/2024 5:38 AM, Greg Troxel wrote:
> Daniel Holloway via Gpsbabel-misc<gps...@li...>
> writes:
>
>> Thanks for all the comprehensive replies. I appreciate that my
>> interest is a minority and regional one but GPSBabel's ability to
>> construct a GPX file from a custom list drew me in. My use case is
>> actually the transfer of historic biological records (e.g. notable
>> plants and fungi) into a form that I can display on a mobile mapping
>> app in the field (my current favourite is Organic Maps on iOS). The
>> coordinates in the source records are in alphanumeric BNG format, and
>> GPSBabel's Universal CSV input caters for this nicely.
> You are really heading down a path which needs a GIS.   I would suggest
> that you use whatever to transform from alpha BNG to something
> numeric and a standard format -- perhaps still BNG, and then do
> projections and datum transforms with ogr2ogr.
>
>> Getting the coordinates transformed as accurately as possible is
>> important to me so it looks like I'll have to do this part outside of
>> GPSBabel and do some cut-and-pasting. I don't know enough about what's
>> going on under the hood to fully understand why an application or web
>> service might use a particular transformation but the aim of my test
>> file was to see what performed well. Of the three web services that I
>> quoted, the only one that provides any details is the one from the
>> British Geological Survey which states that it uses "Oracle Spatial
>> 10g coordinate transformations using approved (recommended) EPSG codes
>> for BNG, WGS84 and ETRS89, which are 27700, 4326 and 4258
>> respectively. Technical details can be provided on request." As they
>> all produce identical results, perhaps they're all using this.
> Datum transformations, especially with historic datums, is a very
> complicated subject.
>
>> Since I made my original post, I've also tried the web service provided by MapTiler's Open Source epsg.io project for
>> which I can provide sets of coordinates in the URL. For my test coordinates:
>>
>> http://epsg.io/trans?data=396552,103097;391437,101894&s_srs=27700&&t_srs=4326
>>
>> This returns:
>> [{"x":"-2.050316558785607","y":"50.82739061538607","z":"0.0"},
>> {"x":"-2.1229128935201205","y":"50.81651863166252","z":"0.0"}]
>>
>> These are slightly different from the results of the other web services but the differences only appear at the fifth
>> decimal place and are negligible in practice. This may be my best bet for processing groups of coordinates together.
> The 5th place of lat/lon is 1m.   You should understand where the source
> coordinates came from and what their accuracy is.  You should also
> realize that anything that involves "WGS84", because it is an ensemble
> with one low-accuracy member (WGS84 TRANSIT or original), is no better
> than 2m.
>
> In addition, if you are converting from a British grid to ETRS89, those
> are both plate-fixed datums, on the same plate, so you should be able to
> avoid not only the ensemble problems of WGS84, but the need to deal with
> dynamic datums like ITRF/WGS84 at all.
>
> 27700 is a projection and the base Crs is EPSG:4277 which is "Ordnance
> Survey of Great Britain 1936".
>
> Surely OSGB publishes transforms from OSGB36 to the modern datum in use.
>
>
> Also, do not assume that satellite imagery is accurate of a few meters.
> Besides registration accuracy, there is the question of dynamic datums
> (not fixed to the plate, where stations have not only coordinates but
> velocities).  With care and particularly high-quality imagery, in the US
> I can see a 1m offset between NAD83(2011) epoch 2010.0 (our national
> datum) and a modern member of the WGS84 family.  But most imagery I
> would not trust to 1m.
>
>
>
> _______________________________________________
> Gpsbabel-misc mailing listhttp://www.gpsbabel.org
> Gps...@li...
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc