[PROJ] Pitching the proj project to Google's Geo team

[Greg Troxel]

Cameron Shorter via PROJ <proj at lists.osgeo.org> writes:

> Hi proj folks,
> If you had one slide to pitch the proj.org project to Google's Geo team,
> with the aim of getting Google to engage in the proj project, what should
> be on that slide?

Not what you asked, but I think that EPSG:4326 is a huge problem and
needs to be fixed.  By saying "WGS84" there is a vast amount of data
labeled with an ensemble, and given the 2m fuzz, all the time-dependent
things you are complaining about are not really wrong.  Yes, they are
actually issues and I get that, but for normal people's usage, only once
you somehow define that the CRS of TMS layers is not "WGS84(ensemble)"
but some ITRF(yyyy) that is non-ancient.

The usage of WGS84/4326 for TMS (which was a bug at the time) has bled
into all sorts of things where people (who probably didn't really
understand that WGS84(TRANSIT) exists collide with other people who
think we need to treat 4326 as possibly containing TRANSIT and thus are
allowed to use null transforms for meter-level shifts) just copied the
phrase.  It shows up in geojson and as the datum of OpenStreetMap.
Because of this proj treats "NAD83(2011) epoch 2010.0" as equal to 4326;
while technically defensible in a narrow sense it is in the modern world
wrong.

Without fixing the definition of 4326 -- or fixing every standard that
refers to it -- we end up in a world where we have to all say, outside
of the specs, that 4326 doesn't really mean what it says, but means
"Assume that the data is in the most recent realization when reading,
but beware that it might be messy.  When transforming to 4326, transform
to the most recent realization.  Accept write/read operations using
different realizations as minor error sources (relative to the errors in
the data before transforming), and if you don't like that, STOP USING
4326!".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220821/e887abeb/attachment.sig>