[GRASS5] New GIS Manager

GRASS GIS GRASS GIS developer
1

Hello Michael et al.

I took a quick look at the screenshot of the new GIS Manager you've been developing, and it looks impressive.

Can the new GIS manager be installed on 6.0.2?
Would you say it's stable enough to use for doing GIS, or is it still too early? I don't mind a few crashes and making bug reports, but I'd like to get a little map development done in between. :wink:

Regards,
Michael

2

Up until a couple weeks ago, I'd say it could probably be installed on 6.0.x
and most of it would work.

With the new, extensive changes to the module gui's, involving a change to
the C module parser.c, I don't know now.

In terms of stability, it is undergoing a rapid set of changes right now and
over the next week +/-. It should calm down after that.

I've got a bunch of things to commit to the cvs on Monday that will fix bugs
in duplicating and compositing, as well as other stuff.

I've managed to integrate most of what I'm doing with the new work by Cedric
Shock on the module GUI. However, I've run into a couple items that have
broken due to the new architecture. The most notable that I haven't been
able too fix yet are interactive querying and measure tools on the map
display toolbar. These should be easily fixable once Cedric is back next
week.

If these don't bother you, I'd recommend trying it after Monday.

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: Michael Rensing <michael.rensing@shaw.ca>
Date: Sat, 25 Mar 2006 07:27:53 -0800
To: "'grass5@grass.itc.it'" <grass5@grass.itc.it>
Subject: [GRASS5] New GIS Manager

Hello Michael et al.

I took a quick look at the screenshot of the new GIS Manager you've been
developing, and it looks impressive.

Can the new GIS manager be installed on 6.0.2?
Would you say it's stable enough to use for doing GIS, or is it still
too early? I don't mind a few crashes and making bug reports, but I'd
like to get a little map development done in between. :wink:

Regards,
Michael

3

Michael Barton wrote:

Up until a couple weeks ago, I'd say it could probably be installed on 6.0.x
and most of it would work.

With the new, extensive changes to the module gui's, involving a change to
the C module parser.c, I don't know now.

The current gui.tcl won't work with the old parser.c, and I don't
think that the current gis.m will work with the old gui.tcl.

--
Glynn Clements <glynn@gclements.plus.com>

4

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sun, 26 Mar 2006 17:47:43 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Michael Rensing <michael.rensing@shaw.ca>, "'grass5@grass.itc.it'"
<grass5@grass.itc.it>
Subject: Re: [GRASS5] New GIS Manager

Michael Barton wrote:

Up until a couple weeks ago, I'd say it could probably be installed on 6.0.x
and most of it would work.

With the new, extensive changes to the module gui's, involving a change to
the C module parser.c, I don't know now.

The current gui.tcl won't work with the old parser.c, and I don't
think that the current gis.m will work with the old gui.tcl.

I'll take your word about the former and can vouch for latter. So this means
that the newest GIS Manager will not work with 6.0.x unless we backport
parser.c changes from 6.1.

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

5

Michael Barton wrote:

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sun, 26 Mar 2006 17:47:43 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Michael Rensing <michael.rensing@shaw.ca>, "'grass5@grass.itc.it'"
<grass5@grass.itc.it>
Subject: Re: [GRASS5] New GIS Manager

Michael Barton wrote:

Up until a couple weeks ago, I'd say it could probably be installed on 6.0.x
and most of it would work.

With the new, extensive changes to the module gui's, involving a change to
the C module parser.c, I don't know now.
     

The current gui.tcl won't work with the old parser.c, and I don't
think that the current gis.m will work with the old gui.tcl.
   
I'll take your word about the former and can vouch for latter. So this means
that the newest GIS Manager will not work with 6.0.x unless we backport
parser.c changes from 6.1.

My opinion is to not backport it but to use the available energy to prepare
a GRASS 6.1.0 release. Only then it can enter Debian etc.

Maybe people could indicate how far they see their contributions in terms
of sort-of-stability to create a release branch? I am not talking about
6.2.-stable,
just a somewhat reliable 6.1.0 release to illustrate the great new features
of 6.1.

Markus

6

On 3/27/06, Markus Neteler <neteler@itc.it> wrote:

My opinion is to not backport it but to use the available energy to prepare
a GRASS 6.1.0 release. Only then it can enter Debian etc.

Maybe people could indicate how far they see their contributions in terms
of sort-of-stability to create a release branch? I am not talking about
6.2.-stable,
just a somewhat reliable 6.1.0 release to illustrate the great new features
of 6.1.

I agree that we should start 6.2 release process soon. I would prefer however
to avoid to have 6.2 branch for a long time before 6.2.0 release.
Because we have usually problems to keep in sync bug fixes in more branches
as many occasional contributors do not follow the release process
or forget to commit bug fixes into both branches.

My suggestion is to prepare 6.2.0 release in HEAD and create the 6.2
branch in the moment of 6.2.0 release. In the perion 6.2 feature freeze
- 6.2.0 release all contributors should concentrate on bug fixing.

What features are missing for 6.2 feature freeze? GEM,... ?

Radim

7

What features are missing for 6.2 feature freeze?

I would like to include changes to allow symbol/icon drawing functions.
I have it working (called from d.graph), but a few structural things
remain to be finalized.

currently I have

int S_plot(SYMBOL *Symb, int x0, int y0,
       SYMBCOLOR *line_color, SYMBCOLOR *fill_color);

e.g.
Symb = S_read ( sname );
S_stroke ( Symb, size, rotation, tolerance );
S_plot(Symb, x0, y0, line_color, fill_color);

I also need to figure out how to do it without Vect_new_line_struct(),
Vect_append_point() etc to store polygon verticies as I don't want it
to depend on the vector lib, but they are oh so handy to use.

Hamish

8

From: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 28 Mar 2006 00:27:53 +1200
To: <grass5@grass.itc.it>
Subject: Re: [GRASS5] New GIS Manager

What features are missing for 6.2 feature freeze?

I would like to include changes to allow symbol/icon drawing functions.
I have it working (called from d.graph), but a few structural things
remain to be finalized.

currently I have

int S_plot(SYMBOL *Symb, int x0, int y0,
       SYMBCOLOR *line_color, SYMBCOLOR *fill_color);

e.g.
Symb = S_read ( sname );
S_stroke ( Symb, size, rotation, tolerance );
S_plot(Symb, x0, y0, line_color, fill_color);

I also need to figure out how to do it without Vect_new_line_struct(),
Vect_append_point() etc to store polygon verticies as I don't want it
to depend on the vector lib, but they are oh so handy to use.

Hamish

With the new work by Cedric Shock, the updated GIS Manager is in
considerable flux. I think that most of it will be ironed out soon. If we
don't count things to be fixed, I'd like to at least do the following:

Make a new GRASS start up.
Make sure that the GEM (GRASS extension manager) is working with the new
system.

If there is time before a feature freeze, a couple of important items that
need to be done include:

develop a non-xterm version of v.digit
develop a non-xterm version of i.points/v.points
develop a TclTk module that reads v.label files and places labels on the
screen in nice PS text (I think fairly easy).
There may be other things, but I don't want to get overambitious :wink:

We might also take this opportunity to think about the following (both of
which have been discussed):

replacing dbf with sqlite as the default attribute management system
changing the raster file architecture to something more along the lines of
the current vector file architecture.

Michael

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

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

9

On 3/28/06, Michael Barton <michael.barton@asu.edu> wrote:

>> What features are missing for 6.2 feature freeze?

With the new work by Cedric Shock, the updated GIS Manager is in
considerable flux. I think that most of it will be ironed out soon. If we
don't count things to be fixed, I'd like to at least do the following:

Make a new GRASS start up.
Make sure that the GEM (GRASS extension manager) is working with the new
system.

If there is time before a feature freeze, a couple of important items that
need to be done include:

develop a non-xterm version of v.digit
develop a non-xterm version of i.points/v.points
develop a TclTk module that reads v.label files and places labels on the
screen in nice PS text (I think fairly easy).
There may be other things, but I don't want to get overambitious :wink:

We might also take this opportunity to think about the following (both of
which have been discussed):

replacing dbf with sqlite as the default attribute management system
changing the raster file architecture to something more along the lines of
the current vector file architecture.

6.0.0 was released a year ago, so we need to create 6.2.0 soon
we cannot start now thinking about major database structure changes
or starting new features.
Especially changeing raster file structure without any format enhancement
would be contraproductive IMO regardless version. That would only
make headache for users. Glynn wants to implement a new raster
format (?) so any changes in raster files should wait for it.
Formats should not change in major release line so any change in
data format which is not backward compatible reults in 7.0.

I am not sure about sqlite, people reported that it is very slow for large
tables. Maybe it can be improved using precompiled queries.

I think that gis.m and GEM should be and 6.2 but we cannot wait
with 6.2 for features which were not even started (v.digit,i.points,...).

Can we start to think about feature freeze circa 30.4. ?

Radim

10

On Tue, Mar 28, 2006 at 10:02:23AM +0200, Radim Blazek wrote:

On 3/28/06, Michael Barton <michael.barton@asu.edu> wrote:
> >> What features are missing for 6.2 feature freeze?
>
> With the new work by Cedric Shock, the updated GIS Manager is in
> considerable flux. I think that most of it will be ironed out soon. If we
> don't count things to be fixed, I'd like to at least do the following:
>
> Make a new GRASS start up.
> Make sure that the GEM (GRASS extension manager) is working with the new
> system.
>
> If there is time before a feature freeze, a couple of important items that
> need to be done include:
>
> develop a non-xterm version of v.digit
> develop a non-xterm version of i.points/v.points
> develop a TclTk module that reads v.label files and places labels on the
> screen in nice PS text (I think fairly easy).
> There may be other things, but I don't want to get overambitious :wink:
>
> We might also take this opportunity to think about the following (both of
> which have been discussed):
>
> replacing dbf with sqlite as the default attribute management system
> changing the raster file architecture to something more along the lines of
> the current vector file architecture.

6.0.0 was released a year ago, so we need to create 6.2.0 soon
we cannot start now thinking about major database structure changes
or starting new features.

Do you want to skip 6.1.x releases? Why?
6.1 was never published so far.

Slightly confused,

Markus

11

On 3/28/06, Markus Neteler <neteler@itc.it> wrote:

> 6.0.0 was released a year ago, so we need to create 6.2.0 soon
> we cannot start now thinking about major database structure changes
> or starting new features.

Do you want to skip 6.1.x releases? Why?
6.1 was never published so far.

Slightly confused,

We need the feature freeze and then series of releases before 6.2.0.
I dont see a big difference between calling them 6.1.x or 6.2.0-rcx,
6.1.x could be released during the last year. We did not release them
so they are already skipped naturally.

Bernhard is expert in GRASS version numbers.

Radim

Markus

12

Radim Blazek wrote:

Especially changeing raster file structure without any format enhancement
would be contraproductive IMO regardless version. That would only
make headache for users. Glynn wants to implement a new raster
format (?) so any changes in raster files should wait for it.

Don't hold your breath; I'm thinking about a future raster format, but
it isn't going to happen soon.

I'm not sure what Michael meant by:

changing the raster file architecture to something more along the lines of
the current vector file architecture.

--
Glynn Clements <glynn@gclements.plus.com>

13

There has been discussion periodically about changing how raster files are
stored within mapsets. What I understood (perhaps incorrectly I suppose) was
that the idea was to store each map in a separate folder, like vectors,
rather than combine all raster cat files in one folder, header files in
another folder, and so on. This would make GRASS raster files much more
portable and easier to manipulate. However, there would need to be some way
to convert formats as between old and new vector formats.

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

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Tue, 28 Mar 2006 21:06:51 +0100
To: Radim Blazek <radim.blazek@gmail.com>
Cc: Michael Barton <michael.barton@asu.edu>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] features needed for 6.2

Radim Blazek wrote:

Especially changeing raster file structure without any format enhancement
would be contraproductive IMO regardless version. That would only
make headache for users. Glynn wants to implement a new raster
format (?) so any changes in raster files should wait for it.

Don't hold your breath; I'm thinking about a future raster format, but
it isn't going to happen soon.

I'm not sure what Michael meant by:

changing the raster file architecture to something more along the lines of
the current vector file architecture.

--
Glynn Clements <glynn@gclements.plus.com>

14

Michael Barton wrote:

There has been discussion periodically about changing how raster files are
stored within mapsets. What I understood (perhaps incorrectly I suppose) was
that the idea was to store each map in a separate folder, like vectors,
rather than combine all raster cat files in one folder, header files in
another folder, and so on. This would make GRASS raster files much more
portable and easier to manipulate. However, there would need to be some way
to convert formats as between old and new vector formats.

OK, that makes sense.

It's also completely orthogonal to any changes which I was considering
regarding the actual raster format.

But, I think that it's the kind of thing which needs to be done at the
start of a revision cycle, i.e. not in 6.2.0 but at the beginning of
6.3cvs. If you try to do it for 6.2.0, it's going to either push 6.2.0
back to next year or make 6.2.0 too buggy for actual use.

--
Glynn Clements <glynn@gclements.plus.com>

15

OK. That makes sense. It got put off in the transition to 6 and I just
wanted to make sure that people didn't forget about it.

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

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Wed, 29 Mar 2006 00:55:00 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Radim Blazek <radim.blazek@gmail.com>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] features needed for 6.2

Michael Barton wrote:

There has been discussion periodically about changing how raster files are
stored within mapsets. What I understood (perhaps incorrectly I suppose) was
that the idea was to store each map in a separate folder, like vectors,
rather than combine all raster cat files in one folder, header files in
another folder, and so on. This would make GRASS raster files much more
portable and easier to manipulate. However, there would need to be some way
to convert formats as between old and new vector formats.

OK, that makes sense.

It's also completely orthogonal to any changes which I was considering
regarding the actual raster format.

But, I think that it's the kind of thing which needs to be done at the
start of a revision cycle, i.e. not in 6.2.0 but at the beginning of
6.3cvs. If you try to do it for 6.2.0, it's going to either push 6.2.0
back to next year or make 6.2.0 too buggy for actual use.

--
Glynn Clements <glynn@gclements.plus.com>

16

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+.

I think we agree that a 6.1.0 development release is a good idea and
should happen soon. This should be a CVS-HEAD tag and not its own
branch; aka the first beta release for what will be 6.2.0. We can
declare a feature freeze upon its release and then start working towards
something that will be 6.2.0-rc1. We stay in CVS-HEAD, no new branch is
created until we release 6.2.0-final. I think things worked really well
for the 6.0 release, with 5.1.0 etc, much better than I hoped actually.
After 6.1.0 it doesn't matter if we call it 6.1.1, 6.1.2, 6.1.3, ...; or
6.2.0rc1, 6.2.0rc2, 6.2.0rc3, ...; but I think 6.2rcX is more motivating
& focusing.

If we want, a feature freeze could be slushy -- minor features already
discussed but not yet fully coded and minor module enhancements could be
included for a time. Another possibility is to freeze the libs/core a
month before the modules or something.

I don't know what the GUI schedule looks like, but if the larger dust
starts to settle in two weeks time* (April 14), we should leave it
another 2 weeks to fix any bugs, then release 6.1.0 on April 30 and
declare a major-feature freeze in effect for the 6.2.0 release. We can
start monthly 6.2-rcX releases after that and look to a 6.2.0 release
after say rc5, in September or October. Sooner if it becomes obvious
that no more work is needed.
[*] Michael: is that realistic?

Details & issues:

Consensus is to include GEM and gis.m in 6.2.0. It would be nice 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.

Restructuring of the raster elements into a $MAPSET/raster/ dir means a
break to GRASS 7.0. It makes sense that this should happen in
combination with and at the same time as a revamp of the raster format
itself. That way we only have to do the transition once. (otherwise we
have GRASS 8.0, four times the backwards incompatibility ugliness, etc.)
Glynn: If you were to take this on, how does Oct-Dec this year sound for
starting work? "2007"? "2012"?

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. 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 it needs
to be default, so if consensus is that it should be default 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?

d.m & gis.m: The day after 6.1.0 is released make gis.m the default GUI.
Keep d.m around until just after 6.2.0 is released.

gis.m GUI improvements (ie labels, etc) can probably keep happening
until about 8 weeks before final 6.2 release. ie (hypothetically) until
6.2.0-rc3 is released. lib/gis/parser.c changes need to freeze by 6.2rc1
I think.

d.out.png: Keep until the day after 6.2.0 is released. (user scripts)

Radim: anything big changes on the horizon needed for QGIS or the
Windows port? It would be a nice bullet point for all 6.2.0 core modules
(r.*, v.*, g.*) to work on windows native, but I don't think 6.2.0
should wait for it.

---

If he is happy to do so, I hope Markus will remain as release manager
and generally as the arbitrator in charge of final decisions.

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.

???

Hamish

17

I agree with everything except 'slushy feature freeze' - it simply
is not feature freeze and we would just continue in development
next year. So I support TRUE feature freeze on april 30
and 6.1.0 release the same day.
If a realy important new feature appeares after the feature freeze it must
be discussed in the list and it can be added only after general concensus.

6.2.0 should be natively ported on Windows but without d.* modules.

I am not aware of missing features necessary for QGIS
or other third party applications.

Radim

On 3/29/06, Hamish <hamish_nospam@yahoo.com> 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+.

I think we agree that a 6.1.0 development release is a good idea and
should happen soon. This should be a CVS-HEAD tag and not its own
branch; aka the first beta release for what will be 6.2.0. We can
declare a feature freeze upon its release and then start working towards
something that will be 6.2.0-rc1. We stay in CVS-HEAD, no new branch is
created until we release 6.2.0-final. I think things worked really well
for the 6.0 release, with 5.1.0 etc, much better than I hoped actually.
After 6.1.0 it doesn't matter if we call it 6.1.1, 6.1.2, 6.1.3, ...; or
6.2.0rc1, 6.2.0rc2, 6.2.0rc3, ...; but I think 6.2rcX is more motivating
& focusing.

If we want, a feature freeze could be slushy -- minor features already
discussed but not yet fully coded and minor module enhancements could be
included for a time. Another possibility is to freeze the libs/core a
month before the modules or something.

I don't know what the GUI schedule looks like, but if the larger dust
starts to settle in two weeks time* (April 14), we should leave it
another 2 weeks to fix any bugs, then release 6.1.0 on April 30 and
declare a major-feature freeze in effect for the 6.2.0 release. We can
start monthly 6.2-rcX releases after that and look to a 6.2.0 release
after say rc5, in September or October. Sooner if it becomes obvious
that no more work is needed.
[*] Michael: is that realistic?

Details & issues:

Consensus is to include GEM and gis.m in 6.2.0. It would be nice 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.

Restructuring of the raster elements into a $MAPSET/raster/ dir means a
break to GRASS 7.0. It makes sense that this should happen in
combination with and at the same time as a revamp of the raster format
itself. That way we only have to do the transition once. (otherwise we
have GRASS 8.0, four times the backwards incompatibility ugliness, etc.)
Glynn: If you were to take this on, how does Oct-Dec this year sound for
starting work? "2007"? "2012"?

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. 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 it needs
to be default, so if consensus is that it should be default 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?

d.m & gis.m: The day after 6.1.0 is released make gis.m the default GUI.
Keep d.m around until just after 6.2.0 is released.

gis.m GUI improvements (ie labels, etc) can probably keep happening
until about 8 weeks before final 6.2 release. ie (hypothetically) until
6.2.0-rc3 is released. lib/gis/parser.c changes need to freeze by 6.2rc1
I think.

d.out.png: Keep until the day after 6.2.0 is released. (user scripts)

Radim: anything big changes on the horizon needed for QGIS or the
Windows port? It would be a nice bullet point for all 6.2.0 core modules
(r.*, v.*, g.*) to work on windows native, but I don't think 6.2.0
should wait for it.

---

If he is happy to do so, I hope Markus will remain as release manager
and generally as the arbitrator in charge of final decisions.

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.

???

Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

18

Hamish wrote:

Restructuring of the raster elements into a $MAPSET/raster/ dir means a
break to GRASS 7.0. It makes sense that this should happen in
combination with and at the same time as a revamp of the raster format
itself. That way we only have to do the transition once.

I disagree. Switching the raster directory layout is much simpler than
a new raster format. With the former, it's clear what needs to be
done; it's just a matter of doing it.

(otherwise we
have GRASS 8.0, four times the backwards incompatibility ugliness, etc.)
Glynn: If you were to take this on, how does Oct-Dec this year sound for
starting work? "2007"? "2012"?

It isn't something which can be done to a timescale. The complexity is
in the design, not the implementation. Every now and then, I revisit
the idea. Hopefully, I'll come up with a workable design eventually,
but I have no idea when.

FWIW, my main goals for a new raster architecture are:

1. Tiled storage. It should be practical to create a single global
lat/lon location, read in all of the ETOPO30 DEMs, patch them together
into a single 43200 x 21600 map, and use it (currently, you have to
decompress an entire row even if you only use a small portion of it).

2. A new API which allows modules to treat a raster essentially as a
2D/3D array, without having to explicitly read rows or use the rowio
or segment libraries.

3. Compatibility. Both the row-oriented and array-model APIs would
need to work with both the old (row-based) and new (tiled) formats.

4. Efficiency.

Point 4 is the hard part.

Both raw and "cooked" (decoded and rescaled) data may need to be
cached (for modules like r.proj, r.cost) or not (for conventional
top-to-bottom, left-to-right processing).

The optimal rescaling algorithm depends upon whether you are scaling
up (every input cell is used, possibly duplicated) or down (some input
cells are ignored, those which are used are only used once), and
whether your are using linear, near-linear or random access.

The optimal block sizes and data formats (those used for storage and
those presented to the application) may vary between applications, yet
fixing those parameters at compile time will, in general, be more
efficient.

I don't want to hand-code optimal algorthims for all of the various
combinations of parameters, but I don't particularly want to
complicate the code by using machine-generated code (e.g. extensive
preprocessing or C++ templates) either.

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.

There's no reason why Tcl/Tk versions can't sit alongside the existing
implementations. The R_get_location_with_* functions can't be removed
until GRASS is basically usable without them.

--
Glynn Clements <glynn@gclements.plus.com>

19

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 nice 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 it needs
to be default, so if consensus is that it should be default 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 decisions.

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 the office
now). Large file is causing problems, Glynn had commented on this but
then the issue disappeared. Maybe his grass-header-fix script could also
do the config.h trick which he suggested?

Markus

20

This sounds like a good plan to me.

MIchael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

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

From: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 29 Mar 2006 19:49:32 +1200
To: <grass5@grass.itc.it>
Subject: Re: [GRASS5] features needed for 6.2

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+.

I think we agree that a 6.1.0 development release is a good idea and
should happen soon. This should be a CVS-HEAD tag and not its own
branch; aka the first beta release for what will be 6.2.0. We can
declare a feature freeze upon its release and then start working towards
something that will be 6.2.0-rc1. We stay in CVS-HEAD, no new branch is
created until we release 6.2.0-final. I think things worked really well
for the 6.0 release, with 5.1.0 etc, much better than I hoped actually.
After 6.1.0 it doesn't matter if we call it 6.1.1, 6.1.2, 6.1.3, ...; or
6.2.0rc1, 6.2.0rc2, 6.2.0rc3, ...; but I think 6.2rcX is more motivating
& focusing.

If we want, a feature freeze could be slushy -- minor features already
discussed but not yet fully coded and minor module enhancements could be
included for a time. Another possibility is to freeze the libs/core a
month before the modules or something.

I don't know what the GUI schedule looks like, but if the larger dust
starts to settle in two weeks time* (April 14), we should leave it
another 2 weeks to fix any bugs, then release 6.1.0 on April 30 and
declare a major-feature freeze in effect for the 6.2.0 release. We can
start monthly 6.2-rcX releases after that and look to a 6.2.0 release
after say rc5, in September or October. Sooner if it becomes obvious
that no more work is needed.
[*] Michael: is that realistic?

Details & issues:

Consensus is to include GEM and gis.m in 6.2.0. It would be nice 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.

Restructuring of the raster elements into a $MAPSET/raster/ dir means a
break to GRASS 7.0. It makes sense that this should happen in
combination with and at the same time as a revamp of the raster format
itself. That way we only have to do the transition once. (otherwise we
have GRASS 8.0, four times the backwards incompatibility ugliness, etc.)
Glynn: If you were to take this on, how does Oct-Dec this year sound for
starting work? "2007"? "2012"?

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. 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 it needs
to be default, so if consensus is that it should be default 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?

d.m & gis.m: The day after 6.1.0 is released make gis.m the default GUI.
Keep d.m around until just after 6.2.0 is released.

gis.m GUI improvements (ie labels, etc) can probably keep happening
until about 8 weeks before final 6.2 release. ie (hypothetically) until
6.2.0-rc3 is released. lib/gis/parser.c changes need to freeze by 6.2rc1
I think.

d.out.png: Keep until the day after 6.2.0 is released. (user scripts)

Radim: anything big changes on the horizon needed for QGIS or the
Windows port? It would be a nice bullet point for all 6.2.0 core modules
(r.*, v.*, g.*) to work on windows native, but I don't think 6.2.0
should wait for it.

---

If he is happy to do so, I hope Markus will remain as release manager
and generally as the arbitrator in charge of final decisions.

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.

???

Hamish