Re: OSSIM 2.2.0
On September 11, 2017 11:27:38 AM GMT+02:00, Rashad Kanavath <mohammedrashadkm@gmail.com> wrote:
>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. ?
The impact of the embedded copy of the ossim fork should be quite small, especially when the sources are stripped down to the bare necessities for OTB (and uses a different SONAME). It makes the fate of the otb package independent of the ossim package, and that's a good thing in the light of the concerns raised in this thread.
Embedded copies are generally frowned upon in Debian. But in this case with questionable upstream development, using a fork is quite reasonable for OTB.
>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.
The fate of the ossim package lies in the hands of the OSSIM developers, if the issues raised remain unresolved the package will be removed from Debian and by extension from Ubuntu. It may also affect its inclusion in OSGeo-Live, or they may choose to keep the package despite its defects.
Kind Regards,
Bas
Reply to: