Skip to content

Pledge for OTB 7.0

Introduction

For a few weeks now we start seeing issues and merge requests with milestone 7.0. This issue is a story aiming at providing a single place discuss everything that we did / want to do in the scope of 7.0. I will start with my own wishes and be a bit radical on purpose. Feel free to enhance or correct this proposal if needed.

A note on the method

For numerous reasons, we are already out of our fixed release schedule (every months). Depending on how this issue will end, we will likely be months away from OTB 7.0, so what do we do in the mean time?

  • Maintain a bugfix 6.6 branch and develop is preparing the 7.0
  • Keep develop as the integration branch for 6.x and start a 7.0 branch that will be moved to develop when ready

Either way, we need to communicate with contributors and users about that.

Another important point is how much we allow ourselves to break things. According to our standard, any API changes needs to be warned in the current release before being applied in the next major release. I feel that this is too restricive for 7.0 (hence the importance of keeping 6.6 bugfix releases up).

Scope of OTB 7.0

I think the main focus of OTB 7.0 should be to loose weight (less code, less build time, less testing time) while getting the important things up to a target standard (same amount of important features, more documentation, more coverage).

Remove OSSIM

This is the first item that comes to my mind, and it is already descrived there : #1506 (closed) Work already started, see !221 (merged) and !224 (merged)

Remove deprecated code and applications

Even when we deprecate code, we seldom remove it, now is the time! Visit issue #1682 (closed) (maybe we should start a dedicated issue for that, and keep #1682 (closed) for listing changes that need to be documented).

Remove even more code (instead of deprecating it)

There are proposal to deprecate some code :

Additionnaly, I think we could remove:

  • All the *TileMap* code. Gdal already handles this, so we support those online data without this code
  • OrthoRectificationImageFilter. Not even used in OrthoRectificationApplication!
  • Core/CommandLineParser. Really?
  • Core/SpatialObjects We already have OGR for that
  • Filtering/Path To be checked piece by piece to see if it is really useful (might be used by some deleted or moved out code)

And there are also thing that were not in ITK back when they were developed and that are now available (help needed to extend the list):

  • Convolution in space and fourier domain (TBC)

Move some modules out of OTB

Some of the OTB modules are barely used, poorly validated, and/or really specific. Why not moving them out as remote modules ? Good candidates :

  • OBIA/RCC8 (cmon, this is my internship code back in 2006, I doubt anyone used it since then!)
  • Registration/DisplacementField (more a proof of concept than anything else)
  • Feature/SeamCarving (any practical application of this in remote sensing ?)
  • Detection/ObjectDetection Code for an old object detection IGARSS publication. Not even deep.
  • Detection/UrbanArea I think this is the code of another IGARSS pub. Not sure it even works.
  • Detection/RoadExtraction Another IGARSS publication code. Not used I think.
  • Detection/CloudDetection Any inputs on this one?
  • Learning/Markov Could be useful, but poorly known or used as of today
  • Radiometry/Simulation interesting but is it really useful to the main OTB audience?

After discussion we can switch some of them to the previous category (simply remove them).

Refactor base classes

  • Rewrite all the otbFunctorFilter to the least possible number of classes (we have 14 different). It is most certainly possible to offer the same feature with a smaller, better documented code (do not forget to have a look into modern ITK and C++)
  • Rewrite the radiometric indices classes. Design is almost an anti-pattern.
  • Rewrite all filters based on VectorData to remove VectorData classes completely

Stop supporting old stuff

Refactor testing

Less data, less IO, more unit testing. To be developed.

Edited by Julien Michel