[GRASS5] Let's release 5.4 asap

> > > Straight away we could delete 5.0 from the list on the
> > > front page leaving only 5.3 and 5.7 I think.
> >
> > I'll do that if there aren't objections.

..

OK, done.

> Maybe we could come up with a word more stable than "Testing" for
> 5.3?

The trouble lies in the dual meaning of the word stable of course.

To the user, "stable" means bug free.
To the developers, "stable" means frozen API.
(which means theoretically fewer bugs, but as in this case, not always)

I think having just "Testing" and "Development" versions up will put
people off. I suggest we use "Final Testing" instead of "Testing"?
(or something like that) It's a lot more encouraging.

Hamish

On Sat, Oct 02, 2004 at 04:35:52PM +1200, Hamish wrote:

> > Maybe we could come up with a word more stable than "Testing" for
> > 5.3?

The trouble lies in the dual meaning of the word stable of course.

To the user, "stable" means bug free.

Not always.
A bug that is documented can be worked around even for users. :slight_smile:

To the developers, "stable" means frozen API.
(which means theoretically fewer bugs, but as in this case, not always)

I think having just "Testing" and "Development" versions up will put
people off. I suggest we use "Final Testing" instead of "Testing"?
(or something like that) It's a lot more encouraging.

We could use more words like a single paragraph to give people
a feeling what version we do recommend for usage.
For now the recommended version (or when in doubt is): 5.3.

There are many reasons to try and use 5.7, so this is encouraged, too.

We have no schedule yet.

I cannot judge how complicated the current copying
or mix linking is and how many changes are going to be made
to the files. So the timing must be up for somebody else to decide.

On Fri, Oct 01, 2004 at 04:00:43PM +0200, Radim Blazek wrote:

On Friday 01 October 2004 15:25, Bernhard Reiter wrote:
> > > I can move files or directories around in CVS in principle.
> > > Just need a good list.
> > > (probably the right mv commands might be most instructive :wink: )
> > > and then I need to schedule shutting down CVS
> > > and doing the change.
> > > (Depending on my time this might a few days, so giving me an ahead
> > > notice is appreceated.)
> >
> > The list is here:
> >
> > http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link.conf?rev=1.72&c
> >ontent-type=text/vnd.viewcvs-markup excluding *akefiles and subdirs,
> > (see
> > http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link?rev=1.8&content
> >-type=text/vnd.viewcvs-markup ) it can still copy unused files, which is
> > not harm, I think.
> >
> > Should be 'cp', not 'mv', I believe.
>
> Yes!
>
> I would appreciate if someone would make a fixed list of "cp"
> command lines that I only need to source with the ",v" extension,
> because that seems more transparent as a script.
> Especially must there be checking if there is a corresponding file already?

Yes.

> Do you want me to
> mv grass51 grass57
> ,too?

No.

> > Initial comment (probably a new comment appended at the end),
> > should tell in unique form, where it was taken from (grass5 tree).
>
> During a copy operation in the repository someone cannot put in CVS
> comments, they would be exactly the same as in the original file.
> Probably with cvs admin you can change something.
> Maybe basiing revision numbers starting with "2.x" ?
>
> When do you want this to happen?
> Next week?
> After 5.4 release?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

No, please do not reduce the choice of people, it will hurt them.

I do not agree with that. What is the problem using 5.3 instead of 5.0?
Also, packagers will not upgrade to 5.7 if there still is a "stable" 5.0.

More generally, a plea from a grass end user: stick to the KIS principle. I
may miss some points, do not see any major problem in using 5.7. It is
already far better than 5.0, and most users cannot afford missing the
excellent new fector features. So, why bother with other versions? I think
concentrating the (little) energies on one version, we'll get better results
sooner.

Overall, the situation is very strange (I do not know of any other program in
this state), and should be better avoided.

Am I wrong?
pc

At 16:57, sabato 02 ottobre 2004, Bernhard Reiter has probably written:

For now the recommended version (or when in doubt is): 5.3.

Sorry, but I do not see your point (I may be naive): why should I use 5.3
instead of 5.7? I cannot afford missing the new vector functionalities, and I
think few professional gis users could, nowadays.
So why exactly we could not recommend 5.7 straight away?
I think users (especially the professionals, main target for GRASS) are
concerned by the ratio functionalities/bugs, not just bug number.
For instance, how many Debian woody desktop users are around?
All the best.
Paolo

- --
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
GPG key @: hkp://wwwkeys.pgp.net http://www.pgp.net/wwwkeys.html
https://www.biglumber.com
Only free software: www.gnu.org / www.linux.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBYFz3/NedwLUzIr4RAtNUAJ9z3qkQCxC5nUOh0QLd2lqQM4W+FwCgkDYB
QUgPmlj+Ey8/vqUH0AlmN3Y=
=6BXr
-----END PGP SIGNATURE-----

On Sat, Oct 02, 2004 at 04:35:52PM +1200, Hamish wrote:

> > > > Straight away we could delete 5.0 from the list on the
> > > > front page leaving only 5.3 and 5.7 I think.
> > >
> > > I'll do that if there aren't objections.
..
>
> OK, done.
>
> > Maybe we could come up with a word more stable than "Testing" for
> > 5.3?

The trouble lies in the dual meaning of the word stable of course.

To the user, "stable" means bug free.
To the developers, "stable" means frozen API.
(which means theoretically fewer bugs, but as in this case, not always)

I think having just "Testing" and "Development" versions up will put
people off. I suggest we use "Final Testing" instead of "Testing"?
(or something like that) It's a lot more encouraging.

Yes, changed for 5.3 (thanks to Paolo Cavallini for another page overhaul).
Please have another look.

Markus

On Fri, Oct 01, 2004 at 01:32:03PM +0200, Bernhard Reiter wrote:

Hi Paul,

got you wrong on that point then.
Moving it into the old section is of course fine.

(Though currently the links to the old section make
you search a bit until you find it again... )

... which is good to avoid that "normal" users grab the old
stuff (and then complain). If a software engineer wants to
study the development history of GRASS, they'll be able to
find it :slight_smile:

Markus

On Sun, 3 Oct 2004, Paolo Cavallini wrote:

At 16:57, sabato 02 ottobre 2004, Bernhard Reiter has probably written:

For now the recommended version (or when in doubt is): 5.3.

Sorry, but I do not see your point (I may be naive): why should I use 5.3
instead of 5.7? I cannot afford missing the new vector functionalities, and I
think few professional gis users could, nowadays.
So why exactly we could not recommend 5.7 straight away?

I think quite a lot of it is a question of what you are used to. If you get used to the vector functionality in 5.7 and are comfortable with using it, you will start using it for all analyses, even when many of them could also be done as raster analyses. So it may not be as vital as you think. I don't know though; I'm not a GIS professional---just suggesting a possible reason why it may not be quite as vital as you suggest.

And more generally also, I think it is a question of what you are used to. If someone's first experience is of GRASS is 5.7 and you have never used 5.3, then you would not miss the features of 5.3 that are not in 5.7. Some other reasons:

5.7 is very Linux-oriented and not well-tested on other operating systems

5.7 lacks the simplicity of the ASCII sites format in 5.3

There are also many 5.3 commands people are used to that are not ported to 5.7. And should not be, either because they will be obsolete or they contain many bugs and one of the aims of 5.7 was to re-write things and remove bugs when they were being moved over. E.g. v.in.dxf, d.extend, interactive g.region, SG3d...

There is no reason now to use 5.0, but I think 5.3 and 5.7 can co-exist side-by-side on the same system.

Paul

Paolo Cavallini wrote:

Sorry, but I do not see your point (I may be naive): why should I use 5.3
instead of 5.7?

People may have built scripts or other functionality on top of 5.3,
and re-writing them might involve significant effort. An academic
institution may have prepared courses involving 5.0/5.3; switching to
5.7 would involve re-writing lecture notes, coursework, marking
guidelines, etc, re-training assistants and so on.

In the real world, backwards compatibility matters. A substantial
upheaval every other year is often far more problematic than many free
software developers would like to believe.

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

Hello Helena

On Mon, 4 Oct 2004, Helena wrote:

On Sun, 3 Oct 2004, Paolo Cavallini wrote:

Sorry, but I do not see your point (I may be naive): why should I use 5.3
instead of 5.7? I cannot afford missing the new vector functionalities, and I
think few professional gis users could, nowadays.
So why exactly we could not recommend 5.7 straight away?

even more important argument against widespread use of 5.7 for non-developers
is that there are still changes/additions that need to be made that affect location
set-up. In particular, I have just started to test the nviz support for volumes,
as well as the volume interpolation and the issue of 3d region has poped-up right away.
I think that if we want to release 5.7/6.0 as 3D GIS the 3d region should be mandatory
(created when a new location is defined)
and vertical datum info should be added to coordinate system definition file.

I was just wondering if you have had any more ideas on how vertical datum information should be interpreted and what modules would pay attention to it, e.g. vector z values, how could a raster layer be tagged as elevation, etc.

I think there is a feature in the 5.7 v.proj where the z value (for 3-D vectors) is interpreted as ellipsoidal height and transformed during a
re-projection. For this I suppose it might be appropriate to have the
vertical datum associated. But as far as I know the methods for transforming
between vertical datums are all based on localised grids and it probably
would not be feasible to include them all in GRASS.

If this is adopted, when a user starts 5.7 with old location created by pre-5.7 GRASS,
user can be asked whether the 3d region file should be created automatically
(e.g. using the default region with 1 layer and 0 vertical origin.) and in that way
the old LOCATIONS can be brought up-to-date for 5.7.
It will be less confusing to make this transition to 3D between 5.3 and 5.7,
where everybody expects significant differences than later.

That is a good idea. I think it is no problem to make these kind of changes one at a time in the 5.7.x series, before 5.8.0 stable is released.

Regarding the sites format - I would very much ask people who use sites to try to
work without the sites ascii format and use the point data in vector format
to find out whether it makes sense to abandon the ascii sites format or whether
there is a serious argument for keeping it. As I mentioned long time ago, the ascii
sites format was a temporary solution until a better support is available in vector format.
But apparently it persists due to its convenience (or that we are just used to it).

I think it is a mixture of both. But I know from e-mails to the list that the default DBF format has problems dealing with attributes for large numbers of points in a vector file, that the sites format would have no trouble with, just churn through them all and get there in the end. I think the sites format was really well implemented, looking through some of the old source code by Bill Brown et al it seems he had some very clear ideas about leveraging the simplicity of the format for maximum convenience, if that makes sense. I feel confident that there is not a lot that can go wrong when using sites.

As I said months before, I believe that 5.3 should be closed to new development
and I agree that it should be released as 5.4 ASAP (it is certainly more stable than
the previous versions of GRASS) and all developemnt should focus on 5.7, but it looks like
that is happening

Yes I think it is. There is a lot more development in 5.7 now and 5.3 is just being tidied up. In fact, thanks to Scott Mitchell letting me use his Mac OS X machine for testing, we may have the problem with shared libraries on that platform fixed. Things may be ready for 5.4.0 by the end of the week at this rate :slight_smile:

Paul

On Mon, Oct 04, 2004 at 10:04:32PM +0100, Paul Kelly wrote:
...

I think it is a mixture of both. But I know from e-mails to the list that
the default DBF format has problems dealing with attributes for large
numbers of points in a vector file,

Paul,

do you have any test data to verify that? If true, is it a limitation
of DBF in general or of the GRASS implementation?

Markus

Helena,

(cc to grass5 for the archive)

On Tue, Oct 05, 2004 at 11:52:30PM -0400, Helena wrote:

I am trying to get myself started in 57 and test nviz so that it can be
submitted, but I need some help (or maybe I should read some manual
or tutorial).

Are you using the older Paudits version or does it already
contain the recent enhancements of 5.7/ogsf?

To test the 3d stuff I have created a 3d point file (see below) using
bugsites
in spearfish (elevation is from DEM and few have points below surface)
and imported it as
s.in.ascii bugsites3d input=bugsitesz.asci d=3
this creates a vector point file

I guess that v.in.ascii should be used.
"-z
    create 3D file"
"

[ the coordinates in my example below are also for Spearfish]

echo "593493.1|4914730.2|123.1|studna
591950.2|4923000.5|222.3|kadibudka
589860.5|4922000.0|232.3|hruska
590400.5|4922820.8|143.2|mysi dira
593549.3|4925500.7|442.6|mineralni pramen
600375.7|4925235.6|342.2|mineralni silnice" | v.in.ascii -z zcol=3 catcol=0 \
  out=mypoints3D columns='x double, y double, z double, label varchar(20)'

You may have to use fs= if you have different field separator.

but v.info indicates that B and T are 0, so it must have ingored d=3 upon
import

no, I guess because s.in.ascii is inappropriate.
I have just extended the HTML page of v.in.ascii, adding above
example.

However, when I modified the ascii file to 3d site format and imported it
with
v.in.sites, it worked. But I still won't get the basic statistics on the
file (probably my mistake as I have never used any DBM tools).

So, now we can try:

d.vect mypoints3D
d.vect mypoints3D disp=attr attrcol=label
# -> points with labels

#check DB:
echo "SELECT * from mypoints3D" | db.select
cat|x|y|z|label
1|593493.100000|4914730.200000|123.100000|studna
2|591950.200000|4923000.500000|222.300000|kadibudka
3|589860.500000|4922000.000000|232.300000|hruska
4|590400.500000|4922820.800000|143.200000|mysi dira
5|593549.300000|4925500.700000|442.600000|mineralni pramen
6|600375.700000|4925235.600000|342.200000|mineralni silnice

Works.

GRASS 5.7.cvs:/data/b_usr4/b_usr4/grassdata/spearfish/helena/site_lists >
v.univar bugsitesz3dt col=1
WARNING: Incompatible types, only number of features, minimum, maximum and
         range can be calculated
DBMI-DBF driver error:
SQL parser error in statement:
SELECT cat, 1 FROM bugsitesz3dt
Error in db_open_select_cursor()

ERROR: Column type not supported

Yes, I guess that you didn't specify the column type when using
v.in.ascii (see my example above how to do that). By default it will
make every type in the DB a string as it cannot guess the column type.

v.univar mypoints3D col=z
WARNING: Incompatible types, only number of features, minimum, maximum and
         range can be calculated
number of features with non NULL attribute: 6
number of missing attributes: 0
number of NULL attributes: 0
minimum: 123.1
maximum: 442.6
range: 319.5

which looks ok. IMHO the warning is confusing, but this could be improved.

g3.createwind says after it is finished -

There must have been an error (which I fixed right now in 5.3 and 5.7 CVS).

Now run g3.region to verify the settings.
but there is no g3.region in 5.7 (should that message just be removed?)

There is (for a few days), please update your 5.7 version.

When I get more familiar with 5.7 and the current 3d stuff I hope that I
will have fewer questions and rather provide some help.

Hope that it works now

Markus

On Mon, Oct 04, 2004 at 10:47:31AM +0200, Markus Neteler wrote:

On Fri, Oct 01, 2004 at 01:32:03PM +0200, Bernhard Reiter wrote:

> got you wrong on that point then.
> Moving it into the old section is of course fine.
>
> (Though currently the links to the old section make
> you search a bit until you find it again... )

... which is good to avoid that "normal" users grab the old
stuff (and then complain). If a software engineer wants to
study the development history of GRASS, they'll be able to
find it :slight_smile:

I tend to disagree, because this has a mental model
or "normal" users that I do not share.
A clear marking should be fine and adaquate for a good archive.

Hi Paolo,

On Sun, Oct 03, 2004 at 10:11:32PM +0200, Paolo Cavallini wrote:

-----BEGIN PGP SIGNED MESSAGE-----

(^^^ Interesting: You are using deprecated non-MIME OpenPGP,
which is an example for contradicting what you have said
about bothering with old versions. )

> No, please do not reduce the choice of people, it will hurt them.

I wrote that a few mails ago and it was meant against "deleting 5.0"
from the servers. (That was a missunderstanding that got clarified,
nobody proposed to delete it.)
Because you have addressed that point
I feel a general answer is wanted.

I do not agree with that. What is the problem using 5.3 instead of 5.0?
Also, packagers will not upgrade to 5.7 if there still is a "stable" 5.0.

I think that advantages for 5.3 over 5.7. has been answered by
others in the thread.

As for archiving old versions (and making them easiy accessible)
this is quite important and all serious Free Software project do it.
What distributors are packaging is mostly up to them,
though they do appreciate understandable recommendations:

Examples:

  Linux Kernel: http://www.kernel.org/
  Still offering lines for 2.0.x 2.2.x 2.4.x and 2.6.x
  Modern distributions usually use 2.4.x with an optional
  choice of 2.6.x. There are small or special purpose
  distributions using 2.0.x and 2.2.x, too for stability
  or hardware reasons.

  GnuPG: www.gnupg.org
  A project with less uptodate webpages, but still offering
  gnupg-1.0.0 in the same directory with 1.2.6 (stable).
  ftp://ftp.cert.dfn.de/pub/tools/crypt/gcrypt/gnupg/
  Then there is 1.3.6 (more stable development to wards 1.4.0) and
  1.9.9 (experimental development).

  Samba: www.samba.org
  A project offering two stable releases 2.2.12 and 3.0.7
  and a development line with 3.1.x.

More generally, a plea from a grass end user: stick to the KIS principle. I
may miss some points, do not see any major problem in using 5.7. It is
already far better than 5.0, and most users cannot afford missing the
excellent new fector features. So, why bother with other versions? I think
concentrating the (little) energies on one version, we'll get better results
sooner.

Overall, the situation is very strange (I do not know of any other program in
this state), and should be better avoided.

Am I wrong?

At least there are many examples for Free Software projects
that keep older versions around and offer many different development lines.

  Bernhard

On Fri, Oct 08, 2004 at 12:37:37PM +0200, Bernhard Reiter wrote:

On Mon, Oct 04, 2004 at 10:47:31AM +0200, Markus Neteler wrote:
> On Fri, Oct 01, 2004 at 01:32:03PM +0200, Bernhard Reiter wrote:

> > got you wrong on that point then.
> > Moving it into the old section is of course fine.
> >
> > (Though currently the links to the old section make
> > you search a bit until you find it again... )
>
> ... which is good to avoid that "normal" users grab the old
> stuff (and then complain). If a software engineer wants to
> study the development history of GRASS, they'll be able to
> find it :slight_smile:

            ^^^^^- (hint)

I tend to disagree, because this has a mental model
or "normal" users that I do not share.
A clear marking should be fine and adaquate for a good archive.

I can imagine many useful improvements for the web site.
... finally it needs someone to realize them.

Markus

On Fri, Oct 08, 2004 at 12:56:07PM +0200, Bernhard Reiter wrote:
[...]

I wrote that a few mails ago and it was meant against "deleting 5.0"
from the servers. (That was a missunderstanding that got clarified,
nobody proposed to delete it.)

[also related to your latest message, Bernhard]

Just to clarify that again: Radim and me have spent much time to
find (!) all the versions. We still try to get hands on the
CERL-4.2 which was never published. Jim Westervelt is trying to
find it for me (us). So, just by entering the
web site through ftp you can see all the versions in subdirectories.

Perhaps you didn't see this page?
http://grass.itc.it/grass_releases.html
Not sure what else could be done.
You can click on all versions and grab the source code.

If you want to see detailed changes (diffs), go here:
http://mpa.itc.it/radim/g50history/

Radim has spent much time to make it convenient HTML pages.
He even fetched all related emails:
http://mpa.itc.it/radim/g50history/grass50history.html

...

As for archiving old versions (and making them easiy accessible)
this is quite important and all serious Free Software project do it.

Fully agreed and also realized for GRASS.

...

At least there are many examples for Free Software projects
that keep older versions around and offer many different development lines.

  Bernhard

GRASS is a prominent example to document 20 years of software development.

However, to offer many different development lines is impossible
unless more developers join the team. But this has been discussed
often enough.

Hope this helps

Markus

5.7's s.out.ascii --
It outputs a vector points file, not an old sites format file.

I was thinking of adding an -o flag to make input= from an old sites
file.

The motivation is that v.in.sites currently doesn't make a table and
rather do all the work to add it, a script which did

s.out.ascii -o -a -d | v.in.ascii

might be easier.

I think I just talked myself into not adding the flag & hoping that
v.in.sites gets fixed.

Hamish

On Thursday 07 October 2004 15:14, Markus Neteler wrote:

Yes, I guess that you didn't specify the column type when using
v.in.ascii (see my example above how to do that). By default it will
make every type in the DB a string as it cannot guess the column type.

No, it _guess_ the column type, whole input is read first, to find
the column type.

Radim

On Monday 11 October 2004 08:21, Hamish wrote:

5.7's s.out.ascii --
It outputs a vector points file, not an old sites format file.

I was thinking of adding an -o flag to make input= from an old sites
file.

The motivation is that v.in.sites currently doesn't make a table

Realy?

Radim

On Monday 04 October 2004 11:44, Paul Kelly wrote:

There are also many 5.3 commands people are used to that are not ported to
5.7. And should not be, either because they will be obsolete or they
contain many bugs and one of the aims of 5.7 was to re-write things and
remove bugs when they were being moved over. E.g. v.in.dxf, d.extend,
interactive g.region, SG3d...

I have updated grass51/TODO:
http://freegis.org/cgi-bin/viewcvs.cgi/grass51/TODO

See also:
http://freegis.org/cgi-bin/viewcvs.cgi/grass51/doc/vector/v.modules.html

Radim

On Monday 04 October 2004 23:04, Paul Kelly wrote:

I think it is a mixture of both. But I know from e-mails to the list that
the default DBF format has problems dealing with attributes for large
numbers of points in a vector file, that the sites format would have no
trouble with, just churn through them all and get there in the end.

I think that it is resolved (v.surf.rst, v.to.rast, ...),
because category-attribute pairs are selected first to sorted
array, so the access to attributes is fast enough.

Radim