Discrepancies between OSGB grid reference and lat/long

[stripytrigger]

I've noticed that some trig points have an OSGB grid reference that doesn't agree with the WGS coordinates given.

For example:

https://trigpointing.uk/trigs/11885 (Corby Church Spire) - clicking the WGS coordinates link opens google maps at the wrong place. The OS map shown on the page also shows the location in the wrong place. However, the OSGB 10 figure grid reference does appear to be correct when pasted in to https://explore.osmaps.com/ (I know there are multiple ways to convert between OSGB and WGS but I'm hoping osmaps.com gets close enough). The distance between the correct and incorrect points is around 1000m, so this isn't just a rounding error!

https://trigpointing.uk/trigs/4833 (Millfield Clump) - The WGS coordinates (and thus the OS map on the page and also the google maps link) take you to the location where the OS maps mark there being a pillar. However the grid reference takes you to a different location (approx 1171m away), which appears to likely match its current location based on recent logs/photos on that page.

So in the latter case the discrepancy looks to be the result of a move (and the grid reference has been updated but not the WGS coords), but in the first case I doubt the church has moved.

These are just two examples, if it's useful I can produce a list of everything that looks like it might be wrong (based on the difference between the data points in a download file), but it's difficult to know which are the result of moves and which are just incorrect data. For those that are wrong it's fairly clear from looking at a map which is the right one, but this could be quite a tedious manual exercise, so I'm interested to know if one of these data points is considered the source of truth?

[Teasel]

Yes, it's all a bit of a mess!

• The biggest issue is that there's effectively no support for trigpoints which have moved. We've been editing the base data based on people's observations. Bugs have accumulated errors. But before we can go and fix them, I need to work out how to handle moved trigpoints. I'm leaning towards resetting the map and the base data back to the official original location, with a new field to say where it's moved to. Not sure what to do about trigpoints which have moved a long way? (North Ockendon springs to mind!)
• On the old site, the OSGB coordinates were used for almost everything. On the new site, almost everything uses WGS coordinates. Therefore previously-hidden discrepancies have become more noticeable
• The old site rounded everything to 1m. I've recently increased this so we can store more accurate coordinates, but haven't back-populated anything yet
• The old site used simple Helmert transformations to convert between OSGB and WGS. I've recently implemented OSTN15/OSGM15 transformations, but haven't yet done a bulk re-calculation
• Irish trigpoints were shoe-horned into the old site using OSGB coordinates. The new site has better support for OSI, but I'm not sure where definitive data can be obtained

I've put together a list that shows the distance between the WGS and OSGB base data for each trigpoint. And, where it is available, the distance between the base data and the official Ordnance Survey records for the trig.
The good news is that there aren't too many horrendous examples like Corby Church Spire, but a good number of the moved trigpoints are worryingly inconsistent.

First thing to do is to sort out a home for "moved-to" locations. Then I'll do a bulk re-population of the base WGS and OSGB coordinates from whatever official OSGB36 / OSNet data I can cobble together. Then we can see what's left!

[Teasel]

NB the above link is mainly relevant to OSGB36 stations. A similar dashboard for OS Net active stations is currently hidden behind admin-only authentication, but the situation is just as dire...

Screenshot_20260128_230222.png (92.9 KiB) Viewed 1107 times

[stripytrigger]

That all sounds pretty reasonable to me, though I wonder if there might be some simplifications that could be made now.

I need to work out how to handle moved trigpoints

This might be controversial, but I suspect that the majority of visitors to this site are here to look for the location of trig points that they can visit, or log or find info for a trig point that they have recently visited. I would imagine that the number of visitors looking for historical location information is very low percentage-wise. Thus, I'd argue that the base data for a trig should be its current location. And if that changes? Then we should update the base data. Historical locations could be stored in a seperate field (or fields if it's moved multiple times!), but to be honest I suspect a note in a free-text "notes" field would be sufficient for most people. Another option would be to store the history of all changes that have happened to a trigpoints data (including any corrections), but again I suspect for most people this is not required.

On the old site, the OSGB coordinates were used for almost everything. On the new site, almost everything uses WGS coordinates.

I think this is a sensible change. While OSGB sounds great for someone looking at an OS map, for almost everything else you want WGS. And when you add in Irish grid, channel islands grid etc, you really want a single, consistent format to store all locations in.

but haven't yet done a bulk re-calculation

Again this perhaps is controversial, but are the OSGB refs actually used for anything other than displaying to the user? If no do the OSGB grid refs need to actually be stored in the database? Could they be calculated on the fly from the WGS coords? This allows you to store WGS as the source of truth, and therefore frees you to choose/change the algorithm that is used to convert to the OSGB ref, without needing to do a mass recalculation of the OSGB refs. I think I remember seeing OSGB in downloaded files, but perhaps it could be removed from there too, to lessen the burden of doing a lot of transformations when someone wants to download something. I think that storing the same data twice, in two different formats, is probably asking for them to become out of sync. Of course one downside of converting on the fly is that the conversion code would need to apply different conversions depending where the point is, in order to convert to the right thing (to OSGB, or to Irish grid etc).

where it is available, the distance between the base data and the official Ordnance Survey records for the trig

I guess that's a whole other thing - how accurate the data is compared to reality. I was only looking at how accurate the T:UK data was with itself. I would expect there to be differences compared to OS records, due to both movements but also inaccuracies/errors in the OS data that won't have been corrected since. I guess there's no way to work out whether the difference is correct without manually looking at each case?

Regards, and thanks for all the great updates recently,

-stripytrigger