[GRASS5] Using external PROJ with 5.3

[Frank Warmerdam]

Radim Blazek wrote:
> OK, I agree with idea, but maybe we could do it in more secure way?
> E.g. optionaly copy libgdal.so to $ARCH/libgrass_gdal.so and build 
> GRASS against this copy? There is already libgrass_shape.so there.
> 
> Another question, how should be built GDAL included in GRASS,
> and where is the limit for dependencies? GDAL should have at least
> xerces and Postgres but probably more, so include also all those libs?

Radim / Paul,

I would agree that renaming libgdal.so to something grass specific
would ensure there is no interference between the GRASS version of GDAL
and any external copy on the system; however, it would make it somewhat
harder for people to install a more recent (or more fully configured) GDAL
and make it work properly.  I guess we could just not that if they want to
make r.in.gdal use a different GDAL they can link $ARCH/libgrass_gdal.so to
their GDAL shared library.

I would also note that if you are going to distribute a GDAL shared library
with GRASS you also need to carry along the support data (normally installed
as /usr/local/shared/gdal) with various EPSG tables, and other support data
files used by specific raster and vector drivers.  These could live in the
GRASS tree, but r.in.gdal would need to be altered slightly to push an
appropriate file search location on the GDAL data search path.

As for build options I would suggest that PNG, JPEG use external shared
libraries which are assumed to be present on the system.  The GIF driver
should be configured --with-gif=internal as should the TIFF and GeoTIFF
driver's unless you want to distribute libtiff and libgeotiff shared
libraries with GRASS.  It is often necessary to have fairly recent versions
of these so depending on a system version is risky.

Is ODBC used elsewhere in GRASS?  If so, I think GDAL/OGR ODBC support should
also be enabled.

Also, I think HDF support is very desirable to the GRASS user community though
it will tend to add a bunch of additional complexity.

Oracle, ECW, MrSID and JPEG2000 should likely not be included (well this may
change when the ECW source is "opened" at which point ECW and JPEG2000 might
well become practical).

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent