Conversion from wgs84 to os gb36 is incorrect

[johnhalifax]

I have tried to convert from wgs84 to osgb36 and the result is wrong. I suspect that Agisoft is not using the correct os transformation. Ostn15 and osgm15. How can I correct this.

[johnhalifax]

I have converted from wgs84 to osgb36 but the result is about 2m off in position and 250mm in level. I suspect that agisoft is using an out of date os transformation. How can I check this and how can I change it to the correct transformation which would be OStn15 and OSgm15?

[Dave Martin]

John,

I wonder if it is a PhotoScan transformation issue or a model issue?

I'm not in front of my PhotoScan machine any time soon, so can't check there, but I wouldn't have thought there was that much shift if it was just because OS TN/GM 02 was still being used instead of the OS TN/GM 15 transformations.  There will, I'm sure, being something on the OSGB web site that covered this at the time. I do recall seeing 'heat maps' that characterised the magnitude of the shift; my recollection was that the typical lateral shift accruing from the OSTN02 to OSTN15 shift across mainland Britain was <5 cm. Changes to OSGM15 reflected a better characterised geoid (plus here on IOM, where we have our own datum DOUGLAS(02/15) instead of Newlyn) - I thought the vertical changes as a result of the new GM were mostly single-figure centimetres in England, but out towards the North and West of Scotland as a result of the better geoid (and, I guess, some isostatic rebound) there was up to a foot of difference in Z.

Can you use, say, the OSGB 'Grid Inquest' tool to try converting one of your WGS84 to OSGB and see if it matches? GridInquest, if a current version, defaults to the '15 transformation, but I seem to recall you can force it to use '02 via the settings.

If you're seeing points out by metres, I suspect it may be down to how the model is constructed/referenced rather than a transformation issue.

Dave

[Dave Martin]

John, I've found a couple of links that may help:

I can't find it on the OSGB web site but this article tabulates the horizontal shift changes as a result of the use of OSTN15 compared to OSTN02 as between -15 and +18mm Northing (RMS 7mm) and -37 to +19 mm Easting (RMS 9mm). It also has a heat map showing changes accruing to the use of OSGM15 compared to OSGM02.

What I have found on the OSGB site is this tool which converts OSTN02/OSGM02 derived coordinates to OSGM15/OSTN15.

Would suggest trying to convert some of your points to see how much shift there is in your locality.

Dave

[johnhalifax]

Hi Dave
You are correct about the shift between OSTh02 and OStn15 it is minimal but the shift between OStn97 and OStn15 can be up to 5m in places. Are you sure agisoft is using OStn 02?
I have tried using grid inquest to convert the tags from wgs84 to osgb36 using the ostn15 transformation. The problem then is reattaching the tags to the images. I have tried importing the untagged images the bringing the tags in as shown in the agisoft instructions but this does not work.

[Dave Martin]

Hi John,

I was pretty sure recent PhotoScan was using OS TN/GM 02, but as I don't have PhotoScan workstation to hand I can't confirm.

Where are you seeing the discrepancy - is it an on-screen tabular WGS84 and OSGB for the same GCP or check point? or is it when you go to get the coordinates from a point on a DEM?

cheers/Dave

[johnhalifax]

Hi Dave
The error becomes obvious when you compare the co-ordinates of the Ground Markers (GCP), surveyed using a Trimble R8 with the Trimble "VRS Now" OStn15 transformation, with the final dense point cloud or ortho image.
Using only GCP to fix the survey is fine this always works and is the workflow we have used for the past 3 years. The problem we have today comes about as we have a new system that uses PPK to geo-tag the images. We are surveyors so we know when things are in the wrong place.
I am hoping to resolve this within agisoft otherwise I am faced with the cost of purchasing/ leasing Pix4D which apparently doesn't seem to have this problem. Which we will confirm later today when we process the data in Pix4D.
By the way thanks for your help it is appreciated. If you have any other ideas keep them coming. I do feel that it is just a simple fix, some box that's not checked but so far the answer has eluded me.

[Alexey Pasumansky]

Hello johnhalifax,

Are you using EPSG::27700 or EPSG::7405 system? If OSGB grid with ODN height is used, then can you share the undulation grid that you are using with our support team?

Also if you are converting the coordinates directly in PhotoScan, are you using Datum Transformation Settings dialog to define ToWGS84 transformation parameters?

[johnhalifax]

Hi Alexey
Not sure what you mean in the first part of your post. I am aware of the european system and its link to wgs84 but other than that can't give you an answer on that. The undulation grid you refer to, do you mean the geoid? The one normally associated with the OS is OSgm15.
The second part, yes  I think I have tried the Datum Transformation Settings to define the transformation parameters. I hope that it is just something in here that I am doing wrong. That would be the simple answer. I am using version 1.4.2 build 6185 64bit. Do you have a workflow for this? does it differ in anyway to previous or newer versions? Do Agisoft have any support where I can speak with some direct or have a web link?

[Alexey Pasumansky]

Hello johnhalifax,

I can suggest to use version 1.4.4 where you can find the Datum Transformation Settings access button next to the coordinate system selection field (for example, when choosing the coordinate system for the DEM generation, results export or in the Convert coordinates dialog).

As for the coordinates issue itself, what is the target system that you are selected when converting the coordinates from WGS84 in PhotoScan? If you need to get the coordinates in British Grid (OSGB 1936) with the ODN height, then you should download OSGM15 geoid model from the following page: http://www.agisoft.com/downloads/geoids/
Then put it to the /geoids/ directory in PhotoScan Pro installation folder and re-start PhotoScan. After that use EPSG::7405 as a target system when converting the coordinates or exporting the results.

[johnhalifax]

Hi Everybody
Just to say Alexey has really tried with this but it seems we keep hitting one problem after another.
I hate to ask this but are there any Pix4D users out there and are you experiencing the same problem?

[Alexey Pasumansky]

Hello johnhalifax,

I suggest to check the proposed workflow on Metashape Pro 1.5.0 (local processing). Currently checking what's wrong with following the described approach in the version 1.4.4.

[johnhalifax]

Sorry I don't understand what you mean?

[johnhalifax]

Hi Alexey,
Tried 1.5 and it comes up with the same error message, " Can't import geoid from multi band image"
Have you tried this? Has it worked for you?
I can send you a link with some images for you to try?

[Alexey Pasumansky]

Hello johnhalifax,

With the latest version of Metashape Pro 1.5.0 build 7125 installed, please do the following:

- put osgb36_osgm15.tif to /Metashape Pro/geoids/ folder,
- start Metashape Pro,
- load images,
- load their coordinate from EXIF (usually performed automatically for geotagged photos) or load from CSV file,
- make sure that in the Reference pane settings dialog the coordinate system is selected according to the camera locations system (WGS84, EPSG::4326),
- click Convert button on the Reference pane toolbar,
- select "OSGB 1936 / British National Grid + ODN height" (EPSG::7405) from the list,
- if necessary - adjust Datum Transformation Settings, but you do not have to reload tif file with geoid, so do not alter Geoid Height field, it should already contain the name of the geoid file,
- confirm conversion for the cameras.

After that process as usual.

If the name of the geoid file is not displayed and you are experiencing similar issues to the version 1.4.4, then please make sure that you have latest build of Metashape installed (7125).