[OSM-talk] What does WGS84 mean for openstreetmap these days?

[Simon Poole]

Thus is a slightly tricky subject and it is not going away.

For another aspect of it see
https://www.openstreetmap.org/user/StephaneP/diary/390290

Essentially in some cases we are using imagery that isn't actually using
WGS84 as if it was (fsvo of WGS84 as you correctly point out) and we
currently don't actually have a way to correct this . And yes while
continental shift is for most countries smaller than all the other ones
when adding geometry, for Australia this not necessarily true.

Simon

Am 19.12.2019 um 15:33 schrieb Greg Troxel:
> (This is a long and complicated subject and I am intentionally asking
> only part of the question.)
>
> It's been said from the beginning that coordinates in the openstreetmap
> datbase are in "WGS84".  That more or less meant "what a GPS receiver
> showed", back in the days when GPS was the GNSS system of choice and
> accuracies were low compared to talking about versions of WGS84.
>
> In discussion on the proj list, it seems the consensus view is that
> WGS84 is now a term that refers to any one of the 6 realizations of
> WGS84 over time.  This makes sense when you have data that is merely
> labeled WGS84, without a more specific label such as WGS84(G1762).  This
> means that WGS84 is considered low accuracy (because the original was),
> and thus any transforms involving it are assigned high error values.
>
> This page has a good overview of the various WGS84 realizations and
> their relationship to ITRF realizations:
>
>   https://www.e-education.psu.edu/geog862/node/1804
>
>
> As normal people (or at least normal nerds) get access to more accurate
> positions, this question begins to matter, as in North America positions
> in original WGS84 and modern WGS84 differ by more than a meter.
>
> I should note that now that WGS84 has converged to ITRF, and new ITRF
> realizations seem to be at most cm-level changes from previous ones, I
> do not expect future WGS84 revisions to be signficantly different from
> either the current one.
>
> So, I wonder if we want to change the definition for OSM coordinates
> from "WGS84" to "the realization of WGS84 currently in use by GPS".
> That doesn't change older coordindates (and I am not suggesting any
> automated changes!!!).  But it does give a notion of what coordinates
> should be, both in using them and in producing new ones for editing.  I
> expect that this will have zero practical effect for most people, but
> will allow higher accuracy for those who are into extreme accuracy.
>
>
> postscript:
>
> I am intentionally leaving out of this discussion two more issues (which
> could result in further changes, with much more complexity).  I list
> them so that those with some background in geodesy can begin to ponder,
> and to explain that my stopping at the proposal above was intentional.
>
> 1) WGS84 is a US datum.  BEIDOU, GALILEO, GLONASS use different datums.
>    SBAS systems also use different datums -- WAAS seems to give
>    coordinates in "ITRF2000 (current epoch)".  It seems most are
>    equivalent to some modern ITRF, with possibly differing epochs.
>
> (I will assume for point 2 that there OSM redefines coordinates to be a
> particular ITRF at a particular epoch, probably matching the current
> WGS84.)
>
> 2) ITRF is global, but objects we map are generally crust-fixed on some
> plate.  The US has a (mostly, if you're not in CA) crust-fixed datum,
> NAD83, and other countries do too.  This is particularly acute in
> Australia which is a notably fast-moving country :-) The modern trend is
> for stations to have velocities and not just coordinates.  Over 20
> years, this starts to matter.  Several countries are introducing new
> national datums that are intended to address some of these issues.  I
> don't think it makes sense for OSM to deal with this issue for a few
> years.
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20191219/7d0dbc10/attachment.sig>