<div dir="ltr"><div dir="ltr">Thanks all for your excellent responses and suggestions.<div>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).</div><div><br></div><div>I'll be talking at a fairly high level discussion. Key points:</div><div>* 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)</div><div>* WGS84 is a poor selection for a tiled basemap + a few of the high level reasons mentioned here and in other sources</div><div>* We need to collect epoch when capturing data when using dynamic datums</div><div>* OGC standards need to be updated as well</div><div>* ... and a bit more which I'm still working on</div><div>* This will be best solved in collaboration, and proj is one of the communities that Google should develop a relationship with.</div><div><br><div>Feel free to continue the discussion on this thread, but note that I'll have minimal bandwidth to incorporate further feedback.</div><div>Hopefully this presentation will lead to a broader engagement, with some deep dive collaborative technical discussions. <br><div><br></div></div></div><div>Warm regards, Cameron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 23, 2022 at 7:55 PM Martin Desruisseaux <<a href="mailto:martin.desruisseaux@geomatys.com">martin.desruisseaux@geomatys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<p>Le 22/08/2022 à 19:32, Greg Troxel a écrit :</p>
</div>
<blockquote type="cite">
<blockquote type="cite">
<p>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".
</p>
</blockquote>
<p>
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?</p>
</blockquote>
<p align="justify">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):</p>
<blockquote>
<p>4035 Unknown datum based upon the Authalic Sphere<br>
4047 Unspecified datum based upon the GRS 1980 Authalic
Sphere<br>
4019 Unknown datum based upon the GRS 1980 ellipsoid<br>
4043 Unknown datum based upon the WGS 72 ellipsoid<br>
</p>
</blockquote>
<p align="justify">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
<a href="https://epsg.org" target="_blank">https://epsg.org</a>. 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).<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<p>(…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.</p>
</blockquote>
<p align="justify">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.</p>
<p align="justify"> Martin</p>
<p align="justify"><br>
</p>
</div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div></div>