On Feb 17, 2009, at 5:35 PM, Hamish wrote:
Howard Butler wrote:
Debian has the luxury of using GDAL by default, which is the only
sane
way this should go. But I can't make GDAL a hard requirement for
libLAS.
how about some sort of "SRS crippled" warning to the user if
libgeotiff-
only or without either of gdal/libgeotiff. (I expect the low-cal users
don't want to see that over and over though :)
It's not so much crippled as "fully featured". The GeoTIFF <-> WKT/
Proj4 processing of GDAL is much more developed than the simple key
translation that a latest libgeotiff has. Neither is perfect, but for
those who can take the GDAL dependency, it might cause fewer headaches
in the end.
Another complication is likely to arise when GDAL in turn starts
linking against libLAS, but we'll burn that bridge when we need to :)
we solved that circular dependency in GRASS by way of the gdal-
plugin*.
before that it was a complete nightmare for Debian to auto-build the
packages. Both due to the order of compiling things**, and e.g. if a
new
grass package came out, GDAL had to be rebuilt, and so the many
packages
depending on GDAL had to be rebuilt, and so on, and so on.
[*] http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz
see also http://packages.debian.org/lenny/libgdal1-1.5.0-grass
and the qgis-plugin-grass package (similar problem for QGIS<->GRASS)
[**] the old method IIRC was to 1) build gdal without grass support,
2)
build grass with gdal support, 3) remove & rebuild gdal with grass
support.
on 11+ hardware platforms.
Gee, that sounds awful. Even more incentive to get this srs stuff out
into its own library.
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
