Re: [Gpsbabel-misc] Accuracy of BNG > GPX (WGS84) transformations
Brought to you by:
robertl
From: Greg T. <gd...@le...> - 2024-08-06 11:39:10
|
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. |