[gdal-dev] Tickets 2385 and 2683 (ECW and MrSID plugins)

[Agustin Lobo]

As I'm not a developer, I might not be understanding the
alternative to patches 2385 and 2683 that is suggested. But as a user
and teacher of students using open source GIS packages, I do understand
the requirements, which IMHO are:

1. A clear way to compile gdal with ecw and mrsid support, and a
clear way of using the generated package for the compilation of
an open source GIS pacakge (I.e., QGIS, gvsig) able to display ecw and 
mrsid images.

2. As most users of open source GIS (and certainly all my students)
will never compile anything but install binaries, and these binaries
come (it seems that because of licensing issues) with no ecw and no 
mrsid support
for linux distributions,
we do require a way to add this support to the binary distribution of
the GIS package somehow.
I thought that patches 2385 and 2683 were suggesting a way of solving this
problem.

Actually, this support is present for windows binary distributions of QGIS,
provided the user takes the steps described at the end of page
http://sites.google.com/site/eospansite/qsig-for-windows
(mainly thanks to directions provided by Micha Silver) for example. But
the same type of solution does not exist for any binary distribution of QGIS
for Linux.

Having ecw and mrsid support is critical for any GIS package to be 
considered
as a practical tool here, because all our official (and free) 
orthoimagery is
distributed in those formats. Therefore, at present, only windows versions
of QGIS can be considered a practical GIS tool.

Hope there is some way of solving this problem. Frank, is your suggestion
becoming a new ticket? Any estimate of when this solution could be 
implemented?

Closing tickets 2385 and 2683 with WONTFIX and not opening a new one
aiming to solve the problem would be very worrying.

Thank you all for your work on gdal.

Agus
-- 

Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo at ija.csic.es
http://www.ija.csic.es/gt/obster



Francesco P. Lovergine wrote:
> On Sun, May 03, 2009 at 10:41:55PM -0400, Frank Warmerdam wrote:
>   
>> Francesco Paolo Lovergine wrote:
>>     
>>> On Sat, May 02, 2009 at 11:18:34AM -0400, Frank Warmerdam wrote:
>>>       
>>>> I'm going to close these tickets as WONTFIX, though folks are welcome to use
>>>> the patches for their own use.
>>>>
>>>> I think it is more appropriate to improve the "in tree" plugin configuration
>>>> and makefile logic rather than pushing drivers out as their own packages.
>>>>
>>>>         
>>> The reason for those patches is having an independent compilation unit. This is
>>> the only purpose for a plugin hack for ecw/mrsid, i.e. to solve a
>>> licensing problem. But for that, I agree that a more general approach to
>>> support a plugin mechanism (possibly with a versioning support) would 
>>> be nice. Are you thinking to something like an apache-like mechanism to 
>>> support DSO modules?
>>> It would be useful defining the constraints for that you are thinking.
>>>       
>> Frankie,
>>
>> I'm afraid I don't understand what you mean by "independent compilation
>> unit" or why exactly the licensing issues of ecw and mrsid make them special
>> with regard to how the plugin gets compiled.
>>
>>     
>
> The reason for having a separated source is allow adding both supports
> to a pre-compiled gdal that does not enable them. An independent compilation
> unit is stuff that can be compiled a part and added to the base after.
>
> Both ecw and mrsid
> SDK require accepting a specific EULA beforei building/using
> and do not distribute sources and/or patches for the sources 
> (both .deb and .rpm stuff can require them) in the case of ecw,
> so it is an problem for binary distributions distribute a gdal+ecw and/or
> gdal+mrsid.
>
>   
>> I don't know how apache handles DSO modules, so I can't comment on whether
>> things would evolve in that direction.
>>
>> I am imagining adding configure options to specify particular drivers should
>> be build and installed as plugins.
>>
>> So in addition to --with-ecw=<path to ecw sdk> there might also be
>> --with-ecw-as-plugin which would cause the ECW driver to be built and
>> installed as a plugin.
>>
>> Best regards,
>>     
>
> That's absolutely reasonable and can co-exists with the previous goal.
>
>