[GRASS5] Temporal data in GRASS?

GRASS GRASS developer
1

Greetings,

I'm interested in working with some GIS data that has a rather dynamic
temporal element. For example, I plan to record the location of
various moving objects, (via GPS), and later I'd like to replay this
data in GRASS.

I've considered doing something as simple as storing timestamped data
in a database and looping through the query results, displaying
successive images. But, I wonder if a more integrated solution might
not be more desirable.

From what I've seen so far, I haven't seen anything in GRASS that
deals with temporal data. (But I am a total newbie to GIS and GRASS so
I may have missed something obvious, just let me know.) I can imagine
many applications that have temporal elements, (ie. changes with
seasons, or from year to year). How have users of GRASS typically
dealt with these kinds of data?

If the current GRASS support isn't sufficient for what I need, then I
plan to implement whatever it takes. I'm an experienced C programmer,
and there are a couple of projects here at ISI that could benefit
from this. I would be interested to hear suggestions from more
experienced GRASS developers on what the right approach might be to
incorporate this into GRASS.

Thanks,

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

2

Hi Carl,

On Wed, Oct 24, 2001 at 11:44:10AM -0400, Carl Worth wrote:

Greetings,

I'm interested in working with some GIS data that has a rather dynamic
temporal element. For example, I plan to record the location of
various moving objects, (via GPS), and later I'd like to replay this
data in GRASS.

I've considered doing something as simple as storing timestamped data
in a database and looping through the query results, displaying
successive images. But, I wonder if a more integrated solution might
not be more desirable.

>From what I've seen so far, I haven't seen anything in GRASS that
deals with temporal data. (But I am a total newbie to GIS and GRASS so
I may have missed something obvious, just let me know.) I can imagine
many applications that have temporal elements, (ie. changes with
seasons, or from year to year). How have users of GRASS typically
dealt with these kinds of data?

well, currently only two modules are present
r.timestamp
v.timestamp

The sites (point data) format also support timestamps.

Then the "xganim" module allows to play selected raster maps as
film sequence (note, just fixed in CVS).

If the current GRASS support isn't sufficient for what I need, then I
plan to implement whatever it takes. I'm an experienced C programmer,
and there are a couple of projects here at ISI that could benefit
from this. I would be interested to hear suggestions from more
experienced GRASS developers on what the right approach might be to
incorporate this into GRASS.

This sounds very good. We are quite interested to fully support
timestamps in GRASS. A suggestion could be to extend i.group
(or develop a new module) to group maps according to timestamps
for later analysis, display or whatever.

Here at ITC we intend to improve the multitemporal image processing
features, but a general implementation would be the best. GRASS 5
provides a DateTime library, most (all?) required functions should
be available on library level. Now it is time to extend the
appropriate GRASS modules.

Have a look at the Programmer's Manual to read about the DateTime.
http://grass.itc.it/grassdevel.html#prog

Please let us know your needs.

I would appreciate a collaboration,

best regards

Markus Neteler

3

Markus Neteler wrote:

Hi Carl,

On Wed, Oct 24, 2001 at 11:44:10AM -0400, Carl Worth wrote:
> Greetings,
>
> I'm interested in working with some GIS data that has a rather dynamic
> temporal element. For example, I plan to record the location of
> various moving objects, (via GPS), and later I'd like to replay this
> data in GRASS.
>
> I've considered doing something as simple as storing timestamped data
> in a database and looping through the query results, displaying
> successive images. But, I wonder if a more integrated solution might
> not be more desirable.
>
> >From what I've seen so far, I haven't seen anything in GRASS that
> deals with temporal data. (But I am a total newbie to GIS and GRASS so
> I may have missed something obvious, just let me know.) I can imagine
> many applications that have temporal elements, (ie. changes with
> seasons, or from year to year). How have users of GRASS typically
> dealt with these kinds of data?

Carl,

I have been working with temporal data in GRASS for many years - mostly in
the area
of spatio-temporal interpolation, simulation of landscape processes and
visualization.
You can see some examples at
http://skagit.meas.ncsu.edu/~helena/gmslab/
e.g. http://skagit.meas.ncsu.edu/~helena/gmslab/viz/erosion.html has
simulation of water
and sediment flow as well as insolation during winter and summer solstice
http://skagit.meas.ncsu.edu/~helena/gmslab/viz/sinter.html has rainfall as
it changes during the year
as well as change in pollutants in groundwater and in Chesapeake bay.
Currently I am looking at a time series of 20 years of bathymetry data and
temporal changes in topography
and water flow pattern due to development.
You can represent time either through a time stamp for raster, vector and
ite data, but if you have a moving
object time can be assigned as a string attribute (I think that we do not
have a specific time attribute) for each
site. There is a need to add the time display capability to other modules
such as d.rast, d.vect, xganim and nviz
as well as create tools for seraching and queriyng the temporal data sets
based on the time stamp
(for example I may want to extract the bathymetry data from my 130 files
time series for the dates
when there were big storms). So it would be wonderful if you could
contribute some capabilities, because the
development of time-related capabilities stopped about 5 years ago and many
people would welcome if
somebdoy could take it over. You can have a quick look at the Date-Time
library html docs at
http://skagit.meas.ncsu.edu/~helena/gmslab/htdoc/
(but then you would have to go to the programers manual as suggested by
Markus, it is in PDF or LATEX)
For the moving objects - especially of you have more of them moving at the
same time you can transform them
to raster (s.to.rast) and then animate them by xganim, however, as I am
writing this I remembered that for
the groudwater pollutants data Bill modified display of sites in SG3d so
that it is drawn as it was measured,
so that you can observe where you have a big time gaps in measurements etc.
But I am not sure where that
piece of code is. It would be nice to add it to nviz. If you have any
questions you can email me.

Helena

well, currently only two modules are present
r.timestamp
v.timestamp

The sites (point data) format also support timestamps.

Then the "xganim" module allows to play selected raster maps as
film sequence (note, just fixed in CVS).

> If the current GRASS support isn't sufficient for what I need, then I
> plan to implement whatever it takes. I'm an experienced C programmer,
> and there are a couple of projects here at ISI that could benefit
> from this. I would be interested to hear suggestions from more
> experienced GRASS developers on what the right approach might be to
> incorporate this into GRASS.

This sounds very good. We are quite interested to fully support
timestamps in GRASS. A suggestion could be to extend i.group
(or develop a new module) to group maps according to timestamps
for later analysis, display or whatever.

Here at ITC we intend to improve the multitemporal image processing
features, but a general implementation would be the best. GRASS 5
provides a DateTime library, most (all?) required functions should
be available on library level. Now it is time to extend the
appropriate GRASS modules.

Have a look at the Programmer's Manual to read about the DateTime.
http://grass.itc.it/grassdevel.html#prog

Please let us know your needs.

I would appreciate a collaboration,

best regards

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

4

Markus and Helena,

Thanks for your quick feedback -- I think it will be very helpful.

I wasn't aware of xganim before, so I'll look at that and hopefully it
will do the trick for me.

Thanks for the pointers to the DateTime library. It's exactly what I
was hoping for, (a data structure with either absolute or relative
time values). The TimeStamp structure is also exactly what I had hoped
it would be, (either a point time or a range).

To summarize, it sounds like the database has slots for TimeStamps in
several places, but that support could be extended in several
places. Also, the ability to query/organize data based on time, and to
display the time seems to be missing. I'll take it on myself to start
improving these areas.

At the same time, I'd like to improve the UI of GRASS in several
areas. I'm running GRASS on a handheld computer and it would be very
nice if the major functionality were available using a stylus,
(ie. single-button pointer device), and no requirement for a
keyboard. I also have some simple ideas to improve cosmetics, (ie. add
support for TrueType fonts using Xft and the RENDER extension in X).

Meanwhile, I'm still getting my feet wet in the GRASS/GIS realm. I've
successfully imported lots of DEM and DLG/SDTS data that I fetched
from the USGS.

I have not yet been successful in importing DRG data in GeoTIFF format
though. I can use "r.in.tiff -v" and see that it finds the .tfw file
and appears to load just fine. But d.rast simply displays a solid
white image and d.histogram segfaults after displaying the title. Any
ideas what I might have screwed up or what I could look into to
diagnose this? (I'm using 0.5pre2 currently, but I'll probably jump to
the head of CVS next).

Thanks!

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

5

On Thu, 25 Oct 2001, Carl Worth wrote:

Markus and Helena,

Thanks for your quick feedback -- I think it will be very helpful.

Thanks for the pointers to the DateTime library. It's exactly what I
was hoping for, (a data structure with either absolute or relative
time values). The TimeStamp structure is also exactly what I had hoped
it would be, (either a point time or a range).

To summarize, it sounds like the database has slots for TimeStamps in
several places, but that support could be extended in several
places. Also, the ability to query/organize data based on time, and to
display the time seems to be missing. I'll take it on myself to start
improving these areas.

I'm sure many of us will find this useful! A concern that I have is that
there are different time/date standards (in operating systems, in database
systems, POSIX, etc.). There is a very good survey in:

@Article{Rnews:Ripley+Hornik:2001,
  author = {Brian D. Ripley and Kurt Hornik},
  title = {Date-Time Classes},
  journal = {R News},
  year = 2001,
  volume = 1,
  number = 2,
  pages = {8--11},
  month = {June},
  url = {http://CRAN.R-project.org/doc/Rnews/\},
}

(that's R-News of the R data analysis community) which may help in
revisiting the code in GRASS. The R code may also be useful in seeing how
to match different systems' assumptions about time through the autoconf
system for compilation. In addition, the R code is GPL, so maybe some of
it may be of direct use - R-1.3.1/src/main/datetime.c makes interesting
reading, and is more up-to-date (I feel) than what you see in
src/libes/datetime/. Certainly the discussion in R-News seems based on
hard-won experience!

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.

6

Hi Carl,

On Thu, Oct 25, 2001 at 01:12:30PM -0400, Carl Worth wrote:

Markus and Helena,

Thanks for your quick feedback -- I think it will be very helpful.

[...]

At the same time, I'd like to improve the UI of GRASS in several
areas. I'm running GRASS on a handheld computer and it would be very
nice if the major functionality were available using a stylus,
(ie. single-button pointer device), and no requirement for a
keyboard. I also have some simple ideas to improve cosmetics, (ie. add
support for TrueType fonts using Xft and the RENDER extension in X).

I have just added from the exp tree (unused/ section) a module
from Huidae Cho:
src/display/d.text.freetype

It is not activated in the compile list due to it's freetype dependencies,
but may be a good starting point for further developments.

Meanwhile, I'm still getting my feet wet in the GRASS/GIS realm. I've
successfully imported lots of DEM and DLG/SDTS data that I fetched
from the USGS.

I have not yet been successful in importing DRG data in GeoTIFF format
though. I can use "r.in.tiff -v" and see that it finds the .tfw file
and appears to load just fine. But d.rast simply displays a solid
white image and d.histogram segfaults after displaying the title. Any
ideas what I might have screwed up or what I could look into to
diagnose this? (I'm using 0.5pre2 currently, but I'll probably jump to
the head of CVS next).

In general you should give
r.in.gdal
a try. It supports a large range of formats. But, first, you may
try to zoom the raster map:

g.region rast=imported_map
d.erase
d.rast ...
d.histogram ...

All GRASS raster commands shall be region sensitive.
Then: file system full? I had such related problems with i.rectify,
not mentioning that the .tmp/ was temporarily flooded...

Best regards

Markus

7

Markus Neteler writes:
> I have just added from the exp tree (unused/ section) a module
> from Huidae Cho:
> src/display/d.text.freetype

Excellent, I'll have a look at this.

> In general you should give r.in.gdal a try. It supports a large
> range of formats. But, first, you may try to zoom the raster map:
>
> g.region rast=imported_map

Whoops... that was my problem. Somehow I thought my elevation and map
data were for the exact same region, but I guess not. I feel foolish.

Well, thanks for the help. :slight_smile:

-Carl

8

Markus Neteler wrote:

I have just added from the exp tree (unused/ section) a module
from Huidae Cho:
src/display/d.text.freetype

It is not activated in the compile list due to it's freetype dependencies,
but may be a good starting point for further developments.

There are a few other issues, e.g. hardcoding the charset to EUC-KR,
requiring iconv() to live in non-standard headers/libraries etc.

I'm currently adding freetype detection to configure, and working on
the portability issues.

--
Glynn Clements <glynn.clements@virgin.net>

9

Carl Worth writes:
> Markus Neteler writes:
> > g.region rast=imported_map
>
> Whoops... that was my problem. Somehow I thought my elevation and map
> data were for the exact same region, but I guess not. I feel foolish.

I'm making headway, but I'm also causing new problems.

My two datasets *are* both for the same region -- the problem was that
the data were in two different projections, (UTM vs. Albers Equal
Area). I've now got each one imported into its own location and I can
view each one separately just fine.

But, of course, I'd like to see them together, so I need to transform
one into the projection of the other. r.proj looks to fit the bill
exactly, but I'm getting the following:

  GRASS > r.proj input=amap location=albers
  cannot initialize pj
  cause: projection not named
  ERROR: Can't get projection key values of output map

My current location seems to have a well-defined projection:

  PROJECTION: 1 (UTM)
  DATUM: NAD27
  ELLIPSOID: clrk66

so what could I be missing?

...

Hmmm... I'm stepping through r.proj in gdb now. It looks like if
PROJ_INFO has one of "name", "tinit", or "sproj" that I might get past
the current problem. So what would I name my projection? Maybe "name:
utm". With that I now get:

  cannot initialize pj
  cause: major axis or radius = 0 or not given
  ERROR: Can't get projection key values of output map

Now it appears to be trying to load some projection parameters based
on the name of my projection. It's trying to look in PROJ_LIB, (which
is not set). I'm feeling like I must not have installed something...

Hmm... programmers manual talks about PROJ4. Do I have to install that
separately?

I'll keep poking.

Any light that could be shed would be most appreciated.

-Carl (Who is anxious to start contributing rather than continually
exposing his ignorance in public forums)

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

10

On Fri, 26 Oct 2001 17:19:14 -0400, Carl Worth <cworth@east.isi.edu> wrote:

Carl Worth writes:
> Markus Neteler writes:
> > g.region rast=imported_map
>
> Whoops... that was my problem. Somehow I thought my elevation and map
> data were for the exact same region, but I guess not. I feel foolish.

I'm making headway, but I'm also causing new problems.

My two datasets *are* both for the same region -- the problem was that
the data were in two different projections, (UTM vs. Albers Equal
Area). I've now got each one imported into its own location and I can
view each one separately just fine.

But, of course, I'd like to see them together, so I need to transform
one into the projection of the other. r.proj looks to fit the bill
exactly, but I'm getting the following:

  GRASS > r.proj input=amap location=albers
  cannot initialize pj
  cause: projection not named
  ERROR: Can't get projection key values of output map

I'm guessing you imported your data with r.in.gdal? Recently there
have been some changes to fix the problem of not completely defining
the region when r.in.gdal creates a new location. You can probably
fix it by running g.setproj with the correct parameters. Otherwise,
please try the new r.in.gdal in CVS.

--
Eric G. Miller <egm2@jps.net>

11

On Fri, Oct 26, 2001 at 05:52:58PM -0700, Eric G. Miller wrote:

On Fri, 26 Oct 2001 17:19:14 -0400, Carl Worth <cworth@east.isi.edu> wrote:

> Carl Worth writes:
> > Markus Neteler writes:
> > > g.region rast=imported_map
> >
> > Whoops... that was my problem. Somehow I thought my elevation and map
> > data were for the exact same region, but I guess not. I feel foolish.
>
> I'm making headway, but I'm also causing new problems.
>
> My two datasets *are* both for the same region -- the problem was that
> the data were in two different projections, (UTM vs. Albers Equal
> Area). I've now got each one imported into its own location and I can
> view each one separately just fine.
>
> But, of course, I'd like to see them together, so I need to transform
> one into the projection of the other. r.proj looks to fit the bill
> exactly, but I'm getting the following:
>
> GRASS > r.proj input=amap location=albers
> cannot initialize pj
> cause: projection not named
> ERROR: Can't get projection key values of output map

I'm guessing you imported your data with r.in.gdal? Recently there
have been some changes to fix the problem of not completely defining
the region when r.in.gdal creates a new location. You can probably
fix it by running g.setproj with the correct parameters. Otherwise,
please try the new r.in.gdal in CVS.

Hi Carl,

a confirmation: Yes, please use the current CVS version. All
others may fail. The problem is that GRASS still uses the older
PROJ4 with additional private definitions not supported by PROJ4.
These inconsistencies have been "work-arounded" last week (in CVS).

The new 5.1 will be fully synchronized with PROJ4, maybe PROJ4
will be extended for that (according to Frank Warmerdam).

So, please update and re-import, then everything should be
fine. If not, it will be another bug to be fixed.

Best regards
Markus

12

Markus Neteler writes:
> On Fri, Oct 26, 2001 at 05:52:58PM -0700, Eric G. Miller wrote:
> > I'm guessing you imported your data with r.in.gdal? Recently there
> > have been some changes to fix the problem of not completely defining
> > the region when r.in.gdal creates a new location. You can probably
> > fix it by running g.setproj with the correct parameters. Otherwise,
> > please try the new r.in.gdal in CVS.
>
> a confirmation: Yes, please use the current CVS version. All
> others may fail.

Thanks for your correct diagnosis. I had indeed created my location
using r.in.gdal.

I tried to update to the latest cvs, but I didn't see any
improvement. I updated to the head of the tree using "cvs update -Ad".
Do I actually want to be on a branch instead?

I tried to use g.setproj to fix things but it croaked:

  Would you still like to change some of the parameters (y/n) [n] y
  Do you want to specify a map datum for this location?(y/n) [n] y
  
  Please specify datum name
  Enter 'list' for the list of available datums
  Hit RETURN to cancel request
  >nad27
  ERROR: invalid input ellipsoid

The significant thing to notice here is that it never printed the
current ellipsoid, nor did it prompt for me to change the ellipsoid.

By manually creating a location and comparing the PROJ_INFO files I
could see that many parameters were missing from the one created by
r.in.gdal. And worse, it had "ellps: clrk66" rather than "ellps:
clark66". I don't know who's fault that was. But after I changed that
manually, I was able to get g.setproj to straighten things out for
me.

So, it looks like g.setproj needs to be fixed to prompt to change the
ellipsoid if the current one is invalid.

Anyway, I'm up and running now, (except for the CVS issue), so thanks
for the help.

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

13

On Mon, 29 Oct 2001 10:31:37 -0500, Carl Worth <cworth@east.isi.edu> wrote:

I tried to update to the latest cvs, but I didn't see any
improvement. I updated to the head of the tree using "cvs update -Ad".
Do I actually want to be on a branch instead?

You want to be using the tagged branch "releasebranch_11_april_2001_5_0_0"

I tried to use g.setproj to fix things but it croaked:

  Would you still like to change some of the parameters (y/n) [n] y
  Do you want to specify a map datum for this location?(y/n) [n] y
  
  Please specify datum name
  Enter 'list' for the list of available datums
  Hit RETURN to cancel request
  >nad27
  ERROR: invalid input ellipsoid

The significant thing to notice here is that it never printed the
current ellipsoid, nor did it prompt for me to change the ellipsoid.

It should have prompted for the ellipsoid before prompting for the
datum (actually, it should prompt for one or the other, but that's
not how it is currently written).

By manually creating a location and comparing the PROJ_INFO files I
could see that many parameters were missing from the one created by
r.in.gdal. And worse, it had "ellps: clrk66" rather than "ellps:
clark66". I don't know who's fault that was. But after I changed that
manually, I was able to get g.setproj to straighten things out for
me.

No. "clrk66" is correct. Don't ask me why...

So, it looks like g.setproj needs to be fixed to prompt to change the
ellipsoid if the current one is invalid.

Anyway, I'm up and running now, (except for the CVS issue), so thanks
for the help.

Perhaps you've been using the main branch, which is way behind the
tagged branch above. Changing that should make a significant
difference in all kinds of programs. Perhaps that needs to be
publicized on the web pages better?

--
Eric G. Miller <egm2@jps.net>

14

Eric G. Miller writes:
> You want to be using the tagged branch "releasebranch_11_april_2001_5_0_0"

Ah, thank you! That should change things considerably.

> Perhaps you've been using the main branch, which is way behind the
> tagged branch above. Changing that should make a significant
> difference in all kinds of programs. Perhaps that needs to be
> publicized on the web pages better?

Yes, I was on the main branch. What is it good for by the way?

The web pages do have some attempts to guide me the right
direction. For example, grasscvs.html says:

  Be sure to get the latest code: List of GRASS CVS branches

With a link to grasscvstags.html. That page does have a boxed and
highlighted message around the correct branch name, but somehow I was
still misled by the text "To check out the latest code within the
release branch".

I guess the qualifier, "within the release branch" made me think I
might not be getting the latest-and-greatest, so I tried the head of
the tree instead.

Maybe some text at the top of grasscvstags.html page describing how
the GRASS project uses tags would be helpful, (many different projects
use cvs tags in remarkably different ways).

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

15

Hi Carl,

Carl Worth wrote:

Markus Neteler writes:
> On Fri, Oct 26, 2001 at 05:52:58PM -0700, Eric G. Miller wrote:
> > I'm guessing you imported your data with r.in.gdal? Recently there
> > have been some changes to fix the problem of not completely defining
> > the region when r.in.gdal creates a new location. You can probably
> > fix it by running g.setproj with the correct parameters. Otherwise,
> > please try the new r.in.gdal in CVS.
>
> a confirmation: Yes, please use the current CVS version. All
> others may fail.

Thanks for your correct diagnosis. I had indeed created my location
using r.in.gdal.

I tried to update to the latest cvs, but I didn't see any
improvement. I updated to the head of the tree using "cvs update -Ad".
Do I actually want to be on a branch instead?

I tried to use g.setproj to fix things but it croaked:

        Would you still like to change some of the parameters (y/n) [n] y
        Do you want to specify a map datum for this location?(y/n) [n] y

        Please specify datum name
        Enter 'list' for the list of available datums
        Hit RETURN to cancel request
        >nad27
        ERROR: invalid input ellipsoid

The significant thing to notice here is that it never printed the
current ellipsoid, nor did it prompt for me to change the ellipsoid.

The current g.setproj is a very ugly hack and is planned to be rewritten
in GRASS 5.1. I just introduced the datum stuff without considering that
it may break other things.
I think the problem you experience is because g.setproj does not allow
to change to a datum with a different ellipsoid (so in fact it does not
allow you to really change the map datum...).
The very short way to change the map datum is to hand-edit the PROJ_INFO
file for a valid datum from $GISBASE/etc/datum.table. But you are on
your own with that. Or you may remove the ellipsoid and datum entries
from the file and re-run g.setproj to update.

Btw. i think GRASS uses clark66, please compare with the
$GISBASE/etc/ellipse.table file.

By manually creating a location and comparing the PROJ_INFO files I
could see that many parameters were missing from the one created by
r.in.gdal. And worse, it had "ellps: clrk66" rather than "ellps:
clark66". I don't know who's fault that was. But after I changed that
manually, I was able to get g.setproj to straighten things out for
me.

So, it looks like g.setproj needs to be fixed to prompt to change the
ellipsoid if the current one is invalid.

r.in.gdal needs to be fixed to read the ellipsoid from
$GISBASE/etc/ellipse.table.

HTH,

Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net

16

On Mon, Oct 29, 2001 at 11:01:27AM -0500, Carl Worth wrote:

Eric G. Miller writes:
> You want to be using the tagged branch "releasebranch_11_april_2001_5_0_0"

Ah, thank you! That should change things considerably.

> Perhaps you've been using the main branch, which is way behind the
> tagged branch above. Changing that should make a significant
> difference in all kinds of programs. Perhaps that needs to be
> publicized on the web pages better?

Yes, I was on the main branch. What is it good for by the way?

The web pages do have some attempts to guide me the right
direction. For example, grasscvs.html says:

  Be sure to get the latest code: List of GRASS CVS branches

With a link to grasscvstags.html. That page does have a boxed and
highlighted message around the correct branch name, but somehow I was
still misled by the text "To check out the latest code within the
release branch".

I guess the qualifier, "within the release branch" made me think I
might not be getting the latest-and-greatest, so I tried the head of
the tree instead.

Maybe some text at the top of grasscvstags.html page describing how
the GRASS project uses tags would be helpful, (many different projects
use cvs tags in remarkably different ways).

Hi Carl,

I would be glad if you send the grasscvstags.html page improved/updated
to me (either html or plain text pieces). I know that it is still
confusing (and I know that I prefer not to have branches in grass51/),
but I need assistance to get grasscvstags.html really useful.

If you don't mind, send some modifications,

thanks

Markus

17

Andreas Lange wrote:

So, it looks like g.setproj needs to be fixed to prompt to change the
ellipsoid if the current one is invalid.

r.in.gdal needs to be fixed to read the ellipsoid from
$GISBASE/etc/ellipse.table.

Andreas,

As I understand it the ellipse name is irrelevant as long as the ellipse
parameters are correct in the definition. Certainly that is the case with
the get_proj.c code that passes the definition to PROJ.4. It just drops
the ellps= setting as long as their are parameter definitions.

The ellipse.table file does have clark66 but PROJ.4 knows the same ellipsoid
as clrk66. The r.in.gdal code is based on essentially generating PROJ.4
definitions for the PROJ_INFO file.

Do you know of aspects of GRASS which require the ellipse name in the
PROJ_INFO file to match an ellipse name in the ellipse.table file exactly?

In GRASS 5.1 I would like to have the PROJ_INFO file work for any acceptable
PROJ.4 definition with some hacks to ensure older style PROJ_INFO files
continue to work properly. The subtle set of differences between PROJ.4
and GRASS coordinate system definitions is (certainly in my case) a source
of bugs and confusion.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

18

Markus Neteler writes:
> I would be glad if you send the grasscvstags.html page improved/updated
> to me (either html or plain text pieces). I know that it is still
> confusing (and I know that I prefer not to have branches in grass51/),
> but I need assistance to get grasscvstags.html really useful.

Perhaps just a simple paragraph at the top of the page, entitled "How
branches are used within GRASS", or maybe "CVS branches and the GRASS
development cycle". I'll try to put a paragraph together, but I'm sure
to get it wrong as I am still a bit confused about how this works in
the current model. See the end of my message for one take on this.

Much of my confusion may have resulted from the fact that I became
acquainted with GRASS in the middle of an (exceptionally long?)
release feature freeze, (which should likely be considered complete
now as discussed in previous threads).

I'm also confused about the existence as grass51 in a separate
directory/module in CVS. Are CVS tags and branches not sufficient for
distinguishing between experimental/stable versions of the code? Why
incorporate a version number into a top-level directory name like
this?

-Carl

PS. Here's an attempt at an explanation for grasscvstags.html This is
something like what I think should be going on, and may not reflect
the current state very well. Especially as it appears that when the
releasebranch_11_april_2001_5_0_0 branch was created that all
development moved to that branch and the head of the CVS tree has gone
neglected. Seems like it would be better to keep most development on
the head instead --- this might also help keep the feature-freeze
release cycles shorter.

But, then again, I'm brand new and I wasn't here to see how or why
things have happened. So I really shouldn't be casting out all kinds
of broad analysis like this. Feel free to ignore me completely. :wink:

<h2>
CVS, tags, branches and the GRASS development cycle
</h2>

<p>
Most of the time, GRASS development occurs at the head of the CVS
tree. When the code becomes sufficiently stable that it could be
considered a candidate for release, a branch is created in CVS. This
branch may be checked out using the appropriate CVS tag. For example,
on 11 April 2001, the GRASS 5.0.0 branch was created with a tag name
of releasebranch_11_april_2001_5_0_0 grass.

<p>
When the branch is created the release is considered "frozen". That
is, no new features will be added to that branch, but only fixes for
bugs. As fixes are applied to the branch, they will also be merged
into the head of the tree, where other experimental development will
continue. After a period of testing and bug fixing, the release branch
will be considered stable and officially released.

19

Hi Carl,

On Mon, Oct 29, 2001 at 01:01:10PM -0500, Carl Worth wrote:

Markus Neteler writes:
> I would be glad if you send the grasscvstags.html page improved/updated
> to me (either html or plain text pieces). I know that it is still
> confusing (and I know that I prefer not to have branches in grass51/),
> but I need assistance to get grasscvstags.html really useful.

Perhaps just a simple paragraph at the top of the page, entitled "How
branches are used within GRASS", or maybe "CVS branches and the GRASS
development cycle". I'll try to put a paragraph together, but I'm sure
to get it wrong as I am still a bit confused about how this works in
the current model. See the end of my message for one take on this.

Much of my confusion may have resulted from the fact that I became
acquainted with GRASS in the middle of an (exceptionally long?)
release feature freeze, (which should likely be considered complete
now as discussed in previous threads).

Sorry for this confusion... In fact the release feature freeze is
exceptionally long. Therefore we'll use the Linux Kernel numbering
scheme for 5.1.

I'm also confused about the existence as grass51 in a separate
directory/module in CVS. Are CVS tags and branches not sufficient for
distinguishing between experimental/stable versions of the code? Why
incorporate a version number into a top-level directory name like
this?

Well, the reason is that grass51/ requires a complete change of the
directory layout. It would be a pain to do this in CVS. Therefore
we start more or less from scratch in a fresh CVS tree, which
already exists (containing the new 5.1 vector library).

[thanks for the text piece, added to
http://grass.itc.it/grasscvstags.html
].

I have again slightly modified that page. Is it somewhat
better now?

Markus

20

Markus Neteler writes:
> Hi Carl,
> Sorry for this confusion... In fact the release feature freeze is
> exceptionally long. Therefore we'll use the Linux Kernel numbering
> scheme for 5.1.

I think this is a fine idea.

> > I'm also confused about the existence as grass51 in a separate
> > directory/module in CVS.
>
> Well, the reason is that grass51/ requires a complete change of the
> directory layout. It would be a pain to do this in CVS. Therefore
> we start more or less from scratch in a fresh CVS tree, which
> already exists (containing the new 5.1 vector library).

Large-scale restructuring of directory trees in CVS can be painful,
indeed.

However, I'm not sure the proposed solution is much better. Developers
will still have to create the new structure and copy the old code over
into it with modifications and "cvs add" all files/directories. (These
are the same steps that would be needed to do it "in place" minus
several "cvs remove" operations).

But problems lie in the future. What happens when grass51 becomes
stable? Do we make a new grass52 directory and go through all the work
again? And how about all the references to checking out "grass" from
CVS. These will all become stale and difficult to maintain for each
major version.

IMHO, it would actually be much easier to just fix the structure
within CVS and leave the code in the "grass" module.

> [thanks for the text piece, added to http://grass.itc.it/grasscvstags.html\]
>
> I have again slightly modified that page. Is it somewhat
> better now?

You're welcome. It's better, but still misleading with regards to the
current state of the code. My paragraph suggests that the head of the
CVS tree will always have the most recent code, (with the possible
temporary exception of a few bug-fixes on the current "frozen"
branch).

However, it seems that currently the head of the CVS tree is actually
very out of date and probably not useful to anyone. So, either that
paragraph should be updated to match the current state of affairs, or
else the changes on the release branch should be merged back onto the
trunk of the CVS tree.

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725