[GRASS5] Re: grass-5.3.0.tar.gz

GRASS GRASS developer
1

Hello Markus

On Fri, 21 May 2004, Markus Neteler wrote:

Hello Paul,

concerning the 5.3 release: I would like to get it completed
(complete announcements, publish it and post it to the
various sites as suggested in the release_rules.txt).

At first I wasn't sure if this should be done (widely announcing it) as it is only a development release (while reading through release_rules.txt I felt a lot of the notes referred mainly to stable releases) but I am starting to think it should after spending some time adding notes about new
modules to the release notes. I wanted to see what the other developers think.

The current version of the release notes is at
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/announce_grass530.html
I am still looking for feedback and improvements especially if I've said anything wrong about the new modules or left anything important out.

I decided purposely not to mention (a) viewproj as I feel it confuses the concept of locations with separate projections in GRASS and it doesn't support
datum transformation (and Thuban has the same functionality) and (b) d.out.tiff as it uses the old CELL driver (why not just d.out.png and convert to a tiff outside GRASSS?).

In a few days I'll be away in holidays. So in case my
help is needed, please let me know.

When you are happy with the release notes please feel free to submit to the news sites as you have done that before.

Paul

2

The current version of the release notes is at
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/announce_grass530.html
I am still looking for feedback and improvements especially if I've
said anything wrong about the new modules or left anything important
out.

1st P:
"A new release of GRASS has ..."

This paragraph is a bit muddled and unprofessional sounding to me.
I wouldn't complain but that's the one which will be used as the
headline .. I understand the "development series" bits are necessary up
front, but we shouldn't be apologigetic about it.. I hate the phrase,
but how to make it more upbeat like "technology preview" ?
Maybe just get rid of the sentances starting with "however".

"Platforms supported by GRASS:" section
MS-Windows NT/2000/XP with Cygnus

a) Didn't someone have it running on Win98 without problems?

b) Cygnus -> Cygwin?

"Users who have been following the development of the GRASS 5.3 'CVS
version' will not be surprised at the contents of the 5.3.0 release."

chop above + "However.."

"What's new" section
- r.in.gdal bug fix worth noting?

- is r.series set to build automatically? Maybe not until I switch that to
use n-1 for varience/std. dev.

- add note on core display modules updated for TrueColor support

"Concurrent Development Series 5.7"
"Major changes to the vector engine and attribute management system "
make that "changes abd improvements" ..

add that it is "very usable" today or the like ..

sorry, very busy & no time for proper corrections right now..

regards,
Hamish

3

Hello Hamish
Thanks for the comments

Hamish wrote:

> The current version of the release notes is at
> http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/announce_grass530.html
> I am still looking for feedback and improvements especially if I've
> said anything wrong about the new modules or left anything important
> out.

1st P:
"A new release of GRASS has ..."

This paragraph is a bit muddled and unprofessional sounding to me.
I wouldn't complain but that's the one which will be used as the
headline .. I understand the "development series" bits are necessary up
front, but we shouldn't be apologigetic about it.. I hate the phrase,
but how to make it more upbeat like "technology preview" ?
Maybe just get rid of the sentances starting with "however".

I agree it sounds very positive with the words 'technology
preview'---have put that in

"Platforms supported by GRASS:" section
MS-Windows NT/2000/XP with Cygnus

a) Didn't someone have it running on Win98 without problems?

b) Cygnus -> Cygwin?

Changed it to mention just Windows with Cygwin

"Users who have been following the development of the GRASS 5.3 'CVS
version' will not be surprised at the contents of the 5.3.0 release."

chop above + "However.."

yes does sound more positive like that---changed

"What's new" section
- r.in.gdal bug fix worth noting?

The main thing is --with-gdal is the default; gdalbridge code hasn't
been removed yet but it should be much more reliable for people---I put
this in:
More reliable raster import
     Technical changes and bugfixes to the r.in.gdal raster import
module mean that by default it will operate reliably with all
recent and older versions of GDAL.

- is r.series set to build automatically? Maybe not until I switch that to
use n-1 for varience/std. dev.

No but I thought I would mention it anyway and people could go looking
for it... too late to change it to compile automatically for 5.3.0 but
could always remove the mention

- add note on core display modules updated for TrueColor support

I'm not totally sure what this means; hopefully this makes sense:
TrueColor Support
     All the core display modules (d.*) now support 24-bit colour.
What modules exactly or is it not important?

"Concurrent Development Series 5.7"
"Major changes to the vector engine and attribute management system "
make that "changes abd improvements" ..

add that it is "very usable" today or the like ..

changed those

sorry, very busy & no time for proper corrections right now..

Was a good help. It's not supposed to be perfect anyway.

Paul

4

Paul Kelly wrote:

> "Platforms supported by GRASS:" section
> MS-Windows NT/2000/XP with Cygnus
>
> a) Didn't someone have it running on Win98 without problems?

I've had it running on Win98. I'm not sure if you could say "without
problems", although most of the issues would apply equally to
NT/2K/XP.

The one issue which is specific to 95/98/ME is the fork() breakage
regarding XDRIVER. mon.start needs -D__W98__ even for the "X server"
version. In turn, this means that you have to use:

  d.mon -s start=...
  d.mon select=...

instead of just "d.mon start=..." (which will try to select the
monitor before it has initialised and is accepting connections).

No but I thought I would mention it anyway and people could go looking
for it... too late to change it to compile automatically for 5.3.0 but
could always remove the mention

>
> - add note on core display modules updated for TrueColor support

I'm not totally sure what this means; hopefully this makes sense:
TrueColor Support
     All the core display modules (d.*) now support 24-bit colour.
What modules exactly or is it not important?

I presume that he's referring to having extended the syntax for
colours to allow the use of RR:GG:BB as well as named colours.

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

5

H

P

G

- is r.series set to build automatically? Maybe not until I switch
that to use n-1 for varience/std. dev.

No but I thought I would mention it anyway and people could go
looking for it... too late to change it to compile automatically for
5.3.0 but could always remove the mention

My concern is that it not go main-stream until that is done, so people
don't get left with mixed/unexpected data. On the otherhand it is a nice
thing to tell people about, and this is a good opportunity to tell them.

- add note on core display modules updated for TrueColor support

I'm not totally sure what this means; hopefully this makes sense:
TrueColor Support
   All the core display modules (d.*) now support 24-bit colour.

I presume that he's referring to having extended the syntax for
colours to allow the use of RR:GG:BB as well as named colours.

Yes, but I'd avoid using "RR:GG:BB" as that implies the 00:00:00 to
ff:ff:ff when the expected range is really 0:0:0 to 255:255:255.

What modules exactly or is it not important?

"most of the usual ones" for whatever that means. :slight_smile: Exceptions are the
d.legend and d.histogram controls for text color, as d.* modules which
otherwise use a 24-bit RGB colormap make it messy to implement.
I don't think enumerating a list is really necessary; if anything, we
should be stating which ones are still not R:G:B compliant.

If any are missing, people can complain and I'll add them one by one.
I don't mean to do every single one just because we can, however.

Hamish

6

The current version of the release notes is at
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/announce_grass530.html

two more late edits:

Alphabetize "Other new modules".
Mention improvements to m.proj2 somewhere (as a more friendly front end
vs cs2cs).

Hamish

7

On Sat, 29 May 2004, Hamish wrote:

The current version of the release notes is at
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/announce_grass530.html

two more late edits:

Alphabetize "Other new modules".

Done that.

Mention improvements to m.proj2 somewhere (as a more friendly front end
vs cs2cs).

In NEWS.html it says "m.proj2: updated for easy WGS84 input/output (Hamish Bowman)". This seems like enough to me. Is it possible to input comma-separated datum tranformation parameters now or does that limitation still remain? If it was fixed, could mention that as well.

Paul

8

> Mention improvements to m.proj2 somewhere (as a more friendly front
> end vs cs2cs).

In NEWS.html it says "m.proj2: updated for easy WGS84 input/output
(Hamish Bowman)". This seems like enough to me.

Yes, should be fine, it's not really new functionality - just an
improvement.

Is it possible to input comma-separated datum tranformation parameters
now or does that limitation still remain? If it was fixed, could
mention that as well.

I don't think so (I didn't do it anyway), the big thing is you can now
import to & from WGS84 lat/lon to the current projection by simply using
the new -i and -o flags. Also it will take input from stdin, so you can
pipe stuff to it. Much easier than figuring out cs2cs; but not really
needed in 5.7 as you can do something like:

IN_PARAM="+proj=longlat +datum=WGS84 +towgs84=0,0,0"
OUT_PARAM=`g.proj -jf`
cs2cs $IN_PARAM +to $OUT_PARAM

ok, that's a bit more difficult than 'm.proj2 -i', but m.proj3 could be
a shell script that does the above g.proj magic & would be easier to
maintain in the future so long as PROJ.4 is a install req. or we add a
line to check for cs2cs & tell the user to install it if it isn't there.

Hamish