[gdal-dev] Use of sexagesimal "pseudo format" in pcs.csv?

[Even Rouault]

Le mardi 26 avril 2016 20:23:28, Jim Lacy a écrit :
> All-
> 
> This morning I was confused by the formatting of lat/lon parameters used in
> the GDAL pcs.csv file.  I initially thought the lat/lon values in the file
> are standard decimal degrees, until I realized some things weren't adding
> up.  After digging, I learned those params use a "pseudo format"
> (EPSG:9110).  i.e., 45.50 = 45 degrees, 50 minutes *NOT* 45 degrees 30
> minutes.
> 
> By comparison, the "epsg" file in PROJ.4 stores lat/lon parameters as
> decimal degrees.
> 
> I'm sure it's been this way for many years. There must be a reason?  Seems
> like it must lead to a lot of confusion.

Jim,

I wasn't even aware of that. I see this comes directly from the EPSG database 
itself :

INSERT INTO epsg_alias VALUES ( 390, 
'Unit of Measure', 
9110, 
7302, 
'DDD.MMSSsss', 
'' ); 

INSERT INTO epsg_unitofmeasure VALUES ( 9110, 
'sexagesimal DMS', 
'angle', 
9102, 
Null, 
Null, 
'Pseudo unit. Format: signed degrees - period - minutes (2 digits) - integer 
seconds (2 digits) - fraction of seconds (any precision). Must include leading 
zero in
 minutes and seconds and exclude decimal point for seconds. Convert to degree 
using formula.', 
'OGP', 
'IOGP', 
'2015-11-25', 
'2002.270 2002.780 2008.020 2015.062', 
0 ); 

What is particularly bad taste is to store such parameters as numeric values 
and not a string literals in the parameter_value column of  the 
epsg_coordoperationparamvalue table

CREATE TABLE epsg_coordoperationparamvalue ( 
coord_op_code                                      INTEGER NOT NULL, 
coord_op_method_code                               INTEGER NOT NULL, 
parameter_code                                     INTEGER NOT NULL, 
parameter_value                                    DOUBLE PRECISION, 
param_value_file_ref                               VARCHAR(300), 
uom_code                                           INTEGER, 
 );

INSERT INTO epsg_coordoperationparamvalue VALUES ( 1258, 
9601, 
8602, 
-74.04513, 
'', 
9110 ); 

GDAL's pcs.csv is a join of the original EPSG tables, so it doesn't change the 
format at that point. It however processes it to decimal degrees on reading, 
which explains why proj.4 epsg file is more reasonable.

Bottom line: better use GDAL importFromEPSG than raw parsing in its CSV files.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com