[gdal-dev] Re: help for comparing two WKT

[Patrick Sunter]

On Mon, Oct 10, 2011 at 3:00 AM,  <gdal-dev-request at lists.osgeo.org> wrote:
> Message: 3
> Date: Sun, 9 Oct 2011 01:32:21 +0200
> From: Even Rouault <even.rouault at mines-paris.org>
> Subject: Re: [gdal-dev] Re: help for comparing two WKT
> To: Etienne Tourigny <etourigny.dev at gmail.com>
> Cc: gdal-dev at lists.osgeo.org
> Message-ID: <201110090132.21477.even.rouault at mines-paris.org>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> Le dimanche 09 octobre 2011 01:05:21, Etienne Tourigny a écrit :
>> Thanks Even
>>
>> I see what you mean, several named GEOGCS/datums can match a given
>> spheroid.
>>
>> I am trying to see if I can assign a named datum given spheroid
>> parameters from the CF Convention for the netcdf driver.
>>
>> For example, this CF definition corresponds to the WGS84 datum/GEOGCS
>>   int crs ;
>>     crs:grid_mapping_name = "latitude_longitude";
>>     crs:longitude_of_prime_meridian = 0.0 ;
>>     crs:semi_major_axis = 6378137.0 ;
>>     crs:inverse_flattening = 298.257223563 ;
>>
>> -> Are there any numerical differences between GEOGCS/datums that use
>> the same spheroid?
>> In other words, is it erroneous (numerically) to use another named
>> GEOGCS/datum than the one that was intended? (e.g. using WGS_1984
>> instead of Hartebeesthoek94).
>
> If using PROJ4 no, they will be equivalent. But if EPSG chose to make them
> different, I guess it probably means that with more precise
> modeling/transformation tools they would be different. It's somehow geodesic
> pedantry.
>
> For example, http://www.fig.net/commission5/reports/wonnacott.pdf
>
> explains how
> the Hartebeesthoek94 was built.

Yes, I think named datums imply sets of control points that can be
used for more precise datum transformations, going beyond just the
ellipsoid used, e.g. see discussions at:
http://www.unidata.ucar.edu/mailing_lists/archives/netcdf-java/2011/msg00024.html

So it doesn't seem to me that two datums that have the same spheroid,
but different names, should return True when tested with
IsSameGeogCS().

If you wanted to test the 2 Spheroids are the same, you could access
info using the OGRSpatialReference::GetAttrNode() function - e.g. path
"GEOGCS|DATUM|SPHEROID", and check the values are the same under that
node.

Also the spheroids themselves have EPSG codes (e.g. EPSG:7030 for the
spheroid used in WGS84, EPSG:7019 for GRS 80) - so maybe the right
level to target these functions is to be able to check spheroid values
and assign EPSG codes at that level?

-- Pat.

>
>>
>> -> Furthermore, is there a precedence than one must or can use in
>> order to choose which one that matches?
>> I assume that the numerical order of the EPSG codes have nothing to do
>> with precedence.
>
> I'm afraid there's no "precedence", apart from an arbitrary choice you could
> made based on what you believe to be the most "usual" / likely one.
>
> EPSG also defines a geographical zone where GEOGCS/PROJCS are valid, so that
> could perhaps be used to guess the most appropriate match when you have other
> elements (such as the bounding box of the raster that uses the SRS), but I'm
> not sure if those values are preserved in the GDAL CSV files.
>
>>
>> regards,
>> Etienne