Introducing Nearmap for Post-catastrophe Response
Post Catastrophe Imagery and AI-derived property damage and condition data unite to help insurers process customer claims more efficiently.
Post Catastrophe Imagery and AI-derived property damage and condition data unite to help insurers process customer claims more efficiently.
Q: What’s the difference between a three-toed sloth, considered to be one of the slowest animals on Earth, and Australia?
A: The sloth moves much faster than Australia!
If you are reading this post, chances are you are well aware of Australia’s constant continental movement, sometimes referred to as continental drift. Whilst Australia moves slower than a sloth, it is actually VERY fast in geological terms — anywhere from 55 to 70mm per year. This topic has been well covered in the media and technical publications. Here’s a good start: Spatial Source.
(Image courtesy of GDA2020 Technical Manual V1.1.1)
At Nearmap, we welcome the introduction of GDA2020. The accuracy of our imagery is constantly improving, and we are committed to delivering our imagery in the way that minimises inaccuracies (you can read more about the projection dilemma on the Esri Australia blog). We found the shift between ITRF and GDA94 is the biggest contributor to the accuracy perception, and we’re actively taking steps to prevent it.
Our imagery is captured, processed, and stored using the ITRF2014 epoch of the date of capture. For a survey that was captured on June 30, 2019, the epoch is 2019.492. (For a primer on how to calculate the epoch from a date, see section titled “6.1 ITRF” in GDA2020, AUSGeoid2020 and ATRF: An Introduction).
We’ve been providing imagery in GDA94 through WMS since we were founded in 2007. We have always supported the GDA94 geographic coordinate system (EPSG:4283) and individual GDA94 MGA zones (49 through 56). Because the imagery is stored in ITRF, it is transformed on the fly to GDA94 by our state-of-the-art WMS server, taking into account the epoch of the original imagery.
Our on-the-fly reprojection capability provides a solid foundation to release the GDA2020 support. We are pleased to announce the release of our new WMS service, which supports both GDA94 and GDA2020. With the new WMS, you will be able to request imagery in either GDA94 or GDA2020 without needing to bring in transformation grids (e.g. NTV v2).
The existing WMS will remain as is, and we are adding a new, improved WMS service in line with our API modernisation program. You can read more about our new generation of APIs in one of our earlier posts about our new Tile API. The new version of the WMS service and the specifics of new WMS APIs will be announced shortly.
We are very excited to be refreshing our WMS offering. In addition to all the benefits of the new API approach, we will support both GDA94 and GDA2020 in the same service. This is a deliberate design to allow our users to migrate to GDA2020 from GDA94 at their own pace. All that is required to switch to GDA2020 is to change the project coordinate system in your GIS application (e.g. ArcMap) or to request a new layer using GDA2020 CRS (QGIS).
The first version of the new WMS will provide access to the latest imagery only. At launch, you will be able to select from the following projections:
To demonstrate how this works, let's walk through a typical GDA94 to GDA2020 transition exercise. We are going to use real data here — using a release candidate WMS service and a free conversion service from Geosciences Australia to change points from GDA94 to GDA2020.
Step 1
Here we start with our data in GDA94. The points are well aligned to the GDA94 imagery. This represents a lot of the datasets that are out there.
Step 2
We now convert our dataset using the free converter service from Geosciences Australia and add both GDA94 and GDA2020 to the same map. You can see that the GDA2020 point is offset from the GDA94 one and no longer aligns with GDA94 imagery.
Step 3
We now switch to using one of the GDA2020 imagery layers from Nearmap, and we can see that the GDA2020 is in the same location as the original point was with respect to GDA94.
Step 4
After performing verification on our datasets, we are confident that the migration is successful, and we are going to archive the GDA94 data, leaving only GDA2020 data accessible to the organisation.
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.
Projection: A mathematical transformation of angular coordinates (typically degrees) to cartesian coordinates (typically metres or feet), taking into consideration the datum.
N.B. Projection in WMS terms is sometimes used interchangeably with CRS.
Datum: System for representing angular coordinates on the surface of Earth. Typically consists of ellipsoid or spheroid, reference frame, and epoch.
CRS: Coordinate Reference System. This is a well-defined code (e.g. EPSG:4326) that codifies a projection and datum to be used for converting Earth coordinates to projected coordinates.
SRS: Spatial Reference System, equivalent to CRS.
Epoch:Date and time on which the datum is based, e.g. 2014.0.
