[GRASS5] Start planning for GRASS 6.2?

It seems like GRASS 6.1 is pretty stable, although the flood of new and improved features continues. I haven’t seen any major problems in quite awhile. And there are LOTS of improvements in 6.1 over 6.0. Should we begin thinking about creating a 6.2 GRASS by the end of the year and moving new development to a 6.3?

There are a couple features I want to ask about that would round out a 6.2 release very nicely. One is the inclusion of the GRASS Extension Manager (GEM) nearing completion by Benjamin Ducke. This would make GRASS more easily extensible if included in the source distribution.

The other is a better attribute database management system (some kind of a spreadsheet like form for data tables, with some basic editing, selecting, and maybe even querying). There was some discussion a short while back about adapting an existing set of tools for this, tied to implementing SQLite (I can’t remember who at the moment). More recently, the possibility has been raised about making SQLite the default attribute data management system—although having briefly looked at the new system used by Open Office 2, I wonder if we might want to think about heading in that direction (or does the Java platform make it difficult?). Is this a possibility in the near future?

So, is it time to plan for a new release?

Michael


Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael, it's always great to see GRASS posts from you! I share your
enthusiasm...

On Wed, 2005-10-26 at 22:53 -0700, Michael Barton wrote:

It seems like GRASS 6.1 is pretty stable, although the flood of new
and improved features continues. I haven’t seen any major problems in
quite awhile. And there are LOTS of improvements in 6.1 over 6.0.
Should we begin thinking about creating a 6.2 GRASS by the end of the
year and moving new development to a 6.3?

This is a very interesting prospect, and one that I would like to see
happen. My selfish reason (not meant to influence GRASS too much, but
perhaps only a little) is that I believe that Fedora Core 5 (FC5) will
be in its final stages of testing around the end of the year. As with
all Fedora releases, it's going to roll up lots of latest and greatest
open source technologies, many of which are hitting their own major
stable version numbers (such as OpenOffice.org 2, but many others, too).
I would very much like to see GRASS 6.2 be one of the packages that's
ready to be packaged for FC5, since that will establish a new "stable"
version that can ultimately be packaged for Red Hat's commercial
products.

There are a couple features I want to ask about that would round out a
6.2 release very nicely. One is the inclusion of the GRASS Extension
Manager (GEM) nearing completion by Benjamin Ducke. This would make
GRASS more easily extensible if included in the source distribution.

I have not myself played with it, but one extension that I'm starting to
look at is some way to regain 3D model import functionality. The loss
of the OpenDWG libraries (due to not being GPL-compatible) is a bummer.
I am presently browsing source code for blender and verse
(http://blender.org and
http://uni-verse.org/What_is_Uni-verse_about.4.0.html ) to see if the
verse server or blender's native code provides a convenient way to re-
acquire 3d model import. I've been told that the place to hook that in
is the v.in.ogr code, but I haven't yet looked at whether the extension
manager is a way to add this functionality without having to recompile
GRASS every time I try something new on the blender or verse side.

The other is a better attribute database management system (some kind
of a spreadsheet like form for data tables, with some basic editing,
selecting, and maybe even querying).

I /love/ this idea. I think it would be one of the most powerful things
we could offer.

There was some discussion a short while back about adapting an
existing set of tools for this, tied to implementing SQLite (I can’t
remember who at the moment). More recently, the possibility has been
raised about making SQLite the default attribute data management
system—although having briefly looked at the new system used by Open
Office 2, I wonder if we might want to think about heading in that
direction (or does the Java platform make it difficult?). Is this a
possibility in the near future?

I think we should look hard at solutions that integrate directly with
OpenOffice.org. OOo Calc is not my favorite spreadsheet, but it's a
very popular one, and to be able to integrate GRASS into OOo would be to
immediately reach thousands of potential users who want to plot
demographic (and other) data against things like US states or countries
or counties, etc.

So, is it time to plan for a new release?

I hope so...

M

On Thu, Oct 27, 2005 at 07:34:10AM -0400, Michael Tiemann wrote:

On Wed, 2005-10-26 at 22:53 -0700, Michael Barton wrote:

...

> The other is a better attribute database management system (some kind
> of a spreadsheet like form for data tables, with some basic editing,
> selecting, and maybe even querying).

I /love/ this idea. I think it would be one of the most powerful things
we could offer.

> There was some discussion a short while back about adapting an
> existing set of tools for this, tied to implementing SQLite (I can’t
> remember who at the moment). More recently, the possibility has been
> raised about making SQLite the default attribute data management
> system—although having briefly looked at the new system used by Open
> Office 2, I wonder if we might want to think about heading in that
> direction (or does the Java platform make it difficult?). Is this a
> possibility in the near future?

I think we should look hard at solutions that integrate directly with
OpenOffice.org. OOo Calc is not my favorite spreadsheet, but it's a
very popular one, and to be able to integrate GRASS into OOo would be to
immediately reach thousands of potential users who want to plot
demographic (and other) data against things like US states or countries
or counties, etc.

While I agree to have a nice GUI for attribute database management,
there is still the 65xxx limit in OpenOffice2. In GIS we easily hit
such limits...
Is there an alternative?

Markus

Markus,

Actually, I was thinking of file compatibility with OO (a database driver)
rather than an interface here. IMHO, we still need an attribute management
interface in GRASS itself.

In OO, if you use the database module ("base") it works much like Access and
handles very large sets of records. A spreadsheet is not really for database
work, though I realize that many people with small files use it that way.

OO 1.x used dbf files for its default database format. In OO 2.x, they've
moved to a new system, HSQLDB. The new one can be had as a stand alone dbms
<http://hsqldb.org/&gt;\. As we are talking about implementing more robust
database implementations for GRASS, I wanted to raise the mention of HSQLDB.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Thu, 27 Oct 2005 13:57:12 +0200
To: Michael Tiemann <tiemann@redhat.com>
Cc: Michael Barton <michael.barton@asu.edu>, grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] Start planning for GRASS 6.2?

On Thu, Oct 27, 2005 at 07:34:10AM -0400, Michael Tiemann wrote:

On Wed, 2005-10-26 at 22:53 -0700, Michael Barton wrote:

...

The other is a better attribute database management system (some kind
of a spreadsheet like form for data tables, with some basic editing,
selecting, and maybe even querying).

I /love/ this idea. I think it would be one of the most powerful things
we could offer.

There was some discussion a short while back about adapting an
existing set of tools for this, tied to implementing SQLite (I can¹t
remember who at the moment). More recently, the possibility has been
raised about making SQLite the default attribute data management
system‹although having briefly looked at the new system used by Open
Office 2, I wonder if we might want to think about heading in that
direction (or does the Java platform make it difficult?). Is this a
possibility in the near future?

I think we should look hard at solutions that integrate directly with
OpenOffice.org. OOo Calc is not my favorite spreadsheet, but it's a
very popular one, and to be able to integrate GRASS into OOo would be to
immediately reach thousands of potential users who want to plot
demographic (and other) data against things like US states or countries
or counties, etc.

While I agree to have a nice GUI for attribute database management,
there is still the 65xxx limit in OpenOffice2. In GIS we easily hit
such limits...
Is there an alternative?

Markus

I would vote against HSQLDB, as it needs Java.
All the best.
pc

At 17:53, giovedì 27 ottobre 2005, Michael Barton has probably written:

Markus,

Actually, I was thinking of file compatibility with OO (a database driver)
rather than an interface here. IMHO, we still need an attribute management
interface in GRASS itself.

In OO, if you use the database module ("base") it works much like Access
and handles very large sets of records. A spreadsheet is not really for
database work, though I realize that many people with small files use it
that way.

OO 1.x used dbf files for its default database format. In OO 2.x, they've
moved to a new system, HSQLDB. The new one can be had as a stand alone dbms
<http://hsqldb.org/&gt;\. As we are talking about implementing more robust
database implementations for GRASS, I wanted to raise the mention of
HSQLDB.

Michael

--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

On 27/10/05 18:53, Michael Barton wrote:

OO 1.x used dbf files for its default database format. In OO 2.x, they've
moved to a new system, HSQLDB. The new one can be had as a stand alone dbms
<http://hsqldb.org/&gt;\. As we are talking about implementing more robust
database implementations for GRASS, I wanted to raise the mention of HSQLDB.

I'd say use SQLite, since OO can handle SQLite too. See here:
http://documentation.openoffice.org/HOW_TO/ scroll down to "Using SQLite
Database with OpenOffice.org".

--W

--

<:3 )---- Wolf Bergenheim ----( 8:>

I received this link from an OOo developer:
http://dba.openoffice.org/miscellaneous/dba20.html#whynot_sqlite

Despite the name, it actually looks as if there is no great resistance
to supporting sqlite if somebody wants to do that work. And it looks as
if the barrier to doing that work is not that high any longer.
Moreover, the work need not be done before the imminent release of OOo
v2. This might be attractive compared to handling the Java requirements
of HSQLDB.

M

On Thu, 2005-10-27 at 08:53 -0700, Michael Barton wrote:

Markus,

Actually, I was thinking of file compatibility with OO (a database driver)
rather than an interface here. IMHO, we still need an attribute management
interface in GRASS itself.

In OO, if you use the database module ("base") it works much like Access and
handles very large sets of records. A spreadsheet is not really for database
work, though I realize that many people with small files use it that way.

OO 1.x used dbf files for its default database format. In OO 2.x, they've
moved to a new system, HSQLDB. The new one can be had as a stand alone dbms
<http://hsqldb.org/&gt;\. As we are talking about implementing more robust
database implementations for GRASS, I wanted to raise the mention of HSQLDB.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> From: Markus Neteler <neteler@itc.it>
> Date: Thu, 27 Oct 2005 13:57:12 +0200
> To: Michael Tiemann <tiemann@redhat.com>
> Cc: Michael Barton <michael.barton@asu.edu>, grass5 <grass5@grass.itc.it>
> Subject: Re: [GRASS5] Start planning for GRASS 6.2?
>
> On Thu, Oct 27, 2005 at 07:34:10AM -0400, Michael Tiemann wrote:
>> On Wed, 2005-10-26 at 22:53 -0700, Michael Barton wrote:
> ...
>>> The other is a better attribute database management system (some kind
>>> of a spreadsheet like form for data tables, with some basic editing,
>>> selecting, and maybe even querying).
>>
>> I /love/ this idea. I think it would be one of the most powerful things
>> we could offer.
>>
>>> There was some discussion a short while back about adapting an
>>> existing set of tools for this, tied to implementing SQLite (I can¹t
>>> remember who at the moment). More recently, the possibility has been
>>> raised about making SQLite the default attribute data management
>>> system‹although having briefly looked at the new system used by Open
>>> Office 2, I wonder if we might want to think about heading in that
>>> direction (or does the Java platform make it difficult?). Is this a
>>> possibility in the near future?
>>
>> I think we should look hard at solutions that integrate directly with
>> OpenOffice.org. OOo Calc is not my favorite spreadsheet, but it's a
>> very popular one, and to be able to integrate GRASS into OOo would be to
>> immediately reach thousands of potential users who want to plot
>> demographic (and other) data against things like US states or countries
>> or counties, etc.
>
> While I agree to have a nice GUI for attribute database management,
> there is still the 65xxx limit in OpenOffice2. In GIS we easily hit
> such limits...
> Is there an alternative?
>
> Markus
>