Opened 10 years ago

Closed 10 years ago

#4922 closed defect (fixed)

Problem with Vertical CS and OGR

Reported by: murphke1 Owned by: Even Rouault
Priority: normal Milestone: 1.10.0
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: gtiff vertcs
Cc:

Description

So I'm getting garbage WKT whenever I have source data with a Vertical CS tag for which the value is also a meaningful Projective CS tag. Example is 5171 - EGM 96. This is also Projective CS "Tokyo 1892 / Korea East Belt". So when "gt_wkt_srs.cpp" calls this: "if( oVertSRS.importFromEPSG( verticalCSType ) == OGRERR_NONE )"

ogr_fromespg.cpp gets a hit with this:

"SetEPSGProjCS( this, nCode );"

without ever trying this:

"SetEPSGVertCS( this, nCode )"

The end result is that the returned Vertical Datum info is dreck. Based upon the setup of the "importFromEPSG" function this will happen any time the Vertical CS tag value is also a valid ProjCS tag value.

I don't see an easy workaround here short of eliminating the conflicting lines in pcs.csv - since EGM96 support is more important to me than Tokyo 1892. But it seems to me that importFromEPSG code ought to be able to accept "hints" so that gt_wkt_srs could explicitly tell it to look for matches in Vertical CS first.

Change History (11)

comment:1 by Even Rouault, 10 years ago

Owner: changed from warmerdam to Even Rouault
Status: newassigned

comment:2 by murphke1, 10 years ago

I'm also not positive its not a problem with the source data - i.e. the Vertical CS should be 5773 rather than 5171. But as this data comes from...a very large US data source... it might need to be handled as a special case if its not explicitly correct.

comment:3 by Even Rouault, 10 years ago

Hum, I had started looking at this, and also observed that 5171 is not in vertcs.csv, so there's perhaps no need for changing the order of lookups.

Could you attach, or provide a link to, a sample file that illustrates the issue ?

comment:4 by murphke1, 10 years ago

I don't think I'm allowed to distribute it. Buts its basically a large set of GEOTIFF DEMs with the VerticalCS set to 5171, which is intended to be EGM96. In vertcs.csv you can see the EGM96 is listed as having a VertCS code of 5773 and a Datum code of 5171. So it looks to me like another case of someone confusing Vertical Datum codes and Vertical CS codes.

So my question then is, do I have to add another special case handler to gt_wkt_srs to account for this, or is the a better way to override this by manipulating the CSV files or something?

comment:5 by Even Rouault, 10 years ago

murphke1, the output of listgeo would be a good start. If it is really such a large data source, then I think that it would be possible to add a special hack in gt_wkt_srs.cpp to workaround the issue. As you seem to have some programming knowledge, perhaps you can provide a patch ?

comment:6 by murphke1, 10 years ago

I'm testing out a patch now, and I'm pretty sure it will work for my purposes. I'll let you know if it does. The question there is more "will my patch screw up anybody else"?

I'm just adding the following, as it appears to stem from the same class of data error:

if( verticalCSType == 5171) {

verticalCSType = 5773; verticalDatum = 5171;

}

In gt_wkt_srs.cpp after the current lines:

/* -------------------------------------------------------------------- */ /* The original geotiff specification appears to have */ /* misconstrued the EPSG codes 5101 to 5106 to be vertical */ /* coordinate system codes, when in fact they are vertical */ /* datum codes. So if these are found in the */ /* VerticalCSTypeGeoKey move them to the VerticalDatumGeoKey */ /* and insert the "normal" corresponding VerticalCSTypeGeoKey */ /* value. */ /* -------------------------------------------------------------------- */

if( (verticalCSType >= 5101 && verticalCSType <= 5112)

&& verticalDatum == -1 )

{

verticalDatum = verticalCSType; verticalCSType = verticalDatum + 600;

}

comment:7 by Even Rouault, 10 years ago

I don't see what it could break, since 5171 is a PROJCS not a VERTCS. So the patch looks good to me if you confirm it works. Perhaps add a few comments before to give the context of the hack.

comment:8 by murphke1, 10 years ago

It does seem to have fixed things for me. What is the procedure for submitting code changes?

comment:9 by Even Rouault, 10 years ago

Just attach to the ticket the output of svn diff.

comment:10 by murphke1, 10 years ago

--- C:/DOCUME~1/MURPHKE1/LOCALS~1/Temp/gt_wk-revBASE.svn000.tmp.cpp Thu Oct 11 16:57:06 2012 +++ C:/Development/gdal/frmts/gtiff/gt_wkt_srs.cpp Mon Dec 10 15:36:33 2012 @@ -891,6 +891,16 @@

}

/* -------------------------------------------------------------------- */

+/* This addresses another case where the EGM96 Vertical Datum code +/* is mis-used as a Vertical CS code */ +/* -------------------------------------------------------------------- */ + if( verticalCSType == 5171 ) + { + verticalDatum = 5171; + verticalCSType = 5773; + } + +/* -------------------------------------------------------------------- */

/* Somewhat similarly, codes 5001 to 5033 were treated as */ /* vertical coordinate systems based on ellipsoidal heights. */ /* We use the corresponding 2d geodetic datum as the vertical */

comment:11 by Even Rouault, 10 years ago

Component: defaultGDAL_Raster
Keywords: gtiff vertcs added
Milestone: 1.10.0
Resolution: fixed
Status: assignedclosed

Applied in trunk in r25299

Note: See TracTickets for help on using tickets.