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).
-> 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.
regards,
Etienne
On Sat, Oct 8, 2011 at 7:56 AM, Even Rouault
<even.roua...@mines-paris.org> wrote:
> Le samedi 08 octobre 2011 07:05:31, Etienne Tourigny a écrit :
>> A related question:
>>
>> given an unnamed datum with defined spheroid, PRIMEM and UNIT values,
>> is there a way to find a corresponding named datum or EPSG code?
>>
>
> You can find a match, but there are often several possible solutions. See on
> your examples below.
>
>> I'd be interested in an existing method, or perhaps externalng code or
>> table in which I could search for common candidate DATUM definitions,
>> and compare using OGRSpatialReference::IsSameGeogCS() .
>
> One method would be to open data/gcs.csv, iterate over the GEOGCS EPSG code in
> the first column, make them expanded to full SRS by
> OGRSpatialReference::importFromEPSG(), strip the nodes you are not interested
> in for the comparisons (AUTHORITY codes), alter the DATUM/SPHEROID names to
> "unknown", and finally compare.
>
>>
>> e.g
>>
>> DATUM["unknown",
>> SPHEROID["Spheroid",6378137,298.257223563]],
>> PRIMEM["Greenwich",0],
>> UNIT["degree",0.0174532925199433]]
>>
>> corresponds to
>>
>> EPSG: 4326
>> or
>> DATUM["WGS_1984",
>> SPHEROID["WGS 84",6378137,298.257223563,
>> AUTHORITY["EPSG","7030"]],
>> AUTHORITY["EPSG","6326"]],
>> PRIMEM["Greenwich",0],
>> UNIT["degree",0.0174532925199433],
>> AUTHORITY["EPSG","4326"]]
>
> Or :
>
> GEOGCS["Hartebeesthoek94",
> DATUM["Hartebeesthoek94",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","6148"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4148"]]
>
> GEOGCS["Yemen NGN96",
> DATUM["Yemen_National_Geodetic_Network_1996",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","6163"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4163"]]
>
> GEOGCS["Korean 1995",
> DATUM["Korean_Datum_1995",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","6166"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4166"]]
>
> And other GEOGCS that are defined by "+proj=longlat +ellps=WGS84
> +towgs84=0,0,0,0,0,0,0 +no_defs" in the share/proj/epsg file.
>
>>
>> also:
>>
>> DATUM["unknown",
>> SPHEROID["Spheroid",6378137,298.2572221010002]],
>> PRIMEM["Greenwich",0],
>> UNIT["degree",0.0174532925199433]],
>>
>> corresponds to
>> EPSG:4283
>> or
>> DATUM["Geocentric_Datum_of_Australia_1994",
>> SPHEROID["GRS 1980",6378137,298.2572221010002,
>> AUTHORITY["EPSG","7019"]],
>> TOWGS84[0,0,0,0,0,0,0],
>> AUTHORITY["EPSG","6283"]],
>> PRIMEM["Greenwich",0],
>> UNIT["degree",0.0174532925199433],
>> AUTHORITY["EPSG","4283"]],
>>
>
> Or :
>
> GEOGCS["TWD97",
> DATUM["Taiwan_Datum_1997",
> SPHEROID["GRS 1980",6378137,298.257222101,
> AUTHORITY["EPSG","7019"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","1026"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","3824"]]
>
> GEOGCS["IGRS",
> DATUM["Iraqi_Geospatial_Reference_System",
> SPHEROID["GRS 1980",6378137,298.257222101,
> AUTHORITY["EPSG","7019"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","1029"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","3889"]]
>
> GEOGCS["MOLDREF99",
> DATUM["MOLDREF99",
> SPHEROID["GRS 1980",6378137,298.257222101,
> AUTHORITY["EPSG","7019"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","1032"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4023"]]
>
> GEOGCS["RGRDC 2005",
> DATUM["Reseau_Geodesique_de_la_RDC_2005",
> SPHEROID["GRS 1980",6378137,298.257222101,
> AUTHORITY["EPSG","7019"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","1033"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4046"]]
>
> GEOGCS["SREF98",
> DATUM["Serbian_Reference_Network_1998",
> SPHEROID["GRS 1980",6378137,298.257222101,
> AUTHORITY["EPSG","7019"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","1034"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4075"]]
>
>
>>
>> many thanks
>> Etienne
>>
>> On Fri, Oct 7, 2011 at 8:36 PM, Etienne Tourigny
>>
>> <etourigny....@gmail.com> wrote:
>> > Hi all,
>> >
>> > I would appreciate any hints as to how I can compare 2
>> > WKT/OGRSpatialReference objects.
>> >
>> > My goal is to make sure that a more detailed WKT (with authority codes
>> > and explicit datum) corresponds (numerically) to a simpler one, such
>> > as in the following examples.
>> >
>> > I understand that the oSRSGDAL.exportToPrettyWkt() function can remove
>> > AXIS, AUTHORITY and EXTENSION nodes, but how can I guarantee that the
>> > PARAMETER nodes are in the same order? Does FixupOrdering() solve that
>> > problem?
>> >
>> > Furthermore, How could I compare the datums?
>> >
>> >
>> >
>> >
>> > CF=[PROJCS["unnamed",
>> > GEOGCS["unknown",
>> > DATUM["unknown",
>> > SPHEROID["Spheroid",6378137,298.2572221010002]],
>> > PRIMEM["Greenwich",0],
>> > UNIT["degree",0.0174532925199433]],
>> > PROJECTION["Lambert_Conformal_Conic_2SP"],
>> > PARAMETER["standard_parallel_1",-18],
>> > PARAMETER["standard_parallel_2",-36],
>> > PARAMETER["latitude_of_origin",0],
>> > PARAMETER["central_meridian",134],
>> > PARAMETER["false_easting",0],
>> > PARAMETER["false_northing",0]]]
>> >
>> > GDAL=[PROJCS["GDA94 / Geoscience Australia Lambert",
>> > GEOGCS["GDA94",
>> > DATUM["Geocentric_Datum_of_Australia_1994",
>> > SPHEROID["GRS 1980",6378137,298.2572221010002,
>> > AUTHORITY["EPSG","7019"]],
>> > TOWGS84[0,0,0,0,0,0,0],
>> > AUTHORITY["EPSG","6283"]],
>> > PRIMEM["Greenwich",0],
>> > UNIT["degree",0.0174532925199433],
>> > AUTHORITY["EPSG","4283"]],
>> > PROJECTION["Lambert_Conformal_Conic_2SP"],
>> > PARAMETER["standard_parallel_1",-18],
>> > PARAMETER["standard_parallel_2",-36],
>> > PARAMETER["latitude_of_origin",0],
>> > PARAMETER["central_meridian",134],
>> > PARAMETER["false_easting",0],
>> > PARAMETER["false_northing",0],
>> > UNIT["metre",1,
>> > AUTHORITY["EPSG","9001"]],
>> > AUTHORITY["EPSG","3112"]]]
>> >
>> >
>> >
>> > Another option is exporting to PROJ.4 strings, but there are the
>> > +towgs84 that shows up , plus some differences in +datum vs. +ellps.
>> >
>> > e.g.
>> >
>> > CF=[+proj=utm +zone=55 +ellps=WGS84 +units=m +no_defs ]
>> > GDAL=[+proj=utm +zone=55 +datum=WGS84 +units=m +no_defs ]
>> > or
>> > CF=[+proj=lcc +lat_1=-18 +lat_2=-36 +lat_0=0 +lon_0=134 +x_0=0 +y_0=0
>> > +ellps=GRS80 +units=m +no_defs ]
>> > GDAL=[+proj=lcc +lat_1=-18 +lat_2=-36 +lat_0=0 +lon_0=134 +x_0=0
>> > +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs ]
>> >
>> >
>> >
>> > many thanks,
>> > Etienne
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
