[GRASS5] features needed for 6.2
benducke at compuserve.de
benducke at compuserve.de
Thu Mar 30 06:11:08 EST 2006
Re. the current state of GEM:
The RCs did not trigger as much feedback and bug reports as
I hoped. From what I got and my own testing I would think
that GEM is stable enough to go into CVS now. In the next
days I will smooth out some minor annoyances. Functionality
is basically where I wanted it to be. For now, I plan no
The documentation should be sufficient to allow people to
use the software and design their own extensions.
For integration into the main CVS, I suggest the following things:
1. GEM itself is just plain ANSI C. The executable should be
installed in /usr/local/bin or whatever the user chooses as
2. The GEM manual in HTML format should be linked to from the main
3. A specially formatted comment line needs to go into index.html
to specify the position at which extensions will install links
to their own documentation pages (see my last email to this list)
4. A directory containing a "skeleton" extension should go somewhere
(maybe in etc? where the user can easily find it)
I have only used CVS for downloading source code so far. I can
but I don't know when I will be able to, as sessions have started at
my university. Maybe someone would volunteer to put GEM into CVS?
> ----- Originalnachricht -----
> Von: Markus Neteler <neteler at itc.it>
> Datum: Mittwoch, 29. März 2006 11:15 pm
> Betreff: Re: [GRASS5] features needed for 6.2
> > On Wed, Mar 29, 2006 at 07:49:32PM +1200, Hamish wrote:
> > > Ok, trying to combine everyone's comments into a draft
> plan/roadmap:> >
> > > We release 6.0.3 whenever it feels right, independent of 6.1+.
> > Yes, we can even do this soon as I have backported two
> > relevant changes (NVIZ tcltk8.4 support and fftw3)
> > ...
> > > Consensus is to include GEM and gis.m in 6.2.0. It would be
> > to have
> > > them both in raw form in the 6.1.0 development snapshot
> release, but
> > > they don't have to be perfect for that.
> > Benjamin, what's the state?
> > ...
> > > SQLite as default db: I think SQLite support is still too
> young and
> > > lightly tested, and it is too important that it doesn't have
> > problems.> Also I don't like the extra dependency.
> > SQLite is getting fairly standard these days. Also QGIS needs it.
> > We can just invite people to use GRASS-SQLite to find out if it
> > works or not. I do so since I find DBF pretty limited.
> > > If consensus is that this should
> > > happen at some point, I suggest it does in CVS in the *days
> > after* 6.2.0
> > > is released. But this is a catch-22 situation.. to get tested
> > needs> to be default, so if consensus is that it should be
> > for 6.2.0, I
> > > think we need to make it the default ASAP.
> > >
> > > New startup GUI: if it is ready by 8 weeks after 6.1.0 it can
> be in
> > > 6.2.0. Otherwise add it after.
> > >
> > > GUIs for r.digit*, i.points: If ready in the 4 weeks after
> 6.1.0 is
> > > released put it in for 6.2.0. If after that then wait until
> > after 6.2.0.
> > > i.e. We shouldn't wait for it to mature before we can release 6.2.
> > > Same for a GUI frontend to g.gisenv and gis.m preferences.
> > > [*] I take it you meant r.digit and not v.digit Michael?
> > Not related to GUI, but related to a new i.points (as long time
> > promised):
> > http://mpa.itc.it/markus/tmp/i.points.auto_30_mar_2006.tar.gz
> > This should be the merge of i.points + i.vpoints along with
> > homography support (geocoding by lines instead of points which is
> > much easier/faster) and auto-GPC search (based on Fourier
> > correlation).There is a file HANDBOOK inside which explains it a
> > bit. Today
> > I found some raster-map negative row bug, maybe someone wants to
> > give it
> > a try? Would be fun to have that in GRASS soon.
> > ...
> > > If he is happy to do so, I hope Markus will remain as release
> > manager> and generally as the arbitrator in charge of final
> > Yes, I can give a hand of course.
> > > I feel really good about where 6.1-cvs is right now; 64bit &
> > large file
> > > bugs are still trickling in (as expected), but otherwise
> things are
> > > pretty strong.
> > Well, 64bit is doing pretty well AFAIK (only 64bit machines in
> > officenow). Large file is causing problems, Glynn had commented
> > this but
> > then the issue disappeared. Maybe his grass-header-fix script
> > could also
> > do the config.h trick which he suggested?
> > Markus
> > _______________________________________________
> > grass5 mailing list
> > grass5 at grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass5
More information about the grass-dev