[Talk-us-massachusetts] Braintree buildings+(Datum shift)

Tue Dec 31 03:37:39 UTC 2019

Hi, Greg,

As you note, NAD83 and WGS84 are two different models of the Earth. I’ll elaborate from what I know.

NAD83 is based on a spheroid that fits North America well. WGS84 is based on a spheroid that fits the Earth’s geoid, a gravitational equipotential, basically the average sea level. My understanding is that because there is a degree of freedom in choosing these, WGS84 was designed to match well in North America. But that meant they did not match that well in most of the rest of the world, and could be a couple of meters off.

My understanding, again, is that there was never an established transformation between the two. Because of this and the above, even ArcGIS doesn’t attempt to automatically transform between them (it only does that for NAD27 ⇒ NAD83, because the National Geodetic Survey established that transformation). But it lets you choose from several ways to transform them, by shifting the center and/or tilting the axis. What’s best depends on where you’re working and the level of accuracy you need.

In any case, this is all going to change in a few years, as NGS is going to replace NAD83 in 2022 with a new standard that’s more similar to WGS84:

	https://www.ngs.noaa.gov/datums/newdatums/

“The new reference frames will rely primarily on Global Navigation Satellite Systems (GNSS), such as the Global Positioning System (GPS), as well as on a gravimetric geoid model resulting from our Gravity for the Redefinition of the American Vertical Datum (GRAV-D) Project.”

Upshot is that the new “International GNSS Service (IGS) frame” will provide a basis for “four plate-fixed terrestrial reference frames” where the US has territory:

	• North American Terrestrial Reference Frame of 2022 (NATRF2022)
	• Pacific Terrestrial Reference Frame of 2022 (PATRF2022)
	• Mariana Terrestrial Reference Frame of 2022 (MATRF2022)
	• Caribbean Terrestrial Reference Frame of 2022 (CATRF2022)

“Each of the four frames will be identical to the latest IGS reference frame (as available in 2022) at an epoch to be determined.”

By “epoch”, they mean every measurement will be defined by a particular date at which a relation is established. Astronomers have been doing this for decades for astronomical coordinates (right ascension and declination), which change regularly due to the precession of the Earth’s axis.

P.S. It’s not just tectonic motion:

	https://www.nasa.gov/topics/earth/features/japanquake/earth20110314.html

How do we measure these changes? Of course, by reference to the never-changing celestial sphere :-)

— Andy

> On Dec 30, 2019, at 9:14 PM, Greg Troxel <gdt at lexort.com> wrote:
> 
> "Wayne Emerson, Jr. via Talk-us-massachusetts"
> <talk-us-massachusetts at openstreetmap.org> writes:
> 
>> I first noticed this shift about a year ago when the iD editor
>> software switched to using a different TMS server for the L3 parcel
>> map. I later saw this email talked about the change of tile servers:
> 
> I saw this too in josm.
> 
>> https://lists.openstreetmap.org/pipermail/talk-us-massachusetts/2018-November/000424.html
>> 
>> At the time I was not subscribed to this list so I posted about it here:
>> 
>> https://forum.openstreetmap.org/viewtopic.php?id=64699
>> 
>> Not sure if my conclusions there were correct however.
> 
> I think you got it right but missing some signficant
> complications.
> 
>> I had assumed that the downloadable files from MassGIS stayed fixed at
>> the original datum, while the TMS applied some sort of techtonic plate
>> movement based correction. The yearly divergence rate noted in my
>> forum post is not big enough to account for the difference we see
>> today, and may be partly due to the initial error in the original
>> datum. Probably only MassGIS would know the source(s) of the
>> difference.
> 
> (I don't see this notion or yearly divergence in the forum post.)
> 
> 
> This is a really complicated subject, and I'll try to summarize without
> being inaccurate.
> 
> Complication 1:
> 
>  Both NAD83 and WGS84 have had multiple realizations over the years,
>  and those realizations are increasingly accurate.
> 
> Complication 2:
> 
>  Even coordinates of stations on our plate in NAD83 change over time.
> 
> The current version of NAD83 is called NAD83(2011).  More or less, the
> intent is that points that are fixed to the crust on the North American
> Plate (all of Mass, and most of the continental US/Canada -- except some
> bits of the west coast) are intended to have stable coordinates.  If you
> look closely, I think stations will have velocities in NAD83(2011) that
> are about 2 mm/year.
> 
> The current version of WGS84 is WGS84(G1762), which is basically the
> same as ITRF2008.  This intends to more or less have station coordinates
> be stable, but in an average global way rather than a plate-fixed way.
> In New England, the same stations that move 2 mm/year in NAD83(2011)
> have velocities of maybe 15 mm/year.
> 
> Complication 3:
> 
>  WGS84 is a name for a group of datums, and when it is said unqualified
>  like that, there is uncertainty at the 2m level because you don't know
>  which version of WGS84 was used.  (This is also true for NAD83, but
>  less so.)  This causes programs asked to transform from NAD83 to WGS84
>  to say "they are the same, to within the fuzz they already each have".
>  But if you ask to transform from NAD83(2011) to WGS84(G1762), they are
>  not the same.
> 
> Complication 4:
> 
>  (slightly unsure here) TMS is defined in terms of "web mercator" which
>  ia defined to be "WGS84" which leads to uncertainty.  I think that
>  "obviously" TMS should be viewed as being WGS84(G1762) today.  But I
>  suspect that if you got a bunch of open-source geodesy types together,
>  that would be a heated argument.
> 
> The whole notion of worrying about this difference is relatively modern;
> in the 80s and early 90s NAD83 and WGS84 were usually treated as
> equivalent.
> 
> So this leads to questions:
> 
>  When MassGIS publishes data and says it is in "NAD83", which
>  realization do they mean?
> 
>  (When MassGIS offers to convert to "WGS84" when downloading from
>  OLIVER, which realization do they mean, and how do they convert?)
> 
>  When the old L3 tiles were created, how was the data obtained and
>  transformed?
> 
>  What datum is the current L3 parcels TMS in?  Did MassGIS transform
>  from NAD83(?) to WGS84(G1762)?  Or just assume equivalence?
> 
> 
> I have a contact at MassGIS and am going to ask about this, once I
> figure out as much as I can myself.
> 
> 
>>> (I see what you mean about Braintree.)
>> 
>> Looks like mainly north half of Braintree is a mess. These imports
>> were done by crschmidt in January 2009.
> 
> That's the super early batch, and I'm not surprised.  crschmidt is no
> longer active, but he imported (back in the days before people got upset
> about imports) a ton of MassGIS data which had the really great effect
> of MA not getting Tiger.  Some of the data is a little wonky (these
> buildings apparently, and the open space layer), but mostly I think it's
> been very positive.
> 
> I started working on OSM just after that import, after a friend pointed
> it out to me.  Before that, OSM didn't seem clearly viable and
> afterwards it was amazing.
> 
>> These are some of the changesets I found on bad Braintree buildings
>> but It looks like the changesets cover huge areas:
>> 
>> https://www.openstreetmap.org/changeset/727079
>> 
>> https://www.openstreetmap.org/changeset/743822
>> <https://www.openstreetmap.org/changeset/727079>
>> 
>> https://www.openstreetmap.org/changeset/743003
>> <https://www.openstreetmap.org/changeset/727079>
>> 
>> The later imports done in 2013 look good.
> 
> Those are the ones led by Jason (who did most of the data transformation
> work, with shared QA), and we were very careful.  I'm glad those are ok.
> 
> _______________________________________________
> Talk-us-massachusetts mailing list
> Talk-us-massachusetts at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us-massachusetts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstreetmap.org/pipermail/talk-us-massachusetts/attachments/20191230/000a4128/attachment.sig>