Pledge for OTB 7.0
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 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 :
- #1692 (closed) (mapnick module)
- #1690 (closed) (online data) I would suggest that we remove them directly instead of deprecating.
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
Core/SpatialObjectsWe already have OGR for that
Filtering/PathTo 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/ObjectDetectionCode for an old object detection IGARSS publication. Not even deep.
Detection/UrbanAreaI think this is the code of another IGARSS pub. Not sure it even works.
Detection/RoadExtractionAnother IGARSS publication code. Not used I think.
Detection/CloudDetectionAny inputs on this one?
Learning/MarkovCould be useful, but poorly known or used as of today
Radiometry/Simulationinteresting 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
- Drop support of python2 #1715 (closed)
- Drop support of gdal <= 2.0
Less data, less IO, more unit testing. To be developed.