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

[Richard Greenwood]

Hi Cameron,

l don't know how many sentences fit on a slide but I would say that the
EPSG system no longer meets current Geo location needs. It was developed
when coordinate systems were primarily regional and plate based. Coordinate
positions are now geocentric, yet most of us still live on one plate or
another. Someone (maybe Google) needs to develop an unambiguous system to
tie geocentric positions to the plates over time to address the half meter
of error that accumulates every decade.

On Tue, Aug 23, 2022, 11:55 AM Martin Desruisseaux <
martin.desruisseaux at geomatys.com> wrote:

> Le 22/08/2022 à 19:32, Greg Troxel a écrit :
>
> In those cases, the worst thing would be to /pretend/ that we have a CRS
> of some specific realization while actually the software has no idea. We
> need a way to said "we don't know what is the realization because the
> producer did not tell us, expect a 2 meters uncertainty".
>
> I don't think it's the worst thing. Assuming NAD27 would be worse. And: if
> somebody claims to have data in 4326 but when you ask them "but really what
> is it" and they have no idea, would you believe them?
>
> Right, I restricted the scope of the discussion to WGS84 for simplicity.
> But for a larger scope, previous versions of EPSG database had the
> following CRS (there is 42 such definitions, I list only a few of them):
>
> 4035    Unknown datum based upon the Authalic Sphere
> 4047    Unspecified datum based upon the GRS 1980 Authalic Sphere
> 4019    Unknown datum based upon the GRS 1980 ellipsoid
> 4043    Unknown datum based upon the WGS 72 ellipsoid
>
> So we had the possibility to specify what we know with some granularity:
> "I don't know the CRS but I think it is some sphere" (a reasonable
> assumption when dealing with numerical models in oceanography). Or "I only
> know that the sphere is based on GRS 1980", etc. Recent versions of EPSG
> database have deprecated those codes with the message "No longer supported
> by EPSG because datum information is required for unambiguous spatial
> referencing", so those CRS are no longer visible on https://epsg.org. As
> said in my previous email, I agree with the stated reason for data
> producers, but it leaves data users with no way to said that the CRS is not
> well known. On my side, I continue to use EPSG:4047 for CRS read from
> CF-conventions (datum is rarely specified in that format) until I find a
> better alternative. For unspecified datum, I assume an uncertainty of 3 km
> (the highest error I have seen so far when ignoring datum shifts, in
> Reunion Island).
>
>
> (…snip…) After some thought, I'd like to restate it. When dealing with
> source data in 4326: increase the formal error of the result by 2m, to
> account for the possibility of treating data that is actually TRANSIT as
> G2139 treat the CRS as if it were the latest realization When dealing with
> a target CRS of 4326 transform to the latest realization don't do anything
> about error, because it's totally legit to treat G2139 data as being of the
> ensemble, and everyone else will add 2m of error when they take it out of
> the ensemble.
>
> It looks reasonable. Treating EPSG:4326 as a recent realization is
> arbitrary, but not wrong if the uncertainty is increased sufficiently.
> Whether the arbitrary part of this approach (EPSG:4326 as a recent
> realization) would be best for the majority, I have no answer to that
> question.
>
>     Martin
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220823/c846a063/attachment-0001.htm>