[ELGIS] Fwd: libtiff4

[Mathieu Baudier]

@Robert: thanks a lot for letting us know, I much appreciate!

I think that for the time being, it's more reasonable not to support
geotiff based on libtiff4, since the impact is quite important as
Peter described.

Ideally we could use build automation to allow anyone to build locally
it own mix based on the SRPMs or the spec files. Any interest in such
an approach?

Or we could at least have ELGIS Plus providing the whole package set
rebuilt without taking care of preserving the base OS.

I would be very interested to hear your thoughts, needs and interests
around this, in order to evaluate if it is worth the effort.

For the next few weeks my priority is however to have the "normal"
packages back to speed (e.g. i386, EL 5, etc.)

On Wed, Dec 12, 2012 at 7:41 PM, Robert Christian Steinke
<rsteinke at uwyo.edu> wrote:
> It looks like there are some policy questions and technical issues for using libtiff4 in ELGIS.  For my work I've recompiled gdal and qgis to use libtiff4, so don't worry about me waiting on this.
>
> ________________________________________
> From: el-bounces at lists.osgeo.org [el-bounces at lists.osgeo.org] on behalf of Peter Hopfgartner [peter.hopfgartner at r3-gis.com]
> Sent: Wednesday, December 05, 2012 4:33 AM
> To: Mathieu Baudier
> Cc: el at lists.osgeo.org
> Subject: Re: [ELGIS] Fwd: libtiff4
>
> On 12/05/2012 08:53 AM, Mathieu Baudier wrote:
>>>> I think you do need to create a libgeotiff4 that uses libtiff4.  I can
>>>> still use gdal, but it won't create BigTIFFs so I assume it is using
>>>> libgeotiff-1.3.0, which is still using libtiff-3.9.4.  Will you also
>>>> need to recompile all of the applications to use libgeotiff4?
>>> Yes, you need to recompile libgeotiff. The same holds true for the
>>> applications. Personally, I did this for GDAL and MapServer. libtiff4
>>> together with libjpeg-turbo gave us a very powerfull soution for raster
>>> data, competing with ECW in terms of speed and space efficiency.
>> Then should we say that our stack doesn't use base libtiff but libtiff4?
>>
>> This would be a significant fork from EPEL (but not from Fedora actually).
>> I am not too keen to maintain two GDALs, MapServers, etc.
> We should check what impact this has on all non-GIS packages depending
> on libtiff, which we should not change, anyways. I can't remember the
> details, but IIRC there were some road blockers to have libtiff and
> libtiff4 installed on the same machine.
> In the end: having libtiff4 and turbo-jpeg in ELGIS would be nice, but I
> fear it would need some non trivial work.
>
>>
>> What about PostGIS 2.0?
>> Since it manages rasters as well I guess it depends on libtiff/geotiff
>> as well? Doesn't it?
> Yes, it does. It should not be too difficult to adapt our PostGIS
> package to 2.0. Personally, I'm using the one from yum.postgresql.org,
> since I'm depending on PostgreSQL 9. The PostgreSQL/PostGIS packages on
> yum.postgresql.org are more complex, since they support multiple
> versions of PostgreSQL on the same machine, so I would not start from them.
>
> Peter
>
> --
> Peter Hopfgartner
> R3 GIS Srl - GmbH
> web  : http://www.r3-gis.com
>
> _______________________________________________
> el mailing list
> el at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/el
> _______________________________________________
> el mailing list
> el at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/el