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

[Martin Desruisseaux]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220823/27aee3f4/attachment.htm>