[GRASS5] current status

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I understand correctly, now to access shapefiles and postgis data with the
latest grass57 one has to recompile gdal from cvs. This is also needed (plus
the patch from Radim) to use grass rasters and vectors in qgis.
Am I correct?
The problem I am encountering is now to find gdal:
ftp://ftp.remotesensing.org/
http://www.remotesensing.org/
are unavailable (unknown host).
Furthermore, it is unclear to me how to get the necessary (grass, ecw, etc.)
libraries. Are they already in the cvs, or should be downloaded and installed
elsewhere?
Alternatively, is it likely that things will settle down, so that it would be
easier to wait a few weeks?
Thanks for your help.
- --
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
GPG key @: www.faunalia.it/Public_key_Paolo.asc
Only free software: www.gnu.org / www.linux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAvCLS/NedwLUzIr4RAoFGAJ4mkRIMCreAZaFzjTNbEiF1Tv5nmQCfSWHx
92S/CsO8m+XcPwpRnNGtBbk=
=4dXN
-----END PGP SIGNATURE-----

On Tuesday 01 June 2004 08:31, you wrote:

If I understand correctly, now to access shapefiles and postgis data with
the latest grass57 one has to recompile gdal from cvs.

Shapefiles should work correctly with GDAL 1.2, postgis only with CVS version.

This is also needed
(plus the patch from Radim) to use grass rasters and vectors in qgis.

Yes.

Furthermore, it is unclear to me how to get the necessary (grass, ecw,
etc.) libraries. Are they already in the cvs, or should be downloaded and
installed elsewhere?
Alternatively, is it likely that things will settle down, so that it would
be easier to wait a few weeks?

Yes, I think that it is better to wait a while. At least until
the patches are in GDAL. The raster support in QGIS is not perfect yet,
missing is support for floating point color tables because GDAL supports
only positive integers. We have already found the solution, but it is not
yet implemented.

BTW 1: Am i right that there is no function which can read rules from
color table in GRASS, something like
G_get_color_rule( struct Colors *, int rule,
                  CELL*, int*, int*, int*,
                  CELL*, int*, int*, int*)
?

BTW 2: Color table is stored as double linked list, doesn't that make
G_get_raster_color too slow?

Radim

On Tuesday 01 June 2004 10:49, Radim Blazek wrote:

BTW 1: Am i right that there is no function which can read rules from
color table in GRASS, something like
G_get_color_rule( struct Colors *, int rule,
                  CELL*, int*, int*, int*,
                  CELL*, int*, int*, int*)
?

BTW 2: Color table is stored as double linked list, doesn't that make
G_get_raster_color too slow?

BTW 3: What is the difference between modular and fixed color table rules?
Is it only the format in which the rules are stored in file?

Radim

The problem I am encountering is now to find gdal:
ftp://ftp.remotesensing.org/
http://www.remotesensing.org/
are unavailable (unknown host).

It seems to be down..

H

> Alternatively, is it likely that things will settle down, so that it
> would be easier to wait a few weeks?

Yes, I think that it is better to wait a while.

For now, you can maybe try Debian packages built by Steve Halasz:

On Monday 31 May 2004 18:04, Steve Halasz wrote:

> > There are instructions here for building a grass 5.7 Debian package:
> > http://mpa.itc.it/markus/grass57/debian/grass57deb/
>
> Yes; I am meaning to build an unofficial GRASS 5.3.0 and 5.7.0 .deb for
> distribution when things calm down a little at work next month.

I have built the debs required to use qgis with grass for i386. They are
available at:

deb http://bullhorn.org/debian unstable main
deb-src http://bullhorn.org/debian unstable main

libgdal1 is built with Radim's initial patch to support grass 5.7
rasters. Needs to be updated with the latest patch.

grass-bin has some problems.
- It does not run ldconfig on the grass libs.
- The tcltkgrass interface won't start. It looks for it in the temporary
packaging install dir and not where dpkg installs it.
- Files aren't installed in locations required by Debian policy I'm
pretty sure.
- Requirement to be built in /usr/src probably won't work with build
daemons.
- Maybe the debian directory shouldn't be kept in the grass source dir
in cvs. I think this might have unwanted side effects. See:
http://lists.debian.org/debian-mentors/2003/10/msg00201.html
- Not certain this won't cause problems if installed with the debian
5.0.3 grass package. May need to conflict with it or provide some kind
of upgrade path.

qgis-plugin-grass provides the actual grass plugin and depends on
grass-bin_5.7.0.

> It would be nice if a user installs this unofficial package or had a
> locally compiled version of 5.7 then the QGIS package GRASS plugin would
> magically start working, or if the QGIS package could contain it's own
> version of libgrass (say taken from the 5.7.0 release).. This probably a
> terrible idea, but I really don't know how it all fits together. Radim?

If you run qgis from the grass57 prompt, the grass plugin should appear
in the plugin manager. Once you load the plugin, things should work ok.
Although grass raster support is still incomplete. Limitations in gdal
and qgis prevent proper display of some rasters ATM.

> > I'm currently trying to assess whether it's best to try to get that
> > package included in Debian
>
> .. this has been an ongoing question. The current version in Debian is
> old and partially broken (NVIZ needs build-depends set to tcl/tk-8.3.
> This not working is a major draw back. Debian bug #248105).
>
> My thoughts on the matter:
> http://article.gmane.org/gmane.comp.gis.grass.devel/3338
>
> see also this thread:
> http://thread.gmane.org/gmane.comp.gis.grass.user/4269
>
> As an update to that, a 5.3.0 release has recently be made, and a 5.7.0
> release should be out in a couple of weeks.
>
> see http://grass.ibiblio.org/announces/announce_grass530.html

I'm for getting a 5.7 package into debian. It can take it's sweet time
getting into stable. But I suspect a lot of grass/qgis users are using
testing/unstable and would be glad to have it. I'm not so wise in the
ways of grass, so if you want to package it, great! I would be happy to
lend a hand if you like.

> > or modify the plugin to work with 5.0.3.
>
> I don't think this is possible or else worth it.

Yes, Radim has verified this is not possible.

Regards,
Steve

Radim Blazek wrote:

BTW 1: Am i right that there is no function which can read rules from
color table in GRASS, something like
G_get_color_rule( struct Colors *, int rule,
                  CELL*, int*, int*, int*,
                  CELL*, int*, int*, int*)
?

Correct. Actually, I'm not sure that the data actually exists in
anything resembling that form.

BTW 2: Color table is stored as double linked list, doesn't that make
G_get_raster_color too slow?

Lookup tables may be used to speed things up; however, if the lookup
tables aren't active, then lookups will simply iterate through the
list until a matching rule is found.

--
Glynn Clements <glynn.clements@virgin.net>