[GRASS5] proj changes for releasebranch?

Hello
I feel the changes I made to the proj implementation in GRASS and the new
datum transformation support are now probably mature enough to go into the
release branch, so I have prepared this and will merge the changes in in a
day or two if nobody objects (positive encouragement would be good too).

Some other things that are intermingled with the proj stuff that will go
in as well:
Easy SG3d compilation by specifying --with-irisgl to configure (this can't
hurt anything)
r.sun improvements which were mixed up with the proj changes to r.sun and
seem to have got good feedback
geo.h and geo_init.c tidying by Eric Miller (seems to work fine in CVS
head)
d.where improvements to output lat/long or WGS84 lat/long for other
projections than UTM

Of course there are lots of other changes in the CVS head that should go
into the release branch; these are just a few that would have been a bit
of work to separate from the proj changes.

Paul

Paul Kelly wrote:

I feel the changes I made to the proj implementation in GRASS and the new
datum transformation support are now probably mature enough to go into the
release branch, so I have prepared this and will merge the changes in in a
day or two if nobody objects (positive encouragement would be good too).

Are you aware of tools/diff.sh? This is what I've been using to
analyse the differences between the head and release branches prior to
merging.

To prepare the previous releases, I've run diff.sh, then posted a
summary of the changes in order to obtain opinions as to which changes
should be merged and which shouldn't.

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

On Thu, 3 Jul 2003, Glynn Clements wrote:

Are you aware of tools/diff.sh? This is what I've been using to
analyse the differences between the head and release branches prior to
merging.

Yes I used it; it was quite useful. Especially the lists showing which
files had been added and removed that I needed to specifically do cvs add
and cvs remove after copying them over. I checked the diffs for the files
I had been working on and any that had other changes than the ones I made;
I changed them manually. The others I just copied over in one go. I had to
run autoconf to generate a new configure script that had the external proj
and IRIS GL changes but not the C++ ones.

To prepare the previous releases, I've run diff.sh, then posted a
summary of the changes in order to obtain opinions as to which changes
should be merged and which shouldn't.

I thought maybe if I committed the things I am happy with to the release
branch now, then the amount of other changes would be much smaller and they
could be gone through in the usual way?

I just downloaded and compiled the 5.0 CVS snapshot of June 28 and
PROJ.4 from remotesensing.org's CVS.

troubles: (all with a lat-lon location)

d.where:

* program goes into interactive mode automatically
   - should it use the current ellipsoid by default and ask no
     questions? What is output if neither -l or -w are used??
* if you choose to display WGS84 as well, the column headings
     need to be identified.

-=-=-

Testing out the new New Zealand transforms:

g.setproj Segfaults if a datum is already set. If you say "n" to the
"specify a map datum for this location?" question it works, and you can
run it again to set a new datum, but if you try and just change the
transform params it segfaults.
[see output #1 below]

=-=

[s|v|r?].proj fails when using the NTv2 distortion grid. Didn't try a
raster, but I got the same error with both site and vector.
(current location nzgd49/NTv2 lat-lon, importing from a WGS84 location)
[see output #2 below]
cs2cs with same (cut-and-paste) parameters works correctly.

=-=

Using the 3 and 7 param transform, s.proj runs to completion, but no
transform is actually done. (happens both ways)
[see output #3 below]
cs2cs with same (cut-and-paste) parameters works correctly.

regards,
Hamish

(sorry about the line wrap)
--------------------------------------------------------------
OUTPUT #1

GRASS:~/grass_data/nz_gd49/PERMANENT > g.setproj

WARNING! A projection file already exists for this location
(Filename '/home/hamish/grass_data/nz_gd49/PERMANENT/PROJ_INFO')

This file contains all the parameters for the
location's projection: Latitude-Longitude

    Overriding this information implies that the old projection
parameters were incorrect. If you change the parameters, all
existing data will be interpreted differently by the projection
software. GRASS will not re-project your data automatically

Would you still like to change some of the parameters (y/n) [n] y

Please specify projection name
Enter 'list' for the list of available projections
Hit RETURN to cancel request

ll

Do you want to specify a map datum for this location?(y/n) [y] y
The current datum is nzgd49
Would you want to change the datum (or the datum transformation
parameters)?(y/n) [n] n
The datum information is not changed
Segmentation fault

--------------------------------------------------------------
OUTPUT #2:

GRASS:~ > v.proj -s in=coastlines mapset=PERMANENT loc=global

Input Projection Parameters: +proj=latlong +a=6378137.000000 +rf=298.257224 +towgs84=0.000,0.000,0.000

Output Projection Parameters: +proj=latlong +a=6378388.000000 +rf=297.000000 +nadgrids=nzgd2kgrid0005.gsb

Creating dig file...
pj_transform() failed
cause: failed to load NAD27-83 correction file
Error in pj_do_proj

===> cs2cs works ok:
echo "170.5 -45" | cs2cs +proj=latlong +a=6378388.000000 +rf=297.000000 +nadgrids=/usr/local/grass5/etc/nad/nzgd2kgrid0005.gsb +to +proj=latlong +a=6378137.000000 +rf=298.257224 +towgs84=0.000,0.000,0.000

170d30'0.327"E 44d59'54.104"S 0.000

--------------------------------------------------------------
OUTPUT #3:

GRASS:~ > s.proj in=test_pts49 mapset=hamish loc=nz_gd49 out=test_pts84

Input Projection Parameters: +proj=latlong +a=6378388.000000
+rf=297.000000 +towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993

Output Projection Parameters: +proj=latlong +a=6378137.000000
+rf=298.257224 +towgs84=0.000,0.000,0.000

===> looks ok, but nothing actually happens:
      (it should change by about 150m)

GRASS:~/grass_data > cat nz_gd49/hamish/site_lists/test_pts49
name|tests
desc|s.in.ascii sites=tests fs=space
175E|36:30S|#1 @site1
174:45E|41:15S|#2 @site2
170:30E|45S|#3 @site3

GRASS:~/grass_data > cat nz_wgs84/hamish/site_lists/test_pts84
name|tests
desc|s.in.ascii sites=tests fs=space
175E|36:30S|#1 @site1
174:45E|41:15S|#2 @site2
170:30E|45S|#3 @site3

===> but cs2cs works ok

GRASS:~ > echo "170.5 -45" | cs2cs +proj=latlong +a=6378388.000000 +rf=297.000000 +towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993 +to +proj=latlong +a=6378137.000000 +rf=298.257224 +towgs84=0.000,0.000,0.000

170d30'0.326"E 44d59'54.134"S 1.512

Hello Hamish

On Thu, 3 Jul 2003, H Bowman wrote:

I just downloaded and compiled the 5.0 CVS snapshot of June 28 and
PROJ.4 from remotesensing.org's CVS.

troubles: (all with a lat-lon location)

d.where:

* program goes into interactive mode automatically

Looks like that was a change by Markus:
http://grass.itc.it/pipermail/grass-commit/2003-April/008573.html
The comment doesn't make it clear why it was done?

   - should it use the current ellipsoid by default and ask no
     questions? What is output if neither -l or -w are used??

By default it outputs eastings and northings (or lat/long if in a lat/long
location). No projection is involved and no need to know which ellipsoid
the projection is based on.

* if you choose to display WGS84 as well, the column headings
     need to be identified.

Yes that would be a pretty specific situation where your location already
was in lat/long and you wanted to view WGS84 lat/long values alongside
local ellipsoid values. With this new feature I was thinking more of
people with a projected location wanting to compare co-ordinates with
values from a GPS receiver.
But good point; I have now updated the CVS version to print 'WGS
Co-ordinates' above the second column.

-=-=-

Testing out the new New Zealand transforms:

g.setproj Segfaults if a datum is already set. If you say "n" to the
"specify a map datum for this location?" question it works, and you can
run it again to set a new datum, but if you try and just change the
transform params it segfaults.
[see output #1 below]

As far as I understand it g.setproj didn't used to let you change an
existing location to lat/long (even if it was lat/long originally). I
removed some of the restrictions on this in the code but looks like maybe
that was a bad idea as it is causing problems elsewhere. Do you get the
same error, say if it is a nzmg projected location instead of lat/long.

I really don't know what to do about g.setproj. You are far better off just
editing PROJ_INFO files manually if you want to change things; g.setproj is
only anywhere near reliable when setting up a brand new location. Even its
man page says it is just a productivity tool to help in setting up
projections, implying it is fine to edit the files by hand. What it does
(prompting for parameters for each projection) is really something that
should be built into PROJ.4.

I'll get back to you on some of the other things. Some ideas:
is your whole map inside the area covered by the grid-shift file?
Does s.proj still give you no shift when doing datum shifts between two
projected locations ( or projected and lat/long), rather than between two
lat/long locations?

Paul

On Thu, Jul 03, 2003 at 11:12:33AM +0100, Paul Kelly wrote:

Hello Hamish

On Thu, 3 Jul 2003, H Bowman wrote:

> I just downloaded and compiled the 5.0 CVS snapshot of June 28 and
> PROJ.4 from remotesensing.org's CVS.
>
>
> troubles: (all with a lat-lon location)
>
>
> d.where:
>
> * program goes into interactive mode automatically

Looks like that was a change by Markus:
http://grass.itc.it/pipermail/grass-commit/2003-April/008573.html
The comment doesn't make it clear why it was done?

I think I made it to make GRASS 5.1 happy - please revert
if necessary. We can do something different in 5.1 (if I
recall correctly it was for the the GUI startup or HTML creation).

[...]

I am not in town at time, so I cannot change myself.

Markus

Hello again

On Thu, 3 Jul 2003, H Bowman wrote:

Testing out the new New Zealand transforms:

g.setproj Segfaults if a datum is already set. If you say "n" to the
"specify a map datum for this location?" question it works, and you can
run it again to set a new datum, but if you try and just change the
transform params it segfaults.
[see output #1 below]

I can't seem to reproduce this. Can you post a sample of your PROJ_INFO,
PROJ_UNITS and DEFAULT_WIND files that you had prior to running g.setproj?

=-=

[s|v|r?].proj fails when using the NTv2 distortion grid. Didn't try a
raster, but I got the same error with both site and vector.
(current location nzgd49/NTv2 lat-lon, importing from a WGS84 location)
[see output #2 below]
cs2cs with same (cut-and-paste) parameters works correctly.

=-=

Using the 3 and 7 param transform, s.proj runs to completion, but no
transform is actually done. (happens both ways)
[see output #3 below]
cs2cs with same (cut-and-paste) parameters works correctly.

Looks like you found a major bug dating back to the first PROJ
improvements in January. We needed to convert latitude/longitude angles
into radians for PROJ, but this wasn't being done. My new version and Eric
Miler's new version both had this bug so I suppose being consistently
wrong meant nobody picked up on it. The relevant function is pj_do_proj()
in src/libes/proj/do_proj.c and I have fixed it in CVS now.

This bug only showed up when projecting between two lat/long locations.

Thanks for all the testing!

Paul

On Thu, 3 Jul 2003, Markus Neteler wrote:

I think I made it to make GRASS 5.1 happy - please revert
if necessary.

Well all it means is you have to press enter 4 times before the prompt to
click in the monitor appears, which is quite quick and easy to do. Depends
on people's general ideas about usability what we should do.

Paul Kelly wrote:

> To prepare the previous releases, I've run diff.sh, then posted a
> summary of the changes in order to obtain opinions as to which changes
> should be merged and which shouldn't.

I thought maybe if I committed the things I am happy with to the release
branch now, then the amount of other changes would be much smaller and they
could be gone through in the usual way?

Personally, I've only "unilaterally" committed the things which I
think can't possibly make anything worse. Even then, I've been wrong
on a couple of occasions.

In retrospect, I think that we should have had a 5.1 branch for minor
but ultimately non-trivial upgrades (e.g. the datum stuff), a 6.0
branch for the more radical stuff (i.e. Radim's vector re-write), and
kept 5.0.x strictly for bugfixes.

There are known actual bugs in 5.0.2; it would have been nice to have
a 5.0.3 version which fixes the bugs in 5.0.2 with absolutely zero
chance of breaking anything else in the process. I'm fairly sure that
both 5.0.1 and 5.0.2 added new bugs which weren't present in 5.0.0 and
5.0.1 respectively.

E.g. 5.0.2 added a *major* bug to r.mapcalc, which could have rendered
5.0.2 unusable (actually, it might be unusable on some platforms; the
only reason why 5.0.2's r.mapcalc works is that the memory obtained by
malloc() early in the program is usually full of zeroes).

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

> d.where:
>
> * if you choose to display WGS84 as well, the column headings
> need to be identified.

Yes that would be a pretty specific situation where your location already
was in lat/long and you wanted to view WGS84 lat/long values alongside
local ellipsoid values. With this new feature I was thinking more of
people with a projected location wanting to compare co-ordinates with
values from a GPS receiver.
But good point; I have now updated the CVS version to print 'WGS
Co-ordinates' above the second column.

Ok, got the heading, but now it breaks when you try to use -w with +nadgrids
[see below #1], and works, but doesn't seem to actually do anything when
you use the 7 +towgs84 transform [see below #2]. Should be 150m(~17") diff't.
(with both old and new do_proj.c)

thanks, it is getting closer..
Hamish

===================================================================
OUTPUT #1

GRASS:~ > d.where

FLAG: Set the following flag?
    one mouse click only?(y/n) [n]

FLAG: Set the following flag?
    Output lat/long in decimal degree?(y/n) [n]

FLAG: Set the following flag?
    Output lat/long referenced to current ellipsoid?(y/n) [n]

FLAG: Set the following flag?
    Output lat/long referenced to WGS84 ellipsoid using datum
transformation parameters defined in current location if available?(y/n) [n] y

Buttons:
Left: where am i
Middle: draw to/from here
Right: quit this

                                                   WGS84 Co-ordinates
              LON: LAT: LON: LAT:
[click]
pj_transform() failed
cause: failed to load NAD27-83 correction file
ERROR: Error in pj_do_proj()
GRASS:~ > g.projinfo

-----------------------------------------------------------
PROJ_INFO file:
name: Lat/Lon
datum: nzgd49
nadgrids: nzgd2kgrid0005.gsb
proj: ll
ellps: international
-----------------------------------------------------------
PROJ_UNITS file:
unit: degree
units: degrees
meters: 1.0
-----------------------------------------------------------

===================================================================
OUTPUT #2

GRASS:~ > d.where -w

Buttons:
Left: where am i
Middle: draw to/from here
Right: quit this

                                                   WGS84 Co-ordinates
              LON: LAT: LON: LAT:
        168:17:54E 45:59:25.5S 168:17:54E 45:59:25.5S
     170:52:06.75E 43:46:20.25S 170:52:06.75E 43:46:20.25S
      173:26:19.5E 41:50:09S 173:26:19.5E 41:50:09S
     175:52:05.25E 40:00:18S 175:52:05.25E 40:00:18S

GRASS:~ > g.projinfo

-----------------------------------------------------------
PROJ_INFO file:
name: Lat/Lon
datum: nzgd49
towgs84: 59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993
proj: ll
ellps: international
-----------------------------------------------------------
PROJ_UNITS file:
unit: degree
units: degrees
meters: 1.0
-----------------------------------------------------------

> Testing out the new New Zealand transforms:
>
> g.setproj Segfaults if a datum is already set. If you say "n" to the
> "specify a map datum for this location?" question it works, and you
> can run it again to set a new datum, but if you try and just change
> the transform params it segfaults.

I can't seem to reproduce this. Can you post a sample of your
PROJ_INFO, PROJ_UNITS and DEFAULT_WIND files that you had prior to
running g.setproj?

Ok.
I think in the long term it would be good to have a robust version of
something like g.setproj. Editing low level files isn't very nice/safe
from a user's perspective. Is the problem that of messy code that is too
far gone to deal with without a total re-write, logical paradoxes with
no good solutions, or just the danger mixung datums and creating data that
doesn't know where it belongs?

Before: (note it happens with both nadgrids and towgs84)

GRASS:~ > g.projinfo

-----------------------------------------------------------
PROJ_INFO file:
name: Lat/Lon
datum: nzgd49
nadgrids: nzgd2kgrid0005.gsb
proj: ll
ellps: international
-----------------------------------------------------------
PROJ_UNITS file:
unit: degree
units: degrees
meters: 1.0
-----------------------------------------------------------
cat nz_gd49/PERMANENT/DEFAULT_WIND
proj: 3
zone: 0
north: 42S
south: 47S
east: 178E
west: 160E
cols: 180
rows: 50
e-w resol: 0:06
n-s resol: 0:06

Running g.setproj again and choosing ll with no datum give me this:
-----------------------------------------------------------
PROJ_INFO file:
name: Lat/Lon
proj: ll
ellps: international
-----------------------------------------------------------
PROJ_UNITS file:
unit: degree
units: degrees
meters: 1.0
-----------------------------------------------------------
(DEFAULT_WIND is the same)

===================================================================

Now I can run g.setproj again- ll, datum Yes, nzgd49, #2 (7 param):
-----------------------------------------------------------
PROJ_INFO file:
name: Lat/Lon
datum: nzgd49
towgs84: 59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993
proj: ll
ellps: international
-----------------------------------------------------------
PROJ_UNITS file:
unit: degree
units: degrees
meters: 1.0
-----------------------------------------------------------
(DEFAULT_WIND is the same)

===================================================================

But if I try g.setproj again:
GRASS:~/grass_data > g.setproj

WARNING! A projection file already exists for this location
(Filename '/home/hb/grass_data/nz_gd49/PERMANENT/PROJ_INFO')

This file contains all the parameters for the
location's projection: Lat/Lon

    Overriding this information implies that the old projection parameters
    were incorrect. If you change the parameters, all existing data will be
    interpreted differently by the projection software.
    GRASS will not re-project your data automatically

Would you still like to change some of the parameters (y/n) [n] y

Please specify projection name
Enter 'list' for the list of available projections
Hit RETURN to cancel request

ll

Do you want to specify a map datum for this location?(y/n) [y]
The current datum is nzgd49
Would you want to change the datum (or the datum transformation parameters)?(y/n) [n]
The datum information is not changed
Segmentation fault

Same segfault if I say yes to the 'change the datum' question and select
a new transform.

Hamish

>
> Using the 3 and 7 param transform, s.proj runs to completion, but no
> transform is actually done. (happens both ways)
> [see output #3 below]
> cs2cs with same (cut-and-paste) parameters works correctly.

Looks like you found a major bug dating back to the first PROJ
improvements in January. We needed to convert latitude/longitude
angles into radians for PROJ, but this wasn't being done. My new
version and Eric Miler's new version both had this bug so I suppose
being consistently wrong meant nobody picked up on it. The relevant
function is pj_do_proj() in src/libes/proj/do_proj.c and I have fixed
it in CVS now.

This bug only showed up when projecting between two lat/long
locations.

Ok, got the new do_proj.c but it doesn't seem to be using it.

How do I rebuild/install a library with rebuilding everything?

The usual gmake5 from within src/libes/proj/ doesn't seem to do it.

I've modified src/CMD/head/head.i686-pc-linux-gnu to use:
GISBASE = /usr/local/grass5
GRASS_BIN =/usr/local/grass5/bin
and then just run 'gmake5' from the source dir..

That builds & installs modules, but doesn't seem to have done it for the
proj lib.

Tried gmake5 -i from src/libes/ as well & the same.

??
Hamish

On Thu, Jul 03, 2003 at 04:36:15PM +0100, Glynn Clements wrote:

Paul Kelly wrote:

> > To prepare the previous releases, I've run diff.sh, then posted a
> > summary of the changes in order to obtain opinions as to which changes
> > should be merged and which shouldn't.
>
> I thought maybe if I committed the things I am happy with to the release
> branch now, then the amount of other changes would be much smaller and they
> could be gone through in the usual way?

Personally, I've only "unilaterally" committed the things which I
think can't possibly make anything worse. Even then, I've been wrong
on a couple of occasions.

In retrospect, I think that we should have had a 5.1 branch for minor
but ultimately non-trivial upgrades (e.g. the datum stuff), a 6.0
branch for the more radical stuff (i.e. Radim's vector re-write), and
kept 5.0.x strictly for bugfixes.

This sounds reasonable. It were also better not to introduce the
highly awaited datum transformation in the 5.0.x branch as it
is incompliant with the older data then.

The currently called 5.1 could become 5.9.x (to end in 6.0 then)
and the datum transformation (as well as the polished NVIZ?) go into
5.2.0 after a short period of 5.1.x.

There are known actual bugs in 5.0.2; it would have been nice to have
a 5.0.3 version which fixes the bugs in 5.0.2 with absolutely zero
chance of breaking anything else in the process.

I agree.

I'm fairly sure that
both 5.0.1 and 5.0.2 added new bugs which weren't present in 5.0.0 and
5.0.1 respectively.

E.g. 5.0.2 added a *major* bug to r.mapcalc, which could have rendered
5.0.2 unusable (actually, it might be unusable on some platforms; the
only reason why 5.0.2's r.mapcalc works is that the memory obtained by
malloc() early in the program is usually full of zeroes).

Like that we could go for radical improvement with 5.9/6.0 which are
definitely necessary for the future of GRASS.

Markus

Hello Paul,

On Thu, Jul 03, 2003 at 11:12:33AM +0100, Paul Kelly wrote:
[...]

> d.where:
>
> * program goes into interactive mode automatically

Looks like that was a change by Markus:
http://grass.itc.it/pipermail/grass-commit/2003-April/008573.html
The comment doesn't make it clear why it was done?

OK, the change is reverted.

Markus

On Fri, 4 Jul 2003, H Bowman wrote:

Ok, got the new do_proj.c but it doesn't seem to be using it.

How do I rebuild/install a library with rebuilding everything?

The usual gmake5 from within src/libes/proj/ doesn't seem to do it.

It is a static library so you need to also recompile the individual
modules that use proj, to link in the new version of the library.

On Fri, Jul 04, 2003 at 11:14:56AM +0200, Markus Neteler wrote:

On Thu, Jul 03, 2003 at 04:36:15PM +0100, Glynn Clements wrote:

[...]

The currently called 5.1 could become 5.9.x (to end in 6.0 then)
and the datum transformation (as well as the polished NVIZ?) go into
5.2.0 after a short period of 5.1.x.

> There are known actual bugs in 5.0.2; it would have been nice to have
> a 5.0.3 version which fixes the bugs in 5.0.2 with absolutely zero
> chance of breaking anything else in the process.
I agree.

Well, thinking again about it:

Apart from the (theoretical) desired versioning, we have some
practical implications:

- who would maintain the 5.0.x release branch
- who would create and maintain a new 5.1.x/5.2.x release branch

- most important: will the developers ever move to the (current) 5.1/5.9/6.0
  when a new 5.1.x/5.2.x release branch would be opened?

Markus

Hello again

On Fri, 4 Jul 2003, H Bowman wrote:

> > Testing out the new New Zealand transforms:
> >
> > g.setproj Segfaults if a datum is already set. If you say "n" to the
> > "specify a map datum for this location?" question it works, and you
> > can run it again to set a new datum, but if you try and just change
> > the transform params it segfaults.
>
> I can't seem to reproduce this. Can you post a sample of your
> PROJ_INFO, PROJ_UNITS and DEFAULT_WIND files that you had prior to
> running g.setproj?

Turns out it was platform-specific. Ran fine on IRIX but I got the bug
reproduced on Cygwin.
And it was my fault as well---while experimenting with using fixed length
strings and variable ones I must have left in some calls to free() that
shouldn't have been there and must have been corrupting the memory. Fixed
in CVS so hopefully should be better now. It is really good to be getting
all these bugs ironed out.

Paul

Markus Neteler wrote:

> The currently called 5.1 could become 5.9.x (to end in 6.0 then)
> and the datum transformation (as well as the polished NVIZ?) go into
> 5.2.0 after a short period of 5.1.x.
>
> > There are known actual bugs in 5.0.2; it would have been nice to have
> > a 5.0.3 version which fixes the bugs in 5.0.2 with absolutely zero
> > chance of breaking anything else in the process.
> I agree.

Well, thinking again about it:

Apart from the (theoretical) desired versioning, we have some
practical implications:

- who would maintain the 5.0.x release branch

I could do that, if 5.0.x were just bugfixes.

My comments about not being able to handle both 5.0 and 5.1 was based
upon the current "5.1" being a radical departure. It wouldn't apply to
a version which was just "upgrades" to 5.0 like the datum stuff and
NVIZ changes.

- who would create and maintain a new 5.1.x/5.2.x release branch

Creating a branch is simple enough. It would be maintained by the
developers who are currently choosing to make significant changes to
5.0.x rather than migrating to the "grass51" tree (which seems to be
everyone except Radim).

- most important: will the developers ever move to the (current) 5.1/5.9/6.0
  when a new 5.1.x/5.2.x release branch would be opened?

I don't know. But the issue of migrating developers to grass51 is
separate to how to handle non-trivial (i.e. non-bug-fix) changes to
5.0.x.

In that sense, there isn't any difference between allowing non-bug-fix
changes to 5.0.x and creating a 5.1.x branch; the difference is
whether end users (most of whom aren't going to be moving to grass51
soon) can get the bug fixes without potentially destabilising
upgrades.

Consequently, I suggest restricting 5.0.x to bug fixes, and either:

a) creating a 5.1.x branch for upgrades, and renaming "grass51" to
e.g. "grass6", or

b) decree that anyone wishing to do more than just fix bugs must
migrate to grass51/grass6.

Option a) means that grass51 will remain non-mainstream for longer;
option b) risks alienating developers. Actually, option a) also risks
alienating developers if the two trees ("grass" and "grass51") diverge
and one lot of effort ends up being discarded.

BTW, allowing non-bug-fix changes to 5.0.x has the same effect as
option a) in terms of dividing the development effort. Basically,
either you push developers into working on grass51, or you don't.

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

> > > g.setproj Segfaults if a datum is already set. If you say "n" to the
> > > "specify a map datum for this location?" question it works, and you
> > > can run it again to set a new datum, but if you try and just change
> > > the transform params it segfaults.

Turns out it was platform-specific. Ran fine on IRIX but I got the bug
reproduced on Cygwin.
And it was my fault as well---while experimenting with using fixed length
strings and variable ones I must have left in some calls to free() that
shouldn't have been there and must have been corrupting the memory. Fixed
in CVS so hopefully should be better now. It is really good to be getting
all these bugs ironed out.

Ok, changing transform parameters works fine for me now in g.setproj.

Hamish

On Thu, Jul 03, 2003 at 11:12:33AM +0100, Paul Kelly wrote:
[...]
> > d.where:
> >
> > * program goes into interactive mode automatically
>
> Looks like that was a change by Markus:
> http://grass.itc.it/pipermail/grass-commit/2003-April/008573.html
> The comment doesn't make it clear why it was done?

OK, the change is reverted.

'd.where --help' now launches into the program instead of returning to
the terminal prompt..

I can also report that the d.where -w option is now working perfectly
with the NTv2 distortion grid.
(same results as with cs2cs anyway)

Hamish