Non clickbaity version: they did not “jump” anywhere, the coordinates for GPS were just updated for the first time since 1994 to account for the constant movement of 7cm per year. And it’s not just these 2 parts of Australia, it’s all if it. NSW and Victoria just moved slightly more than the rest (1.8m vs. 1.5m or 1.7m for other parts).
if you're relying on that map, it's an old one not current with the text in the article actually, victoria and nsw moved only 1.5 m in it, less than average and certainly less than the areas that moved the most, which are parts of the northern territory and western australia.
that map was produced a few years ago, when gda2020 was defined. since then, victoria and nsw have moved about another 14-21 cm, hence the 1.8 m figure. i think there's a little padding included too to account for future drift.
as to the question of if these two states alone jumped, yes, they would have, if you have a datasink that collects official maps and collates them. roads that align on the ground might not meet on your map, since victorian data is gda2020 and south australia is gda94.
how do you deal with that in real life? it's a real concern to real people, and it is not clickbaity to report it. the article did a good job of explaining how it matters to a normal person, but not a good job of explaining why it matters. that is the correct criticism.
Not quite: "To fix this, all Australian states and territories have agreed to update their coordinates by June. However, they are all doing it at their own speeds. On January 1, the Victorian and NSW governments updated the coordinates of every road, property and geographical feature in their states, essentially moving the south-eastern seaboard 1.8 metres north-east overnight."
So all of Australia will move by June, but so far only NSW and Victoria have.
I don't see why it's a good idea to update coordinates of different parts of a continent at different times. Likely a political decision, not a technical one.
It sounds like it wasn't an explicit decision, they just have different people working on it and the NSW and Victoria people were able to make the change earlier than others.
The complaint was towards the clickbaity title which leads one to believe there must have been a sudden tectonic event that caused the continent to move.
“Florida man jumps back in time by one hour!” - leap hour reporting.
Somewhat clickbaity headline. The change is being made to fix a 1.8 metre inaccuracy that has crept into our GPS coordinates, caused by Australia slowly drifting north.
The trickiest part is going to be that some previous GPS coordinates will have been "pinned" to the 1994 grid, and others will have been taken live over that time span.
See, surveyors have always known that you can't actually just write down the GPS coordinates of a boundary or intersection or bridge, because of this exact problem. So surveyors do the math (well, most likely their specialized surveying GPS equipment does the math) and write down the coordinates relative to the baseline for the continental plate in question.
If you have coordinates you know were LAT, LNG in the 1994 baseline, it's easy to apply the transform and get the LAT', LNG' in the new 2020 baseline.
But what happens if your coordinates weren't provided by a surveyor carefully surveying a location in the appropriate baseline? What if your coordinates were measured by a jerk walking to a place last year with a GPS and writing down whatever was displayed? Those coordinates don't need to be transformed, they were already basically correct for the 2020 baseline. If you add the correction to those numbers you're introducing a new error. And to make matters worse, people have been entering non-calibrated numbers into your data set for 25 years -- some numbers will have 5 years of drift, some 15 years. If you know when an uncalibrated measurement was made, you can kind-of interpolate the drift, but without that you're just SoL.
To make matters worse, a company like Google is using data from a wide variety of sources, some they gathered themselves, some they get from others. With your own data, you might at least know either whether it was calibrated to the previous baseline or at least when it was collected, but someone else's dataset might be messy in unknownable ways.
Say you previously got the location of a park entrance from a government parks department, in the 1994 coordinates. Now you go through your aggregated dataset and apply the transformation to the coordinates and get the new number in 2020 coordinates (which thankfully will match what a consumer GPS actually says, now). Next month, when you update your data from the government parks department, it gives you a different coordinate for the park entrance, which is neither the number you had previously for the entrance in 1994 coordinates nor the number you computed in 2020 coordinates.
Now, do you assume that new number is in the new coordinate system, or might it still have been measured in the old coordinate system, either having been measured prior to the changeover or just on old equipment that was not updated? Ideally your interchange format would include the time a GPS measurement was taken as well as any baseline it was calibrated to, but do you want to guess how often interchange formats are "ideal"?
So, long story short, it's going to be a long time before most of the old coordinates are flushed from the system, and you'll probably occasionally see a "wrong" coordinate that can be traced to this sort of thing every now and again for the rest of your life.
the moral to this story is don't dilute your data. if your data is delivered in gda94, don't convert it to gps coords so all your data is in the same format. instead, when you render it, render it from gda94 into your own coordinate system.
that way, you won't have a problem with interpreting what it means. there's no such thing as 145°E 40°S, but there is “145°E 45°S gps 2016-05-07” and that can forever be handled.
Google Maps' Timeline feature has a bug where changes to place names propagate to the past. A bakery where I used to get lunch has changed to a burger place, so if I look back to where I had lunch on that day 2 years ago, it would mislead me into thinking I got a burger...
I hadn't thought of this, thanks for explaining it so thoroughly.
Could you explain though, how you record LAT, LNG coords relative to a continental plate baseline? I thought to solve this problem you simply recorded the time that the measurement was taken, so that you can update the coords based on known plate position data at a given time (e.g. if you know a position was recorded somewhere in Aus in 2018, you just add 2cm x 7cm/yr = 14cm north east to the measurement to get the 2020 coords).
That's honestly getting to a point I only know vaguely about -- my real-world experience is just from chatting with surveyors when I needed to get a couple of parcels of land surveyed (once for a boundary survey, wherein I'm not sure this came up, and once for a FEMA/flood zone survey, where matching the site data to the FEMA data was much more important).
Part of the answer, in the US, (and the expensive equipment -- one of the smaller surveyors I talked to just rented it on an as-needed basis) are the Continuously Operating Reference Stations, which is a network of ground-based stations of defined positions which are used to refine GPS coordinates relative to the National Spatial Reference System: https://www.ngs.noaa.gov/CORS/
> To fix this, all Australian states and territories have agreed to update their coordinates by June. However, they are all doing it at their own speeds.
> Official government road maps and property boundaries will now line up perfectly with GPS location data.
> It will take some time for companies like Google to pick up and implement the new data. But when they do, you will enjoy slightly more accurate satellite navigation.
I don't get it. Does Google have to wait for government? Why couldn't Google incrementally add 1.8 meter to its maps on its own schedule, years ago?
Data providers like Google may have already made the switch, or instead of using the static datums they might use a time-dependent datum where the coordinates change with time.
Thought we like to think of Google as a big data company, for many of its projects it's more an aggregator of other people's data. Yes, it does create original data. But a lot of its data is from outside sources. Very often data that you paid for with your tax dollars, and then get to pay for again with your privacy.
Does anybody know how what3words is dealing with this?
Do locations suddenly have a new 3 word location, or have the words stayed the same and the location they refer to (in GPS co-ordinates) changed?
well, plenty of places could have moved out of their box. many urban properties are quite narrow; i lived on one not even 2.5 metres wide, so every 3m box would be in use (and potentially then some) on that street. (i didn't have an address living there either, but w3w wasn't going to help that problem much. easier to give a recognisable landmark.)
> It will take some time for companies like Google to pick up and implement the new data. But when they do, you will enjoy slightly more accurate satellite navigation.
I wouldn't hold my breath. Google's adoption of updated information for anything other than the capital cities is extremely slow. On the order of the data has been in OSM for five years slow.
Google has photographs of my house from above, and from the road, and doesn't list the road as existing.
They're probably inclined to add this GPS shift data for the capital cities - but the mapping data will probably be inconsistently updated.
Especially as the state and territories provide the data in an incredibly wide range of formats.
VIC, NSW, SA provide shapefiles, which is great, as it is becoming one of the more popular standard. (They also export for a range of other data types).
The NT provides a strange mix of shapefiles and custom xlsx sheets. Unless you're looking at Darwin or the heart of the Kimberly's, you'll be looking at human-written Excel sheets for a lot of this.
QLD, the ACT and WA seem to use OpenGIS/ArcGIS XML files.
Tasmania doesn't maintain their own data, but relies on ANZLIC to do it for them, and seem to be in the middle of an argument over who will do the maintenance moving forward. (The last update to any of their public data appears to be in 2016.) This was shapefile/export like VIC, NSW and SA, but it becomes somewhat useless if it never gets updated.
If you're an islander, you sort of have to hope that the state/territory includes you in their dataset. They don't always. And they're not consistent about when they include you. Regressions are common. Councils tend to maintain their own data, but rarely allow anyone access, paid or not. If you hand them a FOIA request to see the data, then... Well, I got handed a series of printed XML documents, after six months of them threatening to take me to court for requesting it. Multiple island "councils" (often different names, but similar functions) did this.
You should be able to easily submit corrections to the Google maps data, especially if the overhead satellite data already matches. I was able to get my house and street corrected with just a couple requests.
It's been three years and six requests. I don't think it'll happen without someone from the team seeing it on social media. Hell, they have the suburb wrong, let alone the non-existent street.
I tried getting them to correct the location for the apartment I used to live in for months but it kept bieng rejected. I recently got a message 3 years after I had moved that my edit was accepeted.
We had an issue, where they kept reverting to pre-911 addresses in places where there were geocoding gaps in the new address dataset. Even after submitting changes, and having them implemented, they would revert back, presumably every time they merged updates to the new dataset. I suspect the new addresses existed in the list and were imported, but with null coordinates.
We stopped updating, because then you could at least consistently give people the old address for directions. (They did eventually do a permanent fix.)
It seems to be resolved now, but for many years the instant I crossed into a national park the maps would be about 2 metres off from the location reported by GPS. It was just enough to trigger frequent rerouting, which would fail due to no data signal.
I suspect Google uses their own projection for maps in Australia, as they do in the US, which, depending on how they defined and implemented it, could/should add the intermediate layer needed to help resolve this quickly. But there are way too many variables to speculate in any meaningful way.
Depending on how they store imported data vs different Google generated data, you could be talking about a simple transformation parameter change to their projection, or you could be taking about some complex, varying corrections.
For instance, if Google was already using street view or proprietary aerial images for ground truthing, they may have already compensated for the shift in various data sets, in different amounts, depending on when it was collected, and how they handled location adjustments due to discrepancies.
But being Google maps, I wouldn't expect accuracy better than a few meters for any given dataset anyway, given past performance.
Very exciting to have a tangible feeling for plate tectonics like this, and great reporting. As the article says, in the course of a lifetime the continental plate has drifted enough for GPS to mean your Uber shows up on the wrong side of the street.
I wonder if it would be possible to detect the movement by choosing some narrow and very popular touristic spot (such as the top of a building, a viewpoint on a cliff..) and averaging the gps coordinates of the public pictures taken by tens of thousands of visitors during the years. It would be cool.
I'm surprised big GPS users like Google haven't already fixed this on their apps as post-GPS corrective step. Another example of caring little and doing the job so-so :/
This isn't a novel thing, as far as I can tell. A decade ago when I was working on routing of over-the-road trucking, our maps provider moved the entire United States a couple meters and it broke all our road restrictions.
The problem for us -- and likely for those in Australia now -- is that converting physical address descriptions and lat/long becomes a little more fraught. We described road restrictions as being "on the road that is found between X1,Y1 and X2,Y2." A separate layer would snap those X,Y coordinates to the road network and find the road between them. Before the move, that meant converting to "Highway 6 Southbound from milemarker 16 to milemarker 28"
But when you moved the world, X1,Y1 no longer landed on Highway 6, and instead snapped over to the frontage road. Your restriction now read as "Highway 6 Southbound, down to exit 21, around the corner to the frontage road, then down the frontage road". And your restriction that used to say "stay off this one section of road" now says "stay off the highway, the frontage road, and don't use this exit."
While the problem isn't novel, that's probably not what happened with what you're describing, for a number of reasons.
Most local datums are anchored to the local geology. So in the US, if you're using nad27 or nad83, the reference system is "moving" along with the continent (nad83 = North American Datum 1983), based on some weighted benchmark vectors and a lot of math. It's one reason why different datums with defined epochs exist. Some are static, but some are actually dynamic with time (eg ITRF).
But most people don't grok any of that and just stick with defaults, or guess-and-check during map setup and go with whatever looks "close enough".
In your case, chances are the map provider switched datums with the update, from nad27 to nad83, and your software wasn't told about the change. Or it was, but your road restriction data was drawn in the old projection, and not converted / transformed to the new one.
Or, you could have had data that initially was mislabeled, recorded with GPS (wgs84) and entered using one of the many datums that's similar, but not the same. Or maybe collected using one of the many state plane coordinate systems (which people tend to like because it's more or less Cartesian- east,north) which are themselves built in top of one of the datums. You can pick the right coordinate zone, but wrong underlying datum.
If any data provider or aggregator or if your company GIS guru ever selected the wrong projection (choices often are dozens of coded options that look nearly identical), or left it blank (undefined) because they weren't sure...
A instant "shift" would happen as soon as you "corrected" the error, (or upgraded software, or any other number of situations).
This is where a good GIS guru earns their keep, because conversions between projections and datums are just math, and data can often be corrected in seconds by running it through a manual "inverse" conversion, assuming one can recognize what happened.
Back to Australia: if people used GPS coordinates (wgs84) and didn't convert to a Australian centric datum (which is the default option for most collectors), the data would "stay still" while the continent moves. Which is one of many reasons why selecting an appropriate datum/ projection is so important.
For the US: While there is some intra-datum movement between nad27 and nad83, most of the differences are do to improvements in the quality and accuracy of surveys over half a century. So the differences between the two datums tend to grow as you get further from the beginning points of the surveys.
Which means some areas, like a lot of the East coast, have minimal differences, and areas out West have larger deltas, but it varies.
A couple of meters would be better explained by a bad datum transformation than by drift, which is likely an order of magnitude smaller at even the worst locations for the US.
42 comments
[ 3.4 ms ] story [ 89.7 ms ] threadMore that the other states haven't yet updated their data to account for the changes at all, yet. They have until June.
that map was produced a few years ago, when gda2020 was defined. since then, victoria and nsw have moved about another 14-21 cm, hence the 1.8 m figure. i think there's a little padding included too to account for future drift.
as to the question of if these two states alone jumped, yes, they would have, if you have a datasink that collects official maps and collates them. roads that align on the ground might not meet on your map, since victorian data is gda2020 and south australia is gda94.
how do you deal with that in real life? it's a real concern to real people, and it is not clickbaity to report it. the article did a good job of explaining how it matters to a normal person, but not a good job of explaining why it matters. that is the correct criticism.
So all of Australia will move by June, but so far only NSW and Victoria have.
I don't see why it's a good idea to update coordinates of different parts of a continent at different times. Likely a political decision, not a technical one.
“Florida man jumps back in time by one hour!” - leap hour reporting.
The trickiest part is going to be that some previous GPS coordinates will have been "pinned" to the 1994 grid, and others will have been taken live over that time span.
See, surveyors have always known that you can't actually just write down the GPS coordinates of a boundary or intersection or bridge, because of this exact problem. So surveyors do the math (well, most likely their specialized surveying GPS equipment does the math) and write down the coordinates relative to the baseline for the continental plate in question.
If you have coordinates you know were LAT, LNG in the 1994 baseline, it's easy to apply the transform and get the LAT', LNG' in the new 2020 baseline.
But what happens if your coordinates weren't provided by a surveyor carefully surveying a location in the appropriate baseline? What if your coordinates were measured by a jerk walking to a place last year with a GPS and writing down whatever was displayed? Those coordinates don't need to be transformed, they were already basically correct for the 2020 baseline. If you add the correction to those numbers you're introducing a new error. And to make matters worse, people have been entering non-calibrated numbers into your data set for 25 years -- some numbers will have 5 years of drift, some 15 years. If you know when an uncalibrated measurement was made, you can kind-of interpolate the drift, but without that you're just SoL.
To make matters worse, a company like Google is using data from a wide variety of sources, some they gathered themselves, some they get from others. With your own data, you might at least know either whether it was calibrated to the previous baseline or at least when it was collected, but someone else's dataset might be messy in unknownable ways.
Say you previously got the location of a park entrance from a government parks department, in the 1994 coordinates. Now you go through your aggregated dataset and apply the transformation to the coordinates and get the new number in 2020 coordinates (which thankfully will match what a consumer GPS actually says, now). Next month, when you update your data from the government parks department, it gives you a different coordinate for the park entrance, which is neither the number you had previously for the entrance in 1994 coordinates nor the number you computed in 2020 coordinates.
Now, do you assume that new number is in the new coordinate system, or might it still have been measured in the old coordinate system, either having been measured prior to the changeover or just on old equipment that was not updated? Ideally your interchange format would include the time a GPS measurement was taken as well as any baseline it was calibrated to, but do you want to guess how often interchange formats are "ideal"?
So, long story short, it's going to be a long time before most of the old coordinates are flushed from the system, and you'll probably occasionally see a "wrong" coordinate that can be traced to this sort of thing every now and again for the rest of your life.
that way, you won't have a problem with interpreting what it means. there's no such thing as 145°E 40°S, but there is “145°E 45°S gps 2016-05-07” and that can forever be handled.
Google Maps' Timeline feature has a bug where changes to place names propagate to the past. A bakery where I used to get lunch has changed to a burger place, so if I look back to where I had lunch on that day 2 years ago, it would mislead me into thinking I got a burger...
Could you explain though, how you record LAT, LNG coords relative to a continental plate baseline? I thought to solve this problem you simply recorded the time that the measurement was taken, so that you can update the coords based on known plate position data at a given time (e.g. if you know a position was recorded somewhere in Aus in 2018, you just add 2cm x 7cm/yr = 14cm north east to the measurement to get the 2020 coords).
Part of the answer, in the US, (and the expensive equipment -- one of the smaller surveyors I talked to just rented it on an as-needed basis) are the Continuously Operating Reference Stations, which is a network of ground-based stations of defined positions which are used to refine GPS coordinates relative to the National Spatial Reference System: https://www.ngs.noaa.gov/CORS/
> Official government road maps and property boundaries will now line up perfectly with GPS location data.
> It will take some time for companies like Google to pick up and implement the new data. But when they do, you will enjoy slightly more accurate satellite navigation.
I don't get it. Does Google have to wait for government? Why couldn't Google incrementally add 1.8 meter to its maps on its own schedule, years ago?
https://www.icsm.gov.au/australian-datums-and-how-move-betwe...
Data providers like Google may have already made the switch, or instead of using the static datums they might use a time-dependent datum where the coordinates change with time.
Thought we like to think of Google as a big data company, for many of its projects it's more an aggregator of other people's data. Yes, it does create original data. But a lot of its data is from outside sources. Very often data that you paid for with your tax dollars, and then get to pay for again with your privacy.
However, what3words is only accurate to 3m, so this change may not have affected their system at all.
https://www.icsm.gov.au/gda2020/what-changing-and-why
Similar efforts are going on elsewhere, e.g.
https://www.ngs.noaa.gov/datums/newdatums/TrackOurProgress.s...
I wouldn't hold my breath. Google's adoption of updated information for anything other than the capital cities is extremely slow. On the order of the data has been in OSM for five years slow.
Google has photographs of my house from above, and from the road, and doesn't list the road as existing.
They're probably inclined to add this GPS shift data for the capital cities - but the mapping data will probably be inconsistently updated.
Especially as the state and territories provide the data in an incredibly wide range of formats.
VIC, NSW, SA provide shapefiles, which is great, as it is becoming one of the more popular standard. (They also export for a range of other data types).
The NT provides a strange mix of shapefiles and custom xlsx sheets. Unless you're looking at Darwin or the heart of the Kimberly's, you'll be looking at human-written Excel sheets for a lot of this.
QLD, the ACT and WA seem to use OpenGIS/ArcGIS XML files.
Tasmania doesn't maintain their own data, but relies on ANZLIC to do it for them, and seem to be in the middle of an argument over who will do the maintenance moving forward. (The last update to any of their public data appears to be in 2016.) This was shapefile/export like VIC, NSW and SA, but it becomes somewhat useless if it never gets updated.
If you're an islander, you sort of have to hope that the state/territory includes you in their dataset. They don't always. And they're not consistent about when they include you. Regressions are common. Councils tend to maintain their own data, but rarely allow anyone access, paid or not. If you hand them a FOIA request to see the data, then... Well, I got handed a series of printed XML documents, after six months of them threatening to take me to court for requesting it. Multiple island "councils" (often different names, but similar functions) did this.
They have a system but seem to be missing the processes.
We stopped updating, because then you could at least consistently give people the old address for directions. (They did eventually do a permanent fix.)
Depending on how they store imported data vs different Google generated data, you could be talking about a simple transformation parameter change to their projection, or you could be taking about some complex, varying corrections.
For instance, if Google was already using street view or proprietary aerial images for ground truthing, they may have already compensated for the shift in various data sets, in different amounts, depending on when it was collected, and how they handled location adjustments due to discrepancies.
But being Google maps, I wouldn't expect accuracy better than a few meters for any given dataset anyway, given past performance.
https://www.icsm.gov.au/sites/default/files/inline-images/Fi... [0]
The problem for us -- and likely for those in Australia now -- is that converting physical address descriptions and lat/long becomes a little more fraught. We described road restrictions as being "on the road that is found between X1,Y1 and X2,Y2." A separate layer would snap those X,Y coordinates to the road network and find the road between them. Before the move, that meant converting to "Highway 6 Southbound from milemarker 16 to milemarker 28"
But when you moved the world, X1,Y1 no longer landed on Highway 6, and instead snapped over to the frontage road. Your restriction now read as "Highway 6 Southbound, down to exit 21, around the corner to the frontage road, then down the frontage road". And your restriction that used to say "stay off this one section of road" now says "stay off the highway, the frontage road, and don't use this exit."
Most local datums are anchored to the local geology. So in the US, if you're using nad27 or nad83, the reference system is "moving" along with the continent (nad83 = North American Datum 1983), based on some weighted benchmark vectors and a lot of math. It's one reason why different datums with defined epochs exist. Some are static, but some are actually dynamic with time (eg ITRF).
But most people don't grok any of that and just stick with defaults, or guess-and-check during map setup and go with whatever looks "close enough".
In your case, chances are the map provider switched datums with the update, from nad27 to nad83, and your software wasn't told about the change. Or it was, but your road restriction data was drawn in the old projection, and not converted / transformed to the new one.
Or, you could have had data that initially was mislabeled, recorded with GPS (wgs84) and entered using one of the many datums that's similar, but not the same. Or maybe collected using one of the many state plane coordinate systems (which people tend to like because it's more or less Cartesian- east,north) which are themselves built in top of one of the datums. You can pick the right coordinate zone, but wrong underlying datum.
If any data provider or aggregator or if your company GIS guru ever selected the wrong projection (choices often are dozens of coded options that look nearly identical), or left it blank (undefined) because they weren't sure...
A instant "shift" would happen as soon as you "corrected" the error, (or upgraded software, or any other number of situations).
This is where a good GIS guru earns their keep, because conversions between projections and datums are just math, and data can often be corrected in seconds by running it through a manual "inverse" conversion, assuming one can recognize what happened.
Back to Australia: if people used GPS coordinates (wgs84) and didn't convert to a Australian centric datum (which is the default option for most collectors), the data would "stay still" while the continent moves. Which is one of many reasons why selecting an appropriate datum/ projection is so important.
For the US: While there is some intra-datum movement between nad27 and nad83, most of the differences are do to improvements in the quality and accuracy of surveys over half a century. So the differences between the two datums tend to grow as you get further from the beginning points of the surveys.
Which means some areas, like a lot of the East coast, have minimal differences, and areas out West have larger deltas, but it varies.
A couple of meters would be better explained by a bad datum transformation than by drift, which is likely an order of magnitude smaller at even the worst locations for the US.