[GRASS5] Re: KerGIS

Hamish hamish_nospam at yahoo.com
Tue Jan 27 04:59:12 EST 2004


> > : Jeff
>   : Markus
------------

> > As it stands now, I'm not sure where to contribute.

Fixing things, or at least complaining about things, you need as you
need them is a good start I think. Over time this gets the
non-structural problems taken care of, and I think most GRASS's bugs
(from the user's perspective) are non-structural.


> > There are *at least* three code streams for GRASS (5.0, 5.3 and 5.7
> > -- not to mention 4.3) This seems to be the opposite of fix and
> > simplify.

I think at this point no one is directly working on 5.0, it's only old
business. So there are really two active branches. Actually only 1.5
branches really as 5.7 is only about 1.8 megabytes of code-- most of it
is automatically linked directly from the live 5.3 CVS and only exists
in one place. From the end user's perspective though, there is a tyranny
of choice.

 
> Several developers prefer to work on 5.3 - even if things should have
> been already merged into 5.7.

some feedback re. new business:
I don't really use vector or database support so using 5.7 isn't
critical for me. I do however need to use site data heavily, and the
simplicity & bash script-ability of the site_lists format (on the raw
ascii file level) makes me dependant on 5.3. If it wasn't for that I'd
use 5.7 in a minute. As I don't really work on the vector modules, any
improvements to the display or raster modules automatically get fed into
5.7 so I don't feel at all guilty about 'neglecting' it. I just have to
remember to update the man pages and ps.map and fight the urge to
clean up the sites modules.
None of this is structural work of course, just details.
I think the structural work for 5.3->5.7 is a full time job for someone.

Maybe I should look to see what I really need that couldn't be done 
without anything more than s.in.ascii and s.out.ascii? Looking through
some scripts, not much actually! I seem to be somewhat addicted to
creating site_lists files manually with sed &/or Matlab though.

(s.univar was today's outside need, but that was to analyze some cell
stats on a raster map converted with r.to.sites; what a cludge! we need
a stats library! [again, I offer to help populate functions if someone
else lays down the framework; even though it should really be done by a
better coder/statistician than I])



> > And none of them seem to include the capabilites I need. 

They never will unless people (repetitively) explain what is missing &
what they need.


> > In order for 5.7 to work, I need the code for 5.3. Why? Shouldn't
> > all that new code simply go into 5.3?

The idea, as I understand it, is for the 5.3 code branch (which includes
all the old 5.0 and 4.3- legacy code) to be retired almost as soon as it
is released. It has features (ie datum support) too important to be put
off until the official 5.7.0 release, yet too radical to go into the
stable 5.0 series. 5.7 is the opportunity for a vast clean up and
simplification of the GRASS code base-- we only transfer to it what is
actually used.

While we wait for that, I don't think it's too much to do as an end user
to rebuild 5.7 locally 3 or 4 times a year. You can write a script to
automate it or at least use as cut-and-paste notes for next time.. it's
a chore, but not 'hard'.


> > If I could get everything to compile on cygwin, I'd use it there.
> > But they don't. 

What doesn't? Is there a bug report? (does r.terraflow compile, btw?)


> > There's just too many switches and options for a simple (for
> > example)
> > 
> > ./configure
> > make --with-mysql
> > make install

Most of the "switches" (that I have to use, anyway) are really paths
pointing to where libraries/includes are. It'll never compile on say BSD
or even on both the two most popular Linux distributions without such
hints.


> > I've not seen a project with so much connection between code
> > streams. Why?
> 
> Because there aren't enough people to sort out this problem. 
> If it helped, we could merge the code into 5.7. But then I expect
> a major desaster:  5.3 will receive changes and some developers
> regularly ignore to update the relevant files in 5.7 as well.
> I try to hunt for those files, but it's not that easy.

Yes, it would be a huge pain to have to check in everything twice into
divergent code bases. The problem goes away as soon as 5.3 moves into
bug-fix-only mode though. It would be nice if we had a countdown to
5.3.0 todo-list on a webpage somewhere.


> > Almost all of my work is with vectors and the attributes, lots of
> > attributes of polygons (adjacency lists, unions, intersects, area
> > calculations, and attributes -- think FRAGSTATS woulodn't it be nice
> > to have a version for GRASS for people to build on).

So what's missing from 5.7?? I don't understand. What does 5.3 have that
5.7 is missing from for you? (besides simplicity of end-user building)


> > For my
> > projects, I'm constantly moving files between GRASS and Arc/Info and
> > ArcView for projecting files across all sorts of projections, datums
> > and coordinate systems and I have yet to be able to accomplish this
> > in GRASS simply because I can't gdal/GRASS to work resulting from
> > some sort of goofy circular dependencies).

So do you have problems with *both* PROJ.4 *and* GDAL/OGR then? I was
under the impression that the proj stuff was working really well in both
5.3 and 5.7...

What are the problems? Are there bug reports filed for them?
These are the sort of things that need to be fixed ASAP, IMO.


> > We need help. Isn't there an institution that promotes the
> > development of GRASS where people can work on it full time? It seems
> > that the overworked developers are spread pretty thin and the
> > project needs a small army of people pushing on.

If there are specific things you need fixed ASAP to make you more
productive so as to make your company more money, *especially* with
respect to PROJ.4 or GDAL, there are a number of people reading this
list who code for cash, probably for cheaper than an ESRI module, and it
might help break the log jam for others as well, which means more
support, which means more users, .. more support, etc.


> > And thanks for hearing my pleas.
ditto



regards & US$0.013,
Hamish




More information about the grass-dev mailing list