[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OSSIM 2.2.0



Hello Bas,

I had pushed a fix to ossim on issue #114 to build ossim apps and ossim libs together. (you already knew)
The License issue #113 cannot be fixed by OTB team. It is the sole responsibility of OSSIM.
The last remaining issue of jsoncpp #115 is another interesting one to deal with.
Because it is an amalgamated source of jsoncpp[1] with some changes for and by OSSIM[2]

[1] https://github.com/ossimlabs/ossim/blob/dev/src/base/jsoncpp.cpp#L1
[2] https://github.com/ossimlabs/ossim/commits/dev/src/base/jsoncpp.cpp

I had discussed this issue in depth with OTB developer team during our last meet.  And it is not the first time OTB is fixing errors for this project.
Note that, we have a copy of ossim_plugins which cannot be merged for a long time. The problem here is we cannot keep fixing stuff for OSSIM as they keep all discussions and releases, private bug tracker far away from us.
If the project has cared a bit more about its existence in open source ecosystem, it would have been bit more interesting to us.
Before the last release, we came to know for new releases from OSSIM by looking in download.osgeo.org/ossim/
And that's just about tip of issues we had with how development activities goes in OSSIM.

So We had couple of options we like to try:
1.  Keep fixing all ossim bugs that affect us under our own project's funds.
2. Remove or make ossim dependency optional to OTB
3. Fork a lite version of ossim into Modules/otbossim/ and cut down as much as possible. (merging otbossimplugins into otbossim)
  We don't need ossim apps, geos, openthreads, (and jsoncpp) etc..

First option is what we are doing right now.

Second one is not possible for a short term.
It will either delay otb releases for a while or will keep the packaging effort as is. always and only use ossim-1.8.20-3.

With third option, there is no more dependency to OSSIM, GEOS, OpenThreads in OTB.
Infact, we keep our "lite" version of ossim under otb's namespace. The only dependency will be from geotrans library[3]
This library is currently embedded in ossim library since I can remember and we will keep this as is for now like 6S and SiftFast.

This forking effort will open doors to explore the possibility to use widely available proj4 instead of geotrans.
That will fix a 5 year blocking issue in OTB! [4]

[3] http://earth-info.nga.mil/GandG/geotrans/
[4] https://bugs.orfeo-toolbox.org/view.php?id=701

This third option will finally get to the second one. (remove dependency to ossim)

We highly appreciate the work on otb's packaging and it's contribution to the project.
But we are not expert in packaging and this the point we like to get suggestions from you and DebianGIS team.

What will be the impact on packaging work (we can help with related changes) with fork of ossim lite version into OTB sources. ?

AFAICT, It will be like an embedded copy of ossim and all development will be detached from upstream project. We only need and use
only a small part of ossim library. Everything else is out of this ossim-lite or otbossim module. If you look, its kind of what they do with jsoncpp.

For now, there is no action or ongoing work in any direction as you see no RFCs from OTB side!

Finally, I would also like to say that ossim developers are friendly when we send bug reports, or patches to OSSIM.
This was the one thing which kept going for us. But our team is getting tired on how the development activities goes in an OSGeo approved project.

--
Regards,
   Rashad

Reply to: