[GRASS5] The status of 5.0

Helena Mitasova hmitaso at unity.ncsu.edu
Mon Mar 25 12:22:11 EST 2002


>

Roger,

all of the enhancements that you have mentioned are extremely useful - do
you have
at least a brief man pages for the new ones? (especially the MODFLOW
related?)
Markus, would it be possible to include these new and enhanced modules?

Now the question is where they should go? GRASS5.1? Are they ready for the
current GRASS5.0?

As for switching from GRASS4* to GRASS5* - it is always hard to upgrade and
people should have done
it long time ago, but it is well worth it. Just as a small example from my
own experience: I really hated
the new d.zoom (because I cannot tell left from right and I aways clicked
the wrong button). However,
just recently I had to use some old version of GRASS with the old d.zoom.
Well, enough to say, I don't
hate the new d.zoom anymore. What a tedious work it was to do zooming in
old versions of GRASS -
and that is a function that one uses almost every day.
And that is just a small example. Of course, when you have a lot of custom
features which will need
upgrade that is a different story, but it still may be worth the effort
because GRASS5 has just so many,
so much better capabilities.

As for the "big GRASS 4 installations" are there any? All those that I have
known here in the US
had to switch to ESRI products years ago (CERL, NRCS, USGS, etc.),
as it was manadated as a standard for government agencies.

Helena



> 3)  I've written or modified a number of modules:
>
> r.out.ascii  I added an -s flag to print surfer ascii grids.  I gave you
> that change some time ago and it hasn't been included in the release.  I
> also have been getting a read error from r.in.ascii when using the -s
> option, and have to use a separate program to import some Surfer ascii
> files.
>
> r.in.mf  This reads MODFLOW 2-D binary data into GRASS raster files
>
> r.in.list  This reads MODFLOW list-formatted files into GRASS raster
> files
>
> r.basin  (Probably needs a new name)  This creates masks of contiguous
> areas that meet one of several different logical criteria.  I used this
> to map a geomorphic surface as a continuous area with a slope below a
> given threshold.  It contains several tests other than the "less than or
> equal to" test that I used for that application.
>
> r.proj, v.proj, s.proj  I've modified all of these to perform the
> NAD83<-->NAD27 conversions.  This also requires a version of the proj
> library later than 4, a new library function (pj_do_projA.c) and a place
> to store the conversion tables.  These need to be updated to a more
> recent version of the proj library.
>
> I have a few other utilities that I keep that aren't built as GRASS
> modules, but probably should be.  One imports dxf files that can't be
> handled with v.in.dxf.  I promised several months ago that I would
> upgrade v.in.dxf and haven't had time to get to it yet.  One reads text
> from dxf files and writes GRASS paint label files and one reads text
> labels from site files and writes GRASS paint label files.  I use the
> paint label files in ps.map to label data points and surface features.
> I even have a utility that resamples output from MT3DMS output (3-D
> chemical transport and reaction in ground water) and produces vertically
> refined 3D grid files.  They let G3D produce some pretty stunning
> results.
>
> I'm not trying to make a point that I've done a lot of work that should
> be included in GRASS but I do have to admit that it would reduce my
> workload if they were included in GRASS.
>
> My point is that probably anyone who has kept a GRASS installation for
> production has modified their installation in one or more different
> ways.  As a result I find it really unlikely that a lot of old GRASS
> users (like Blacklands in Texas, for instance) are going to switch to
> GRASS 5. I also doubt that future GRASS 5 users are going to want to
> make frequent updates of their production installations.
>
> Incidentally, have the old GRASS 4.x users been contacted to see if they
> intend to upgrade to 5?  Has anyone worked with them to include their
> modifications, or to see what capabilities they need?  It appears to me
> that if we could get even one big GRASS 4 installation to switch to
> GRASS 5 then their people could make big contributions to the ongoing
> development of GRASS 5.
>
> Roger Miller
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5




More information about the grass-dev mailing list