Hello Wolfgang
On 19 Jul 2003, Wolfgang Lueck wrote:
You realise that this is an additional installation hurdle for new
users.
I find it hard to disagree with you as this used to be my opinion as well.
Obviously this is true, although some users might have PROJ installed
already. So I will try and describe what has caused me to change my
opinion more recently.
Most important probably is that I can now compile an external PROJ.4 on
my system. When I first tried (version 4.4.5 I think) I couldn't get it to
compile on SGI/IRIX, so I relied on the internal GRASS copy then. But the
more recent PROJ versions I have had no problem with. It is very quick and
simple to install
tar xvzf proj-4.4.7.tar.gz
cd proj-4.4.7
./configure
make
make install
and then you also have the cs2cs program to reproject points, which is
very useful.
We can put instructions on the website for how to do this, also for
checking that the directory where libproj.so is installed is in
/etc/ld.so.conf on Linux or in LD_LIBRARY_PATH.
Do you feel that your user base is big enough and that your users
are capable of installing all dependency packages on their own? Remember
not all users are developers or really Linux / UNIX literate.
In fairness, if a user is not Unix literate, they are not going to get
much out of GRASS, or certainly not use it to anywhere near its full
potential.
I just see all those queries coming in as soon as this happens. There are
enough as there are with postgres, tcltk versions, and ODBC whose libraries
residing in different locations depending on version and distribution.
I know this is not really your point but PROJ.4 is a lot smaller and
simpler to install than those other things. Tcl/Tk can take an hour to
compile and install; PROJ is just 5 minutes, or less on a fast machine. I
wouldn't even try installing postgres and ODBC from source.
I suspect most queries would come from using an out-of-date version of
PROJ (this has been the case so far). I will try looking at getting the
configure script to check the version and refuse to continue if it is
older than 4.4.6.
It might be trivial for you developers but certainly not for the users.
Well If you go the route of removing PROJ and GDAL from the main
N.B. GDAL isn't contained in the GRASS sources. The change I was proposing
only means GDAL must be installed before compiling r.in.gdal if you want
to use it, rather than adding it as an afterthought. I suspect (have no
proof though) that the gdalbridge mechanism whereby you can compile GRASS
without GDAL and then install it afterwards is sometimes causing
segmentation faults with r.in.gdal because the gdalbridge code may be out
of date---this highlights an advantage of separating out things that are
maintained externally from GRASS.
sources, we should consider setting up a package containing all
ancillary code and packages. Even if it is a bit outdated, this might
proove extremely valuable for Newbie's. These ancillary packages might
Yes, but installing these packages wouldn't be any less bother than
installing the latest version. I thought the point was that with the PROJ
built into GRASS the user didn't have to worry about installing it
separately. When PROJ was not being actively maintained for a few years it
was probably a good idea to keep a copy inside GRASS for a while, but now
that it is being maintained again and continuously changing it is just
messy having different versions around and trying to keep them up-to-date.
be things like R, Gstats, alternate GUI's such as QGIS or QGRASS dwg
import module etz. I still think that the biggest problem GRASS has is
the steep learning curve which starts with its installation and
configuration. I frequently have to install the package for fellow GIS
/ RS users.
What about writing a script that would automatically download the
latest versions of the packages from their respective ftp sites, gunzip,
untar, configure with the correct switches for use with GRASS, compile and
install them all before the main GRASS compilation?
Looks like there are two main reasons for having a separate PROJ:
1) Less developer effort maintaining separate copies and user can take
advantage of latest PROJ capabilities without having to update GRASS.
2) Requires much less space; src/libes/proj directory in GRASS was several
megabytes and all the projection code was compiled into a static library
and linked into every module that uses projection. This makes the binaries
much bigger as well. GRASS 5.1 (to be GRASS 5.7.x) uses shared libaries
and the compiled binaries take a tiny amount of space compared to GRASS
5.0
3) It appears to me generally the way things are done with most Free
software, i.e. all the packages depend on others which have to be
installed first. GRASS didn't used to be like that and is slowly evolving.
Definitely a script to download and install pre-requisite packages as a
pre-install step to GRASS might be a nice idea...
Paul
