Thread: [Gpsbabel-misc] Accuracy of BNG > GPX (WGS84) transformations
Brought to you by:
robertl
From: <deh...@gm...> - 2024-08-05 17:37:54
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi Robert,</div> <div> </div> <div>I've been converting Universal CSV lists of BNG coordinates to GPX XML files with GPSBabel and am wondering about the accuracy of the conversion. Here's my test input which lists a couple of trig points (triangulation stations) in the county of Dorset:</div> <div> </div> <div>name,comment,bng,date<br/> Badbury Rings Trig Point,Test Point 1,ST 96552 03097,2024/08/05<br/> Spettisbury Rings Trig Point,Test Point 2,ST 91437 01894,2024/08/05</div> <div> </div> <div>The trig points are marked on British Ordnance Survey maps and also visible in satellite images, allowing me to check accuracy in various mapping apps. </div> <div>Using the GPSBabel GUI (v.1.9.0) under Windows 10, the file is processed successfully with the following feedback:</div> <div> </div> <div>gpsbabel -w -i unicsv -f G:/Trig Points.csv -o gpx -F G:/Trig Points.gpx<br/> Translation successful</div> <div> </div> <div>This is the output:</div> <div><?xml version="1.0" encoding="UTF-8"?><br/> <gpx version="1.0" creator="GPSBabel - https://www.gpsbabel.org" xmlns="http://www.topografix.com/GPX/1/0"><br/> <time>2024-08-05T16:54:46.903Z</time><br/> <bounds minlat="50.816463984" minlon="-2.122941465" maxlat="50.827336109" maxlon="-2.050345019"/><br/> <wpt lat="50.827336109" lon="-2.050345019"><br/> <time>2024-08-04T23:00:00Z</time><br/> <name>Badbury Rings Trig Point</name><br/> <cmt>Test Point 1</cmt><br/> <desc>Test Point 1</desc><br/> </wpt><br/> <wpt lat="50.816463984" lon="-2.122941465"><br/> <time>2024-08-04T23:00:00Z</time><br/> <name>Spettisbury Rings Trig Point</name><br/> <cmt>Test Point 2</cmt><br/> <desc>Test Point 2</desc><br/> </wpt><br/> </gpx></div> <div> </div> <div>All well and good but when I check the generated coordinates in mapping apps, they are a few metres off target. Furthermore, they differ from coordinates generated by various online BNG > WGS84 conversion tools which are themselves consistent. For example:</div> <div> </div> <div>British Geological Society<br/> https://webapps.bgs.ac.uk/data/webservices/convertForm.cfm<br/> Badbury Rings Trig Point = 50.827400 , -2.050323<br/> Spettisbury Rings Trig Point = 50.816527 , -2.122918</div> <div> </div> <div>Grid Reference Finder<br/> https://gridreferencefinder.com<br/> Badbury Rings Trig Point = 50.827400 , -2.0503234<br/> Spettisbury Rings Trig Point = 50.816527 , -2.1229184</div> <div> </div> <div>Mapserve<br/> https://www.mapserve.co.uk/conversion-tools<br/> Badbury Rings Trig Point = 50.8273995082622 , -2.05032333478781<br/> Spettisbury Rings Trig Point = 50.8165274566942 , -2.1229183177272</div> <div> </div> <div>The difference isn't huge but it seems to be more than a rounding error. So, I'm wondering what might need to be done to harmonise the GPSBabel conversion with these others.</div> <div> </div> <div>Many thanks,<br/> Nims</div></div></body></html> |
From: tsteven4 <tst...@gm...> - 2024-08-05 20:43:58
|
I suspect but have not proven this is because we use a abridged molodensky transformation using the 3 parameters dX, dY dZ values shown below. The citation claims this is only accurate to +/- 20m. We don't use PROJ.4, and we don't have more complex transformations available. See Transformations in GDAL/OGR (edina.ac.uk) <https://digimap.edina.ac.uk/help/gis/transformations/transform_gdal_ogr/> which says > PROJ.4 contains a large number of transformations and parameters. > However by default OGR uses a 3 parameter shift because it covers the > largest available area -see blogpost on how transformations are chosen > in Proj4. > <http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html>However, > this is only accurate to +/- 20 metres over the whole of the UK. It is > equivalent to the ArcGIS transformation called OSGB_1936_To_GS_1984_1 > and has parameters of dX: 375, dY-111, dZ 431 On 8/5/2024 11:37 AM, Nims via Gpsbabel-misc wrote: > Hi Robert, > I've been converting Universal CSV lists of BNG coordinates to GPX XML > files with GPSBabel and am wondering about the accuracy of the > conversion. Here's my test input which lists a couple of trig points > (triangulation stations) in the county of Dorset: > name,comment,bng,date > Badbury Rings Trig Point,Test Point 1,ST 96552 03097,2024/08/05 > Spettisbury Rings Trig Point,Test Point 2,ST 91437 01894,2024/08/05 > The trig points are marked on British Ordnance Survey maps and also > visible in satellite images, allowing me to check accuracy in various > mapping apps. > Using the GPSBabel GUI (v.1.9.0) under Windows 10, the file is > processed successfully with the following feedback: > gpsbabel -w -i unicsv -f G:/Trig Points.csv -o gpx -F G:/Trig Points.gpx > Translation successful > This is the output: > <?xml version="1.0" encoding="UTF-8"?> > <gpx version="1.0" creator="GPSBabel - https://www.gpsbabel.org" > xmlns="http://www.topografix.com/GPX/1/0"> > <time>2024-08-05T16:54:46.903Z</time> > <bounds minlat="50.816463984" minlon="-2.122941465" > maxlat="50.827336109" maxlon="-2.050345019"/> > <wpt lat="50.827336109" lon="-2.050345019"> > <time>2024-08-04T23:00:00Z</time> > <name>Badbury Rings Trig Point</name> > <cmt>Test Point 1</cmt> > <desc>Test Point 1</desc> > </wpt> > <wpt lat="50.816463984" lon="-2.122941465"> > <time>2024-08-04T23:00:00Z</time> > <name>Spettisbury Rings Trig Point</name> > <cmt>Test Point 2</cmt> > <desc>Test Point 2</desc> > </wpt> > </gpx> > All well and good but when I check the generated coordinates in > mapping apps, they are a few metres off target. Furthermore, they > differ from coordinates generated by various online BNG > WGS84 > conversion tools which are themselves consistent. For example: > British Geological Society > https://webapps.bgs.ac.uk/data/webservices/convertForm.cfm > Badbury Rings Trig Point = 50.827400 , -2.050323 > Spettisbury Rings Trig Point = 50.816527 , -2.122918 > Grid Reference Finder > https://gridreferencefinder.com > Badbury Rings Trig Point = 50.827400 , -2.0503234 > Spettisbury Rings Trig Point = 50.816527 , -2.1229184 > Mapserve > https://www.mapserve.co.uk/conversion-tools > Badbury Rings Trig Point = 50.8273995082622 , -2.05032333478781 > Spettisbury Rings Trig Point = 50.8165274566942 , -2.1229183177272 > The difference isn't huge but it seems to be more than a rounding > error. So, I'm wondering what might need to be done to harmonise the > GPSBabel conversion with these others. > Many thanks, > Nims > > > _______________________________________________ > 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 |
From: tsteven4 <tst...@gm...> - 2024-08-05 20:44:09
|
I suspect but have not proven this is because we use a abridged molodensky transformation using the 3 parameters dX, dY dZ values shown below. The citation claims this is only accurate to +/- 20m. We don't use PROJ.4, and we don't have more complex transformations available. See Transformations in GDAL/OGR (edina.ac.uk) <https://digimap.edina.ac.uk/help/gis/transformations/transform_gdal_ogr/> which says > PROJ.4 contains a large number of transformations and parameters. > However by default OGR uses a 3 parameter shift because it covers the > largest available area -see blogpost on how transformations are chosen > in Proj4. > <http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html>However, > this is only accurate to +/- 20 metres over the whole of the UK. It is > equivalent to the ArcGIS transformation called OSGB_1936_To_GS_1984_1 > and has parameters of dX: 375, dY-111, dZ 431 On 8/5/2024 11:37 AM, Nims via Gpsbabel-misc wrote: > Hi Robert, > I've been converting Universal CSV lists of BNG coordinates to GPX XML > files with GPSBabel and am wondering about the accuracy of the > conversion. Here's my test input which lists a couple of trig points > (triangulation stations) in the county of Dorset: > name,comment,bng,date > Badbury Rings Trig Point,Test Point 1,ST 96552 03097,2024/08/05 > Spettisbury Rings Trig Point,Test Point 2,ST 91437 01894,2024/08/05 > The trig points are marked on British Ordnance Survey maps and also > visible in satellite images, allowing me to check accuracy in various > mapping apps. > Using the GPSBabel GUI (v.1.9.0) under Windows 10, the file is > processed successfully with the following feedback: > gpsbabel -w -i unicsv -f G:/Trig Points.csv -o gpx -F G:/Trig Points.gpx > Translation successful > This is the output: > <?xml version="1.0" encoding="UTF-8"?> > <gpx version="1.0" creator="GPSBabel - https://www.gpsbabel.org" > xmlns="http://www.topografix.com/GPX/1/0"> > <time>2024-08-05T16:54:46.903Z</time> > <bounds minlat="50.816463984" minlon="-2.122941465" > maxlat="50.827336109" maxlon="-2.050345019"/> > <wpt lat="50.827336109" lon="-2.050345019"> > <time>2024-08-04T23:00:00Z</time> > <name>Badbury Rings Trig Point</name> > <cmt>Test Point 1</cmt> > <desc>Test Point 1</desc> > </wpt> > <wpt lat="50.816463984" lon="-2.122941465"> > <time>2024-08-04T23:00:00Z</time> > <name>Spettisbury Rings Trig Point</name> > <cmt>Test Point 2</cmt> > <desc>Test Point 2</desc> > </wpt> > </gpx> > All well and good but when I check the generated coordinates in > mapping apps, they are a few metres off target. Furthermore, they > differ from coordinates generated by various online BNG > WGS84 > conversion tools which are themselves consistent. For example: > British Geological Society > https://webapps.bgs.ac.uk/data/webservices/convertForm.cfm > Badbury Rings Trig Point = 50.827400 , -2.050323 > Spettisbury Rings Trig Point = 50.816527 , -2.122918 > Grid Reference Finder > https://gridreferencefinder.com > Badbury Rings Trig Point = 50.827400 , -2.0503234 > Spettisbury Rings Trig Point = 50.816527 , -2.1229184 > Mapserve > https://www.mapserve.co.uk/conversion-tools > Badbury Rings Trig Point = 50.8273995082622 , -2.05032333478781 > Spettisbury Rings Trig Point = 50.8165274566942 , -2.1229183177272 > The difference isn't huge but it seems to be more than a rounding > error. So, I'm wondering what might need to be done to harmonise the > GPSBabel conversion with these others. > Many thanks, > Nims > > > _______________________________________________ > 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 |
From: tsteven4 <tst...@gm...> - 2024-08-05 22:01:47
|
We actually use the standard molodensky (5 parameter) transformation, but not the 7 parameter Molodensky-Badekas or the OSTN02 transformation mentioned in the reference below. It isn't clear to me what transformation the online tools you referenced used. On 8/5/2024 2:43 PM, tsteven4 wrote: > > I suspect but have not proven this is because we use a abridged > molodensky transformation using the 3 parameters dX, dY dZ values > shown below. The citation claims this is only accurate to +/- 20m. > We don't use PROJ.4, and we don't have more complex transformations > available. > > See Transformations in GDAL/OGR (edina.ac.uk) > <https://digimap.edina.ac.uk/help/gis/transformations/transform_gdal_ogr/> > which says > >> PROJ.4 contains a large number of transformations and parameters. >> However by default OGR uses a 3 parameter shift because it covers the >> largest available area -see blogpost on how transformations are >> chosen in Proj4. >> <http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html>However, >> this is only accurate to +/- 20 metres over the whole of the UK. It >> is equivalent to the ArcGIS transformation called >> OSGB_1936_To_GS_1984_1 and has parameters of dX: 375, dY-111, dZ 431 > > On 8/5/2024 11:37 AM, Nims via Gpsbabel-misc wrote: >> Hi Robert, >> I've been converting Universal CSV lists of BNG coordinates to GPX >> XML files with GPSBabel and am wondering about the accuracy of the >> conversion. Here's my test input which lists a couple of trig points >> (triangulation stations) in the county of Dorset: >> name,comment,bng,date >> Badbury Rings Trig Point,Test Point 1,ST 96552 03097,2024/08/05 >> Spettisbury Rings Trig Point,Test Point 2,ST 91437 01894,2024/08/05 >> The trig points are marked on British Ordnance Survey maps and also >> visible in satellite images, allowing me to check accuracy in various >> mapping apps. >> Using the GPSBabel GUI (v.1.9.0) under Windows 10, the file is >> processed successfully with the following feedback: >> gpsbabel -w -i unicsv -f G:/Trig Points.csv -o gpx -F G:/Trig Points.gpx >> Translation successful >> This is the output: >> <?xml version="1.0" encoding="UTF-8"?> >> <gpx version="1.0" creator="GPSBabel - https://www.gpsbabel.org" >> xmlns="http://www.topografix.com/GPX/1/0"> >> <time>2024-08-05T16:54:46.903Z</time> >> <bounds minlat="50.816463984" minlon="-2.122941465" >> maxlat="50.827336109" maxlon="-2.050345019"/> >> <wpt lat="50.827336109" lon="-2.050345019"> >> <time>2024-08-04T23:00:00Z</time> >> <name>Badbury Rings Trig Point</name> >> <cmt>Test Point 1</cmt> >> <desc>Test Point 1</desc> >> </wpt> >> <wpt lat="50.816463984" lon="-2.122941465"> >> <time>2024-08-04T23:00:00Z</time> >> <name>Spettisbury Rings Trig Point</name> >> <cmt>Test Point 2</cmt> >> <desc>Test Point 2</desc> >> </wpt> >> </gpx> >> All well and good but when I check the generated coordinates in >> mapping apps, they are a few metres off target. Furthermore, they >> differ from coordinates generated by various online BNG > WGS84 >> conversion tools which are themselves consistent. For example: >> British Geological Society >> https://webapps.bgs.ac.uk/data/webservices/convertForm.cfm >> Badbury Rings Trig Point = 50.827400 , -2.050323 >> Spettisbury Rings Trig Point = 50.816527 , -2.122918 >> Grid Reference Finder >> https://gridreferencefinder.com >> Badbury Rings Trig Point = 50.827400 , -2.0503234 >> Spettisbury Rings Trig Point = 50.816527 , -2.1229184 >> Mapserve >> https://www.mapserve.co.uk/conversion-tools >> Badbury Rings Trig Point = 50.8273995082622 , -2.05032333478781 >> Spettisbury Rings Trig Point = 50.8165274566942 , -2.1229183177272 >> The difference isn't huge but it seems to be more than a rounding >> error. So, I'm wondering what might need to be done to harmonise the >> GPSBabel conversion with these others. >> Many thanks, >> Nims >> >> >> _______________________________________________ >> 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 |
From: Robert L. <rob...@gp...> - 2024-08-05 22:20:20
|
I'm not UNhappy leaving such transformations to other tools like ArcGIS or ogr2ogr and keeping us focused on file format conversions. It's a bit of a parlor trick that we do this at all. It's a digital, global world, and fixing country specific datum protections isn't really our focus. I'm happy leaving that to GDAL just like they happy to leave the details of a zillion GPSes and file formats to us. If someone brings a PR to our doorstep to improve things (that doesn't involve including a copy of GDAL), great, but it's not strategic for us. On Mon, Aug 5, 2024, 5:02 PM tsteven4 <tst...@gm...> wrote: > We actually use the standard molodensky (5 parameter) transformation, but > not the 7 parameter Molodensky-Badekas or the OSTN02 transformation > mentioned in the reference below. It isn't clear to me what transformation > the online tools you referenced used. > On 8/5/2024 2:43 PM, tsteven4 wrote: > > I suspect but have not proven this is because we use a abridged molodensky > transformation using the 3 parameters dX, dY dZ values shown below. The > citation claims this is only accurate to +/- 20m. We don't use PROJ.4, and > we don't have more complex transformations available. > > See Transformations in GDAL/OGR (edina.ac.uk) > <https://digimap.edina.ac.uk/help/gis/transformations/transform_gdal_ogr/> > which says > > PROJ.4 contains a large number of transformations and parameters. However > by default OGR uses a 3 parameter shift because it covers the largest > available area - see blogpost on how transformations are chosen in Proj4. > <http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html> > However, this is only accurate to +/- 20 metres over the whole of the > UK. It is equivalent to the ArcGIS transformation called > OSGB_1936_To_GS_1984_1 and has parameters of dX: 375, dY-111, dZ 431 > > > On 8/5/2024 11:37 AM, Nims via Gpsbabel-misc wrote: > > Hi Robert, > > I've been converting Universal CSV lists of BNG coordinates to GPX XML > files with GPSBabel and am wondering about the accuracy of the conversion. > Here's my test input which lists a couple of trig points (triangulation > stations) in the county of Dorset: > > name,comment,bng,date > Badbury Rings Trig Point,Test Point 1,ST 96552 03097,2024/08/05 > Spettisbury Rings Trig Point,Test Point 2,ST 91437 01894,2024/08/05 > > The trig points are marked on British Ordnance Survey maps and also > visible in satellite images, allowing me to check accuracy in various > mapping apps. > Using the GPSBabel GUI (v.1.9.0) under Windows 10, the file is processed > successfully with the following feedback: > > gpsbabel -w -i unicsv -f G:/Trig Points.csv -o gpx -F G:/Trig Points.gpx > Translation successful > > This is the output: > <?xml version="1.0" encoding="UTF-8"?> > <gpx version="1.0" creator="GPSBabel - https://www.gpsbabel.org" xmlns= > "http://www.topografix.com/GPX/1/0" <http://www.topografix.com/GPX/1/0>> > <time>2024-08-05T16:54:46.903Z</time> > <bounds minlat="50.816463984" minlon="-2.122941465" > maxlat="50.827336109" maxlon="-2.050345019"/> > <wpt lat="50.827336109" lon="-2.050345019"> > <time>2024-08-04T23:00:00Z</time> > <name>Badbury Rings Trig Point</name> > <cmt>Test Point 1</cmt> > <desc>Test Point 1</desc> > </wpt> > <wpt lat="50.816463984" lon="-2.122941465"> > <time>2024-08-04T23:00:00Z</time> > <name>Spettisbury Rings Trig Point</name> > <cmt>Test Point 2</cmt> > <desc>Test Point 2</desc> > </wpt> > </gpx> > > All well and good but when I check the generated coordinates in mapping > apps, they are a few metres off target. Furthermore, they differ from > coordinates generated by various online BNG > WGS84 conversion tools which > are themselves consistent. For example: > > British Geological Society > https://webapps.bgs.ac.uk/data/webservices/convertForm.cfm > Badbury Rings Trig Point = 50.827400 , -2.050323 > Spettisbury Rings Trig Point = 50.816527 , -2.122918 > > Grid Reference Finder > https://gridreferencefinder.com > Badbury Rings Trig Point = 50.827400 , -2.0503234 > Spettisbury Rings Trig Point = 50.816527 , -2.1229184 > > Mapserve > https://www.mapserve.co.uk/conversion-tools > Badbury Rings Trig Point = 50.8273995082622 , -2.05032333478781 > Spettisbury Rings Trig Point = 50.8165274566942 , -2.1229183177272 > > The difference isn't huge but it seems to be more than a rounding error. > So, I'm wondering what might need to be done to harmonise the GPSBabel > conversion with these others. > > Many thanks, > Nims > > > _______________________________________________ > Gpsbabel-misc mailing list http://www...@li... > To unsubscribe, change list options, or see archives, visit:https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc > > _______________________________________________ > Gpsbabel-misc mailing list http://www.gpsbabel.org > Gps...@li... > To unsubscribe, change list options, or see archives, visit: > https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc > |
From: Greg T. <gd...@le...> - 2024-08-05 22:57:42
|
Robert Lipe <rob...@gp...> writes: > I'm not UNhappy leaving such transformations to other tools like ArcGIS or > ogr2ogr and keeping us focused on file format conversions. > > It's a bit of a parlor trick that we do this at all. It's a digital, > global world, and fixing country specific datum protections isn't really > our focus. I'm happy leaving that to GDAL just like they happy to leave the > details of a zillion GPSes and file formats to us. > > If someone brings a PR to our doorstep to improve things (that doesn't > involve including a copy of GDAL), great, but it's not strategic for us. I think this is the right call. I'd even lean to removing datum transforms. Part of the difficulty is that labeling of which point is in which datum is very tricky business. More recent proj has better datum transformations. In the US, that includes gridded model files that match NGS's transforms. There are mechanisms for choosing specific transforms. So punting all this to proj/gdal seems best. |
From: Daniel H. <deh...@gm...> - 2024-08-06 10:30:47
|
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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:</div><div dir="ltr"><br></div><div dir="ltr">http://epsg.io/trans?data=396552,103097;391437,101894&s_srs=27700&&t_srs=4326</div><div dir="ltr"><br></div><div dir="ltr">This returns:</div><div dir="ltr">[{"x":"-2.050316558785607","y":"50.82739061538607","z":"0.0"},{"x":"-2.1229128935201205","y":"50.81651863166252","z":"0.0"}]</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div><br></div></div><div dir="ltr"><br>On 5 Aug 2024, at 23:20, Robert Lipe <rob...@gp...> wrote:<br><br></div><div dir="ltr"><p dir="ltr">I'm not UNhappy leaving such transformations to other tools like ArcGIS or ogr2ogr and keeping us focused on file format conversions. </p> <p dir="ltr">It's a bit of a parlor trick that we do this at all. It's a digital, global world, and fixing country specific datum protections isn't really our focus. I'm happy leaving that to GDAL just like they happy to leave the details of a zillion GPSes and file formats to us. </p> <p dir="ltr">If someone brings a PR to our doorstep to improve things (that doesn't involve including a copy of GDAL), great, but it's not strategic for us. </p> <br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 5, 2024, 5:02 PM tsteven4 <<a href="mailto:tst...@gm...">tst...@gm...</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u> <div> <p>We actually use the standard molodensky (5 parameter) transformation, but not the 7 parameter Molodensky-Badekas or the OSTN02 transformation mentioned in the reference below. It isn't clear to me what transformation the online tools you referenced used.<br> </p> <div>On 8/5/2024 2:43 PM, tsteven4 wrote:<br> </div> <blockquote type="cite"> <p>I suspect but have not proven this is because we use a abridged molodensky transformation using the 3 parameters dX, dY dZ values shown below. The citation claims this is only accurate to +/- 20m. We don't use PROJ.4, and we don't have more complex transformations available.<br> </p> <p>See <a href="https://digimap.edina.ac.uk/help/gis/transformations/transform_gdal_ogr/" target="_blank" rel="noreferrer">Transformations in GDAL/OGR (edina.ac.uk)</a> which says</p> <p> </p> <blockquote type="cite"><span style="color:rgb(58,60,57);font-family:Lato,sans-serif;font-size:20px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;white-space:normal;background-color:rgb(246,245,244);text-decoration-style:initial;text-decoration-color:initial;display:inline!important;float:none">PROJ.4 contains a large number of transformations and parameters. However by default OGR uses a 3 parameter shift because it covers the largest available area -<span> </span></span><a href="http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html" style="box-sizing:border-box;padding:0px;color:rgb(44,62,98);text-decoration:underline rgb(44,62,98);font-family:Lato,sans-serif;font-size:20px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;white-space:normal;background-color:rgb(246,245,244)" target="_blank" rel="noreferrer">see blogpost on how transformations are chosen in Proj4.</a><span style="color:rgb(58,60,57);font-family:Lato,sans-serif;font-size:20px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;white-space:normal;background-color:rgb(246,245,244);text-decoration-style:initial;text-decoration-color:initial;display:inline!important;float:none"><span> </span>However, this is only accurate to +/- 20 metres over the whole of the UK. It is equivalent to the ArcGIS transformation called OSGB_1936_To_GS_1984_1 and has parameters of dX: 375, dY-111, dZ 431</span></blockquote> <br> <div>On 8/5/2024 11:37 AM, Nims via Gpsbabel-misc wrote:<br> </div> <blockquote type="cite"> <div style="font-family:Verdana;font-size:12.0px"> <div>Hi Robert,</div> <div> </div> <div>I've been converting Universal CSV lists of BNG coordinates to GPX XML files with GPSBabel and am wondering about the accuracy of the conversion. Here's my test input which lists a couple of trig points (triangulation stations) in the county of Dorset:</div> <div> </div> <div>name,comment,bng,date<br> Badbury Rings Trig Point,Test Point 1,ST 96552 03097,2024/08/05<br> Spettisbury Rings Trig Point,Test Point 2,ST 91437 01894,2024/08/05</div> <div> </div> <div>The trig points are marked on British Ordnance Survey maps and also visible in satellite images, allowing me to check accuracy in various mapping apps. </div> <div>Using the GPSBabel GUI (v.1.9.0) under Windows 10, the file is processed successfully with the following feedback:</div> <div> </div> <div>gpsbabel -w -i unicsv -f G:/Trig Points.csv -o gpx -F G:/Trig Points.gpx<br> Translation successful</div> <div> </div> <div>This is the output:</div> <div><?xml version="1.0" encoding="UTF-8"?><br> <gpx version="1.0" creator="GPSBabel - <a href="https://www.gpsbabel.org" target="_blank" rel="noreferrer">https://www.gpsbabel.org</a>" xmlns=<a href="http://www.topografix.com/GPX/1/0" target="_blank" rel="noreferrer">"http://www.topografix.com/GPX/1/0"</a>><br> <time>2024-08-05T16:54:46.903Z</time><br> <bounds minlat="50.816463984" minlon="-2.122941465" maxlat="50.827336109" maxlon="-2.050345019"/><br> <wpt lat="50.827336109" lon="-2.050345019"><br> <time>2024-08-04T23:00:00Z</time><br> <name>Badbury Rings Trig Point</name><br> <cmt>Test Point 1</cmt><br> <desc>Test Point 1</desc><br> </wpt><br> <wpt lat="50.816463984" lon="-2.122941465"><br> <time>2024-08-04T23:00:00Z</time><br> <name>Spettisbury Rings Trig Point</name><br> <cmt>Test Point 2</cmt><br> <desc>Test Point 2</desc><br> </wpt><br> </gpx></div> <div> </div> <div>All well and good but when I check the generated coordinates in mapping apps, they are a few metres off target. Furthermore, they differ from coordinates generated by various online BNG > WGS84 conversion tools which are themselves consistent. For example:</div> <div> </div> <div>British Geological Society<br> <a href="https://webapps.bgs.ac.uk/data/webservices/convertForm.cfm" target="_blank" rel="noreferrer">https://webapps.bgs.ac.uk/data/webservices/convertForm.cfm</a><br> Badbury Rings Trig Point = 50.827400 , -2.050323<br> Spettisbury Rings Trig Point = 50.816527 , -2.122918</div> <div> </div> <div>Grid Reference Finder<br> <a href="https://gridreferencefinder.com" target="_blank" rel="noreferrer">https://gridreferencefinder.com</a><br> Badbury Rings Trig Point = 50.827400 , -2.0503234<br> Spettisbury Rings Trig Point = 50.816527 , -2.1229184</div> <div> </div> <div>Mapserve<br> <a href="https://www.mapserve.co.uk/conversion-tools" target="_blank" rel="noreferrer">https://www.mapserve.co.uk/conversion-tools</a><br> Badbury Rings Trig Point = 50.8273995082622 , -2.05032333478781<br> Spettisbury Rings Trig Point = 50.8165274566942 , -2.1229183177272</div> <div> </div> <div>The difference isn't huge but it seems to be more than a rounding error. So, I'm wondering what might need to be done to harmonise the GPSBabel conversion with these others.</div> <div> </div> <div>Many thanks,<br> Nims</div> </div> <br> <fieldset></fieldset> <br> <fieldset></fieldset> <pre>_______________________________________________ Gpsbabel-misc mailing list <a href="http://www.gpsbabel.org" target="_blank" rel="noreferrer">http://www.gpsbabel.org</a> <a href="mailto:Gps...@li..." target="_blank" rel="noreferrer">Gps...@li...</a> To unsubscribe, change list options, or see archives, visit: <a href="https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc" target="_blank" rel="noreferrer">https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc</a> </pre> </blockquote> </blockquote> </div> _______________________________________________<br> Gpsbabel-misc mailing list <a href="http://www.gpsbabel.org" rel="noreferrer noreferrer" target="_blank">http://www.gpsbabel.org</a><br> <a href="mailto:Gps...@li..." target="_blank" rel="noreferrer">Gps...@li...</a><br> To unsubscribe, change list options, or see archives, visit:<br> <a href="https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc" rel="noreferrer noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc</a><br> </blockquote></div> </div></body></html> |
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. |
From: tsteven4 <tst...@gm...> - 2024-08-07 01:23:18
|
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 |
From: tsteven4 <tst...@gm...> - 2024-08-06 16:02:32
|
As described in guide-coordinate-systems-great-britain.pdf (ordnancesurvey.co.uk) <https://www.ordnancesurvey.co.uk/documents/resources/guide-coordinate-systems-great-britain.pdf> , using the helmert transformation (6.2) and parameters (6.6) results much closer matches to the web sites you used. I use the approximation they mentioned of changing the signs of the parameters for reversing "small" transformations. However, note the reference says > The error is up to 3.5 metres (95%) both horizontally and vertically If you really want the best conversion you need to use OSTN15(6.3). I don't see gpsbabel implementing OSTN15, but I can imagine gpsbabel implementing the helmert transformation. > <?xml version="1.0" encoding="UTF-8"?> > <gpx version="1.0" creator="GPSBabel - https://www.gpsbabel.org" > xmlns="http://www.topografix.com/GPX/1/0"> > <time>2024-08-06T15:49:13.516Z</time> > <bounds minlat="50.816527458" minlon="-2.122918364" > maxlat="50.827399509" maxlon="-2.050323375"/> > <wpt lat="50.827399509" lon="-2.050323375"> > <time>2024-08-05T06: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-05T06:00:00Z</time> > <name>Spettisbury Rings Trig Point</name> > <cmt>Test Point 2</cmt> > <desc>Test Point 2</desc> > </wpt> > </gpx> On 8/5/2024 11:37 AM, Nims via Gpsbabel-misc wrote: > Spettisbury Rings Trig Point,Test Point 2,ST 91437 01894,2024/08/05 |