Trouble with Average Elevation in SensorModel
Mantis Issue 360, reported by cvalladeau, assigned to abricier, created: 2011-06-27
The m_AverageElevation used to compute transform on point seems to reveal some trouble : NoData, nan() or 0?
Here the historic of mails form developpers lists :
Le 27/06/2011 09:11, Julien Michel a écrit : I agree with you, this fix will only lead to other errors, in the mean time, I do not like the idea of having ossimGpt.height not initialized (it already lead to the bug in forward model convergence), and in some cases, when passing nan() as elevation to ossim, things go wrong (like in the SPOT5 model). Do you have any advice on how to fix this properly ?
Le 25/06/2011 22:53, Emmanuel Christophe a écrit : I still disagree with this change:
- this is just hiding the problem and giving the illusion that stuff works for a test case that is chosen at a low altitude.
- the value will still be wrong for high altitude scene, but not so wrong, so it will be harder to detect.
- this is more or less equivalent to hard coding the altitude that works well for the test.
- the line "m_AverageElevation = 0; // used as a invalid value" is now obviously wrong: we don't want to use 0 as a invalid value.
On Fri, Jun 24, 2011 at 09:09, Cyrille Valladeau cyrille.valladeau@c-s.fr wrote:
Done. Feel free to improve the change.
Have a nice week end, Cyrille
Le 24/06/2011 17:42, Julien Michel a écrit :
I am not sure, but I think you should rather change it in SensorModelAdaptor ...
Julien
Le 24/06/2011 16:08, Cyrille Valladeau a écrit :
Hi,
Finally, I've changed the otbSensorModelBase::m_AvarageElevationVamue form -32768 to 0.
Cyrille
Le 23/06/2011 15:57, Cyrille Valladeau a écrit :
Nothing decided yet... Any proposition is welcome.
Cyrille
Le 23/06/2011 15:46, Julien Michel a écrit :
Any update on this issue ? SPOT5 forward model is returning Nan when SRTM == NODATA, and I feel this is somehow related ...
Regards,
Julien
Le 21/06/2011 18:29, Cyrille Valladeau a écrit :
OK. So I think that there's some confusion in the SensorModelAdaptor::InverseTransformPoint. We do
148 if (this->m_UseDEM)
149 {
150 double height = this->m_DEMHandler->GetHeightAboveMSL(lon, lat);
151 ossimGPoint.height(height);
152 }
153 else if (h != -32768)
154 {
155 ossimGPoint.height(h);
156 }
If there's no DEM and the given altitude h is at -32768, the ossimGPPoint.hgt value is not initiliazed (http://trac.osgeo.org/ossim/doxygen/ossimGpt_8h-source.html, no default value)... Maybe we should add a else { ossimGPoint.height(0); } ??
Cyrille
Le 21/06/2011 18:09, Emmanuel Christophe a écrit :
We should make sure that the value of -32768 is never passed to ossim: when we have this value, either use the 2D methods from ossim or pass it as an ossim::nan.
On Tue, Jun 21, 2011 at 07:27, Cyrille Valladeau cyrille.valladeau@c-s.fr wrote:
Hi all,
The test prTvGCPsToRPCSensorModelImageCheckInputGcpPointsProjection failed every where. I had a look and (think) found the problem. This test use the GenericRSTransform which includes an otbInverse and otbForward SensorModel to compute the transform. Those classes have 2 ways to deal with the elevation (to proceed the TransformPoint method)
- Use the DEM thaht the user has set
- Use the AverageElevation otherwise
Our problem is that the AverageElevation default value is -32768. Thus when OSSIM performs the computation of the transformed point, it happens that it can't reach a "stable" value and returns some unpredictable values. To be back to the test. If I set the AverageElevation to 0 when the user doesn't give the DEM, the test passes.
My question is the following one. Should we :
- let the things like that?
- really use the m_AverageElevation in the TransformPoint SensorModels methods?
- Add an TransformAverageElevation in the GenericRSTransform class (that will be give as AverageElevation to the SensorModels)?
- Other?
Cyrille
1309188576 - C ValladeauDo we talk about the same fix? (http://hg.orfeo-toolbox.org/OTB/rev/604ce888978d). In this lastest one, the "m_AverageElevation = 0; // used as a invalid value" was reverted...
1309197629 - christopCyrille, yes, I saw the backout after sending my mail (your original mail was pointing to the first commit).
The idea would be to carry the invalid value around OTB as much as possible. It could be a nan (but otb/itk does not handle it I think) or a specific value (-32768 is one).
To avoid funny effects, this value should not be passed to ossim. At each otb/ossim interface (easier now are they are all in the same directory), we check the value and decide what to do:
- in some cases, ossim has a 2D version of the function, without elevation, if the elevation is invalid, we use it
- otherwise, the result is likely to be wrong and we need a strong signal to the user: warning? exception? I just know that I really prefer the program to tell me right away that the result is going t