Difference between revisions of "Sensor Models Support"

From OTBWiki
Jump to: navigation, search
(Testing / Validation)
(Related Links: Updated link to OSSIM API documentation)
Line 91: Line 91:
 
*Conf Call Log: [https://docs.google.com/document/d/1gSS9dc9t_UR03lglqhZJEp9JJGtsIBuir6IkozawIk4/edit?hl=fr&pli=1 link]
 
*Conf Call Log: [https://docs.google.com/document/d/1gSS9dc9t_UR03lglqhZJEp9JJGtsIBuir6IkozawIk4/edit?hl=fr&pli=1 link]
 
*Related OTB bug report: [http://bugs.orfeo-toolbox.org/view.php?id=257 link]
 
*Related OTB bug report: [http://bugs.orfeo-toolbox.org/view.php?id=257 link]
*OSSIM doxygen: [http://173.12.67.205/osgeo/ossim/doc/html/classes.html link]
+
*OSSIM doxygen: [http://trac.osgeo.org/ossim/doxygen/classes.html link]

Revision as of 15:55, 27 August 2013

Tasks

  • Implement ossimGeometricSARSensorModel::LineSampleToWorld() using the user-provided ossimSensorModel patch: Action on Bug #257

This fix aims at providing a symmetry in forward and backward projections. The point P' projection of the point P from the referential R0 to R1 should match P when reprojected back from R1 to R0. According to the test prTvGenericRSTransformGenericConversionCheckingFromGCP, only TERRASARX and RADARSAT2 are impacted and the gain is minimal regarding the speed loss (x7 on TERRASARX 4025 GCPs). This improvement is integrated within OTB (in GeometricSARSensorModel).

  • Reimplement ImagingRay() in the class ossimGeometricSarSensorModel

Using ossimSarModel class implementation -> implement 4 methods: imagingRay(), computeOPfromImage(), getArpTime(), getArpPosition(). These methods need parameters that are not extracted in the ossimGeometricSarSensorModel (theArpXPolCoeff, theArpYPolCoeff, theArpZPolCoeff, theLsrOffset, theTimeCoeff, theOrpCenter, thePixelSpacing, theOPX, theOPY, theOrpPosition...). They are extracted in ossimSarModel. Integrating the extraction of these parameters from the keyword list was far more heavy than just implementing methods in ossimGeometricSarSensorModel. After this integration, it seems that the specific metadata still can't be accessed (Cf. Dashboard) and does not solve the issues.

  • Switch inheritance from ossimGeometricSarSensorModel to ossimSarModel

An example provided by ossim Team of RadarSat model implementation inheriting from ossimSarModel: In fact, the provided RadarSat model inherits from ossimSensorModel. The base class ossimSarModel does fit fell well with RadarSat. This refactoring should apply to each Sar models giving up the ossimSarModel inheriting solution and increasing drastically the amount of inheriting switch work.

Try to port ossimTerraSarModel to evaluate the amount of work to convert one plugin.

  • remove keyword duplication
  • convert other models

Testing / Validation

  • Model validation using GCPs:
Sensor Image > WGS84 WGS84 > Image
SAR
ENVISAT [0,0] ok
RADRASAT1 [0,0] 8/15, ok 7/15 ok
RADARSAT2 [0,0] 2/4 84px, 2/4 13000px
TERRASARX [0,0] ok (~60px, max 120px)
Optical (FYI)
SPOT5 [nan,nan] ok
FORMOSAT [nan,nan] [nan,nan]
QUICKBIRD ok ok


  • Forward Backward projection consistency:

It checks the bijectivity of the "Sensor model to WGS84" projection. -Untested sensors: SPOT4, PALSAR, CosmoSkymed, ONERA: OTB-LargeInput files don't have keyword lists GEOEYE, IKONOS, WorldView2, MODIS, RapidEye: OTB-LargeInput files are otho-ready, OTB can't handle it yet -Tested sensors: QuickBird, SPOT5, RadarSat1, RadarSat2, Formosat2, TerraSarX, ENVISAT: see Dashboard.

It seems that, form some sensors, a forward sensor model instanciated through a GenericRSTransform is not valid nevertheless it is valid when directly instanciated.

OSSIM Related Commits

Required Documents

  • Keyword list description
    • TerraSarX
    • RadarSat 1
    • Envisat Asar

Related Links

  • Dedicated Repository: link
  • Dashboard Submission: link
  • Conf Call Log: link
  • Related OTB bug report: link
  • OSSIM doxygen: link