Coordinate system duality: A journey to a true dual CRS system

TL;DR

This blog is about trade-offs, dealing with past choices, and finding a pragmatic solution.

At Sensat, we use a dual Coordinate Reference System (CRS). For visualisation in our web platform, we use Webmercator (or our 3D derivative, Sensat Mercator) —For user-facing coordinates, measurements, and data uploads/downloads, we support almost 200 projected CRSes — It wasn’t always like that though.

Sensat aims to provide a cohesive, context-rich visual environment for construction projects. We offer both 2D and 3D capabilities, and our mid-term goal is to have all data visualised in one place. For a long time, however, 3D data was uploaded, stored, and rendered in the measurement CRS, while 2D data was in Webmercator. This became a blocker for bringing 2D and 3D data together.

To lay the foundations for merging our viewers, we settled on reprojecting everything to Webmercator and manually scaling altitude values to achieve the required visual quality. To get there, we weighed up three options against eight criteria, spanning implementation difficulty, data processing demands, performance, visual quality, and measurement integrity.

The result? We now have the ability to share data between 2D and 3D (and soon we’ll have it all together — watch this space!). We’ve also gained access to vast, Webmercator-ready public contextual datasets, improved performance, and delivered a higher-quality product.

What are we aiming for?

To give our users a seamless visual experience — where they can explore their data alongside Sensat’s reality capture and publicly available contextual datasets — we be able to render all data together. Currently, we have separate 2D and 3D viewers with only partial data sharing between them. Later this year, we plan to merge these, removing the barriers to working with all data types in one place.

The problem we had

Nothing is built without compromise. The separation between our viewers is a classic case of a young company moving fast to provide value. Naturally, you choose the path of least resistance, then circle back when use cases mature and customer expectations grow. In our case, having data split by environment was orthogonal to our USP — we federate data for all stakeholders, and this had to be addressed.

Technically, we had a bigger challenge: our environments used completely different coordinate systems for rendering. Until now, 2D rendering used a dual CRS approach with visualisation in Webmercator, while 3D rendering used only the measurement CRS.

To unify the data, we had to choose a common coordinate system — and as always, it came with trade-offs.

The choices

We have a mature product with enough users that we can’t afford to blow it all up and start again — in other words, we had to work with or around previous decisions. The system rendered 3D user data in the measurement CRS it was uploaded in, while 2D data was rendered using a classic web mapping setup backed by OpenLayers and the Webmercator CRS (EPSG:3857). In that space, we render publicly available contextual data, user-uploaded data transformed to Webmercator, and our own reality capture products — again, transformed to Webmercator.

💡Webmercator is an imperfect CRS for visualisation - is Greenland really the same size as Africa?! That said, it’s become the de facto web mapping standard since Google popularised it in 2015. ALL web mapping systems you may have used today use it - Google Earth, ESRI Online, Google Maps, Mapbox and OpenStreetMaps to name a few. Because of this most publicly available data comes pre-projected as Webmercator. This plus the abundance of tools mapping libraries exists for working with it make it the a clear choice.

Given that backdrop, we evaluated three options for unifying the CRS across all project data — against eight criteria:

Options:

1. Use the project’s measurement CRS
2. Use a geocentric 3D CRS such as EPSG:4978
3. Use Webmercator — EPSG:3857

Criteria (in order of importance):

1. How much data reprocessing is required?
2. How much of the ongoing data transformation can be done in ahead-of-time processing?
3. Would choosing the option mean we’d also have to complete the merging of our viewers?
   1. Viewer merging is big and complex enough on it’s own. We wanted to avoid getting in a situation where we abandoned the whole project because it was taking too long or was becoming too difficult to pull-off.
4. What are the implications on visual quality?
   1. The impact our choice has on the visual quality of output data and our ability to tune the runtime system for performance and quality.
5. How many transformation combinations will we have to manage?
   1. CRS transforms are notoriously fiddly - often there’s more than one way to perform the calculation. We’d run into trouble in the past choosing a transform which had a better alternative which lead to embarrassingly offset data.
6. Would it require structural changes to either render engine - e.g navigation and camera controls?
7. How easy is the coordinate system to work with for non domain expert colleagues?
8. Would we have to build extra tooling to ensure measurements taken by the user are calculated in their measurement CRS?

Why we chose Webmercator

Option 2 (a true 3D CRS) seemed ideal — we’re building a 3D-first platform, after all. If we were starting from scratch, it would’ve been my top choice. But making it work with our legacy setup would’ve required reprocessing all existing data, plus additional tooling to expose useful, human-readable coordinates (because geocentric Z is the axis between the poles, not altitude). We’d also have to rebuild our 3D viewer’s navigation and camera logic — and we couldn’t justify 1–2 years of work before users saw any value. So, we ruled that out.

Option 1 also dropped out quickly. It would require on-the-fly transformation of contextual data at runtime and managing a many-to-many set of transformations — including support for both vanilla UTM systems and niche CRSes like SnakeGrid. We didn’t want to play CRS transform whack-a-mole. The upside would’ve been native measurements and coordinate readability for users — but it wasn’t worth the complexity.

That left Option 3: Webmercator. Why?

• We’d only need to reprocess existing 3D data
• Most contextual data is already in Webmercator
• No on-the-fly transforms required
• We could limit changes to the 3D renderer only — no structural changes
• Coordinates would be intuitive for non-domain experts
• We’d only need to handle transforms into/out of Webmercator — a one-to-many relationship we already manage

The downside? Webmercator isn’t a 3D CRS — so we’d have to correct altitude distortion and we’d have to be careful about doing calculation in the measurement CRS.

The implementation

As mentioned, Webmercator has its quirks — but we were happy with the devil we knew. Once all trade-offs were considered, it stood out as the best choicewe could solve the altitude distortion issue.

Correcting the Z

Webmercator is a conformal 2D CRS, with distortion increasing away from the equator (see Greenland, above). There are no reprojection tools (we use Proj and Geodesy-Wasm) that scale altitude values. Without correction, this results in flattened 3D visuals at high latitudes.

The fix is simple: scale the Z value by applying the Webmercator scaling factor, calculated as

s = 1 / cos(φ) — where φ is the coordinate's latitude.

We’ve added this scaling step to our data processing pipelines and measurement APIs. We call the result Sensat Mercator — a playful nod to Webmercator’s original name, Google Mercator.

💡We know how this may sound to GIS purists - we feel it too. But given the landscape we found ourselves on, Webmercator (and our Sensat Mercator derivative) was honestly the best choice.

Wrapping it up

The most optimal solution on paper isn’t always the right one in practice — and this was definitely one of those times. The good news? We could deliver our chosen design quickly and move on to the next phase.

Our focus is, and always will be, adding value for our users. We know we can revisit choices if and when we need to. For now, we’re full steam ahead on merging our viewers and bringing all project data into a single visual environment.

‍