Opened 13 years ago

Closed 9 years ago

#3940 closed defect (fixed)

PDS positioning and xy sign issues.

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: PDS
Cc: thare

Description

PDS has many registration issues across the different releases. Thus not only are there 0.5 to 1.5 pixel shifts, there are even projection offset that are wrongly negated. To mitigate this "-co" options need to be defined for PDS to allow a user to override the defaults. Please change as you see fit (e.g. like if -co options are too long).

~line 290-300, overwrite whole comment section and sections:

    /***********   Grab LINE_PROJECTION_OFFSET ************/
    /***********   Grab SAMPLE_PROJECTION_OFFSET ************/

//-----------------New code to overwrite (untested) -----

    // Calculate upper left corner of pixel in meters from the upper left center pixel sample/line offsets.
    // It doesn't mean the defaults will work for every PDS image, as these values are used inconsistantly.
    // Thus we have included conversion options to allow the user to override the documented PDS3 default.
    // Jan. 2011, for known mapping issues see GDAL PDS page or mapping within ISIS3 source (USGS)
    // $ISIS3DATA/base/translations/pdsProjectionLineSampToXY.def
   
    // defaults should be correct for what is documented in the PDS3 standard
    double   dfSampleOffset_Shift = -0.5;
    double   dfLineOffset_Shift = -0.5;
    double   dfSampleOffset_Mult = -1.0;
    double   dfLineOffset_Mult = 1.0;

    if( CSLFetchNameValue(papszOptions,"SampleProjOffset_Shift") != NULL )
    {
        dfSampleOffset_Shift = atof(CSLFetchNameValue(papszOptions,"SampleProjOffset_Shift"));
    }
    if( CSLFetchNameValue(papszOptions,"LineProjOffset_Shift") != NULL )
    {
        dfLineOffset_Shift = atof(CSLFetchNameValue(papszOptions,"LineProjOffset_Shift"));
    }
    if( CSLFetchNameValue(papszOptions,"SampleProjOffset_Mult") != NULL )
    {
        dfSampleOffset_Mult = atof(CSLFetchNameValue(papszOptions,"SampleProjOffset_Mult"));
    }
    if( CSLFetchNameValue(papszOptions,"LineProjOffset_Mult") != NULL )
    {
        dfLineOffset_Mult = atof(CSLFetchNameValue(papszOptions,"LineProjOffset_Mult"));
    }

    /***********   Grab LINE_PROJECTION_OFFSET ************/
    value = GetKeyword("IMAGE_MAP_PROJECTION.LINE_PROJECTION_OFFSET");
    if (strlen(value) > 0) {
        yulcenter = (float) atof(value);
        dfULYMap = ((yulcenter + dfLineOffset_Shift) * -dfYDim * dfLineOffset_Mult);
        //notice dfYDim is negative here which is why it is again negated here
    }
    /***********   Grab SAMPLE_PROJECTION_OFFSET ************/
    value = GetKeyword("IMAGE_MAP_PROJECTION.SAMPLE_PROJECTION_OFFSET");
    if( strlen(value) > 0 ) {
        xulcenter = (float) atof(value);
        dfULXMap = ((xulcenter + dfSampleOffset_Shift) * dfXDim * dfSampleOffset_Mult);
    }

For my notes - known PDS line/sample offset oddities

from: $ISIS3DATA/base/translations/pdsProjectionLineSampToXY.def

Object = ProjectionOffsetMults
  #  MAGELLAN - MIDR
  #  Magellan MIDR file labels were converted from VICAR labels to PDS
  #   labels, and in this conversion the sample/line offsets were rounded
  #   to whole numbers; subpixel accuracy was lost. Because of this, we'll
  #   never exactly match the latitude/longitude but we can be close.
  Group = Selection
    Keyword = "DATA_SET_ID"
    Pattern = "MGN-V-RDRS-5-MIDR"
    xMult   = -1.0
    yMult   = 1.0
    xOff    = -0.5
    yOff    = 1.0
  End_Group

 

  # VIKING ORBITER
  Group = Selection
    Keyword = "DATA_SET_ID"
    Pattern = "VO1/VO2-M-VIS-5-DIM-V1.0"
    xMult = -1.0
    yMult =  1.0
    xOff = -1.0
    yOff = -1.0
  End_Group

 

  #  MAGELLAN - FMAP
  Group = Selection
    Keyword = "DATA_SET_ID"
    Pattern = "MGN-V-RDRS-5-DIM"
    xMult   = 1.0
    yMult   = -1.0
    xOff    = 1.5
    yOff    = 1.5
  End_Group

 

  #  CASSINI RADAR
  Group = Selection
    Keyword = "DATA_SET_ID"
    Pattern = "CO-SSA-RADAR"
    xMult   = -1.0
    yMult   = 1.0
    xOff    = 0.5
    yOff    = 0.5
  End_Group

 

  #  KAGUYA TERRAIN CAMERA
  Group = Selection
    Keyword = "DATA_SET_ID"
    Pattern = "TC_MAP"
    xMult   = 1.0
    yMult   = 1.0
    xOff    = -0.5
    yOff    = -0.5
  End_Group

 

  #  STANDARD PDS
  #  Should always be last
  Group = Selection
    Keyword = "PDS_VERSION_ID"
    Pattern = "PDS3"
    xMult   = -1.0
    yMult   = 1.0
    xOff    = -0.5
    yOff    = -0.5
  End_Group
End_Object

from: http://pds.nasa.gov/documents/psdd/PSDDmain_1r71.pdf (check!)

LINE PROJECTION OFFSET REAL <pixel> The line projection offset element provides the line offset value of the map projection origin position from the line and sample 1,1 (line and sample 1,1 is considered the upper left corner of the digital array). Note: that the positive direction is to the right and down.

SAMPLE PROJECTION OFFSET REAL <pixel> The sample projection offset element provides the sample offset value of the map projection origin position from line and sample 1,1 (line and sample 1,1 is considered the upper left corner of the digital array). Note: that the positive direction is to the right and down.

Change History (4)

comment:1 by warmerdam, 13 years ago

Status: newassigned

For reference, the pdsdataset.cpp code treats LINE_PROJECTION_OFFSET and SAMPLE_PROJECTION_OFFSET as the *center* of the top left pixel. Reviewing the PDS specification it seems unclear whether it is intended to be the center of the top left pixel or the top left corner of the top left pixel.

The parameters suggested cannot be -co (creation options). They most likely would be handled as configuration option (ie. --config on the commandline), and should be named in a way that makes them clearly PDS related and perhaps somewhat briefly. Alternatively we could just provide a similar mechanism as gdal_translate parameters that could be applied to any sort of dataset, not just PDS.

comment:2 by warmerdam, 13 years ago

I have applied a modest variation on this patch using config options with a PDS_ prefix to apply offset and sign changes in trunk (r21616). The test suite entry gives a sense of how it would be used.

I can't help but think it would be better to have the special values applied automatically based on recognising the product using the pdsProjectionLineSampToXY.def file. It could either be done with the .def file in it's current file, or altering it to be a .csv file. In either case it could live in the gdal/data directory. Is this desirable? I also notice that we don't actually have any user docs for the PDS, ISIS2 or ISIS3 docs.

Leaving ticket open to resolve these issues.

comment:3 by warmerdam, 13 years ago

Correction, the changes are actually r21617 in trunk.

comment:4 by Jukka Rahkonen, 9 years ago

Resolution: fixed
Status: assignedclosed

I would say that it would be better to open new specific tickets about the issues that Frank lists than keeping this ticket open forever. Closing as fixed 4 years ago with r21617.

Note: See TracTickets for help on using tickets.