Our WMS tries hard to serve content using the projection that the client software uses for display. In addition to ensuring datum correctness, there is another very good reason for that: avoiding quality degradation from client-side reprojection.
To understand what happens here, first we need to understand how GIS applications request WMS content. The exact mechanism differs between the likes of ArcGIS Pro, QGIS, and Autodesk platforms, but the basics are the same.
There are two places to set the coordinate system: in the project settings and on the WMS layer. The former controls the coordinate system that is presented to the user. This is sometimes called “on-the-fly reprojection.” The latter controls the coordinate system that is used to request content from the server.
When the two coordinate systems are the same, the image from the server is simply displayed on the screen. This is the best quality image you are going to get. When the two systems are different, the client software has to reproject on the fly, and there is a quality drop. You can see the difference below.
When the server doesn’t support the requested CRS, it will use the default CRS, which is WGS84 (EPSG:4326). This is where things get interesting. WGS84 (both the geographic version and its close cousin Web Mercator) are the two most popular projections for delivering content over the internet, and neither is specific about which datum the data is based on. This leaves the onus of selecting a datum and communicating that to the user to the service provider. It’s common in Australia to create datasets in GDA94 and convert them to WGS84 for presentation on the web with no datum shift. Using the same approach, one can convert GDA2020 datasets to WGS84. If you then open the two datasets side by side, you will notice the GDA94/GDA2020 offset, even though they may be using the same CRS.
The users are none the wiser in either scenario. In order to ensure datum alignment, they will need to know the datum of the default CRS and perform a datum shift on the client side (which is difficult and error-prone).
This is where the combination of a different default (GDA2020) and an ability to request either GDA94 or GDA2020 from the same Nearmap service really shines. The chances of undefined behaviour are greatly reduced.
We will be watching with interest as the industry moves from GDA2020 to ATRF, bringing date- based datums. As we described earlier, the spatial web protocols don’t have a mechanism to communicate the epoch of the content when Earth-based coordinate systems are used (such as WGS84). When the protocols of client software get sophisticated enough to handle datasets with dates, our data will fit naturally into the ecosystem; all our captures are tagged with a date, and we have all the metadata needed to supply alongside the imagery.