Removing WGS84 Assumptions & Dependencies

Chesapeake Times, Vol 17 | April 2024

SonarWiz has traditionally relied, in a number of ways, on translations between coordinates in the “projet output” system (the X/Y coordinates reprented in the plan view, in the projection system chosen at the project creation) and WGS84 latitude/longitude (EPSG:4326) coordinates. We assumed a lot of incoming data – sonar or ancillary – was of WGS84 latitude/longitude origin, or translated it to that for storage. Doing so allowed us to have a single underlying reference system to bring together a number of incoming data from various places and treat them similarly, but at the cost of correctness in some circumstances.

In the recent past, we’ve started storing and using “as-originally-imported” coordinate rference system identifiers (spatial reference identifies [SRIDs]) for some (sidescan, sub-bottom, bathy and FLS) data. See David Finlayson’s recent related article at: https://chesapeaketech.com/datumtransformations, which explains some of the benefits of this change.  In particular, storing original coordinates and their associated SRID eliminates some positioning errors and allows for the possibility of after-import corrections.

In SonarWiz 8.0, we’ve made another change in this direction: storing SRIDs for features.  Previously, features and the points associated with them were treated as having WGS84 latitude/longitude (EPSG:4326) coodinates.  We’d take grid coordinates from the plan view or a waterfall and convert them to EPSG:4326 for storage.  Those created on a waterfall would draw correctly there – row and range are stored as well – but all would be subject to plan view positioning errors when in a project using a system that doesn’t allow for a near-lossless trip to WGS84 and back. The GDA datums were the proximate motivator for this change – we’d see errors of this type around a meter and a half near Perth.

We have more to do, though.  For features, allowing SRID selection at import time and editing after the fact would improve the system; the present change focused mainly on features created on the plan view and within waterfalls.  Additionally, there are other project artifacts still used in SonarWiz assuming or translating to WGS84 coordinates, such as survey lines, cores, map corrections, and to a lesser extent, contacts. Each of these would benefit from a similar treatment.  We’ve got a list going for future improvements.  For now, though, I’ll try to leave you with some words of wisdom.

“The best time to stop needlessly relying on WGS84 lat/lon (EPSG:4326) as a pivot datum is twenty years ago.  The second best time is now.”
    – Confucius, probably

I offered up that quote to David for his previous article and he didn’t bite.  Can you believe it?  Me either.  So there it is.