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

[Cameron Shorter]

Thanks all for your excellent responses and suggestions.
It has been great to discover that Googler Kurt is on the proj PSC, and he
will be a better person than me to be a conduit between proj and Google,
especially at the super detailed technical level. (That will be a point on
my slide).

I'll be talking at a fairly high level discussion. Key points:
* The basemap owner sets the projection for maps based on this basemap, so
there is a duty of basemap owners to get this right. (Hint-hint Google)
* WGS84 is a poor selection for a tiled basemap + a few of the high level
reasons mentioned here and in other sources
* We need to collect epoch when capturing data when using dynamic datums
* OGC standards need to be updated as well
* ... and a bit more which I'm still working on
* This will be best solved in collaboration, and proj is one of the
communities that Google should develop a relationship with.

Feel free to continue the discussion on this thread, but note that I'll
have minimal bandwidth to incorporate further feedback.
Hopefully this presentation will lead to a broader engagement, with
some deep dive collaborative technical discussions.

Warm regards, Cameron

On Tue, Aug 23, 2022 at 7:55 PM 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/842f6615/attachment.htm>