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

[Etienne Tourigny]

On Mon, Oct 10, 2011 at 4:14 AM, Patrick Sunter <patdevelop at gmail.com> wrote:
> 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().

Ok I understand now, will close the bug I filed.

>
> 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?

Well not much added value in adding the spheroid EPSG code, so I guess
it's not worth the trouble.

This simple example

GEOGCS["unknown",
    DATUM["unknown",
        SPHEROID["Spheroid",6378140,298.257]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]]

would become

GEOGCS["unknown",
    DATUM["unknown",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]]

instead of the more complete (but possibly erroneous in terms of
precise geodesy)

GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9108"]],
    AUTHORITY["EPSG","4326"]]

Thanks to everyone for their help
Etienne
>
> -- 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>