Optimize coordinate transformations in SARSensorModel

Summary

transformation between geographical coordinates and ECEF coordinates takes a lot of time in SarSensorModel computations. In the current implementation, a transform object is created for each transformation, this is very inefficient. Instead, the same transformation object can be created at class construction and used in each transformation.

Copyright

The copyright owner is CNES and has signed the ORFEO ToolBox Contributor License Agreement.

---

Check before merging:

• All discussions are resolved
• At least 2 votes from core developers, no vote.
• The feature branch is (reasonably) up-to-date with the base branch
• Dashboard is green
• Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
• Optionally, run git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i on latest changes and commit

changed the description

changed milestone to %8.0.0

added refactoring label

assigned to @ctraizet

added 1 commit

• d3b6a6f7 - PERF: use the same transform objects for all coordinate transformation of the...

Compare with previous version

For future optimizations, it'll be nice to also have

CoordinateTransformation::Transform(std::size_t N, double /*inout*/ *x, double /*inout*/ *y, double /*inout*/ *z)
{
  assert(x);
  assert(y);
  assert(z);
  if (m_Transform->Transform(N, x, y, z) == 0) {
    std::ostringstream oss;
    oss << "(TransformFailureException) "
        << "Transform: " << this << ", "<< N << " 3D parameters";
    throw std::runtime_error(oss.str());
  }
}

// + The forward call in GeocentricTransform

// + The same forward call as SarSensorModel::EcefToWorld and SarSensorModel::WorldToEcef
// And possibly in other places.

At this point it's easier to stay low level (I've hesitated to introduce otb::Span, but we'd actually need an SOA-kind-of span for a better API) and let developers of filter/applications take care of allocating and caching a (different) temporary structure for transforming regions in one call (in each thread).

I also don't know whether it would make sense to use the other overloads that return an array of boolean flags telling us which transformations succeeded or failed.

BTW, I'm not sure that interrupting everything by throwing is the best choice if most pixels but a few could not be transformed.

added Ready for review label

mentioned in commit d29183f7

merged