RE: [GRASS5] v.digit color name mismatch

John_Gillette1 · February 24, 2003, 4:00pm

This is good information to know. I have been looking at vector
processing modules also and have wondered if I was "wasting"
my time by not looking at 5.1. My concern is that what I do
for 5.0 will change with 5.1. These comments make it clear to me
that I need to compile 5.1 and start looking at what's different.

In particular, I have been looking in v.digit and v.build at
topology building and checking routines to see how lower level
routines can be used to build higher level functions.

I'd also like to document what I figure out. The programming
manual has little information at this level of internals.

It would be good if we can coordinate our work. Or at least share
what areas we are working in. (I'm thinking specifically
of the vector area.)

John

-----Original Message-----
From: Helena Mitasova [mailto:hmitaso@unity.ncsu.edu]
Sent: Monday, February 24, 2003 10:16 AM
To: cheg01@attbi.com
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] v.digit color name mismatch

cheg01@attbi.com wrote:

>----- Original Message -----
>From: "Radim Blazek" <blazek@itc.it>
>To: <cheg01@attbi.com>; <grass5@grass.itc.it>
>Sent: Monday, February 24, 2003 12:53 AM
>Subject: Re: [GRASS5] v.digit color name mismatch
>
>
>>Hi Chris,
>>
>>I see that you are working on v.digit, I would like to only note
>>that work on v.digit in 5.1 was also started:
>>http://mpa.itc.it/radim/g51/v.digit3.png
>>
>>Radim
>>
>
>I suspect that 5.0 will continue to have a large user base
for some years
>to come. Is there an expeced release date for 5.1?
>
Chris, if you are doing anything with vector modules I are greatly
encourage you to look at 5.1
and coordinate your work with Radim. The vector capabilities
in 5.0 are
not adequate
and we all need to work on getting 5.0 merged with 5.1 as soon as
possible so that we can have a working version
of GRASS5.1 with everything in it - I expect that people will
switch to
GRASS5.1 as soon as it becomes
usable because of its vector and database support, so I would not put
much effort in fixing 5.0 vector stuff.
This is just my view, others may see it differently.

Helena

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

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

Chris_Heg · February 25, 2003, 1:39am

This may be a philosophic issue rather than a software issue. When I look
at the Grass website I see the words "stable release" and "supported"
associated with 5.0.0 and the words "highly experimental" and "use at you
own risk" associated with 5.1.x. That is not going to encourage a quick
transistion to the next version by the average user. My guess is that many
users are more interested in having a stable GIS even if the functions are
limited than having ideal functionality with unknown stability. I
absolutely support all efforts to improve future versions of Grass, but I
think it is a bit early to abandon efforts to clean up 5.0.0, even in areas
where it is weak, only 5 months after it hit the streets as an official
release. This is just my opinion. I am not a programmer, just an interested
user. I have a hard enough time understanding the geographic part without
using experimental software.

BTW: all of the developers have done a magnificent job making GRASS what it
is today. Thanks.

----- Original Message -----
From: "John Gillette" <JGillette@rfmd.com>
To: "Radim Blazek" <blazek@itc.it>; "Helena Mitasova"
<hmitaso@unity.ncsu.edu>; <cheg01@attbi.com>
Cc: <grass5@grass.itc.it>
Sent: Monday, February 24, 2003 8:00 AM
Subject: RE: [GRASS5] v.digit color name mismatch

This is good information to know. I have been looking at vector
processing modules also and have wondered if I was "wasting"
my time by not looking at 5.1. My concern is that what I do
for 5.0 will change with 5.1. These comments make it clear to me
that I need to compile 5.1 and start looking at what's different.

In particular, I have been looking in v.digit and v.build at
topology building and checking routines to see how lower level
routines can be used to build higher level functions.

I'd also like to document what I figure out. The programming
manual has little information at this level of internals.

It would be good if we can coordinate our work. Or at least share
what areas we are working in. (I'm thinking specifically
of the vector area.)

John

-----Original Message-----
From: Helena Mitasova [mailto:hmitaso@unity.ncsu.edu]
Sent: Monday, February 24, 2003 10:16 AM
To: cheg01@attbi.com
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] v.digit color name mismatch

cheg01@attbi.com wrote:

>----- Original Message -----
>From: "Radim Blazek" <blazek@itc.it>
>To: <cheg01@attbi.com>; <grass5@grass.itc.it>
>Sent: Monday, February 24, 2003 12:53 AM
>Subject: Re: [GRASS5] v.digit color name mismatch
>
>
>>Hi Chris,
>>
>>I see that you are working on v.digit, I would like to only note
>>that work on v.digit in 5.1 was also started:
>>http://mpa.itc.it/radim/g51/v.digit3.png
>>
>>Radim
>>
>
>I suspect that 5.0 will continue to have a large user base
for some years
>to come. Is there an expeced release date for 5.1?
>
Chris, if you are doing anything with vector modules I are greatly
encourage you to look at 5.1
and coordinate your work with Radim. The vector capabilities
in 5.0 are
not adequate
and we all need to work on getting 5.0 merged with 5.1 as soon as
possible so that we can have a working version
of GRASS5.1 with everything in it - I expect that people will
switch to
GRASS5.1 as soon as it becomes
usable because of its vector and database support, so I would not put
much effort in fixing 5.0 vector stuff.
This is just my view, others may see it differently.

Helena

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

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

Jaro_Hofierka2 · February 25, 2003, 7:10am

Hi,

I fully support your opinion. I am a developer but also a user and I understand very well how important
is a stable and reliable system in critical projects. As a developer I am a bit uncertain if I should work on modules
for grass5.1 or grass5.0 because some of grass5.0 modules have been already transfered to grass5.1.
If I want to make some improvements to grass modules should I work on grass5.0 or grass5.1 modules? As grass5.1 is
highly experimental and in some terms inreliable, I risk, as a user, that I will have to switch frequently between
grass5.0 and grass5.1. Moreover, a parallel development of identical modules may cause future problems
and extra work to merge all updates in grass5.2.
It is clear that at some point in the future all development works for grass5.0 must be stopped and all effort must be directed
to transition to grass5.2 (or grass5.1 stable). Otherwise we risk wasting time and effort of many people.
Perhaps a core team of grass5.1 developers should keep grass5.1 as minimal as possible in terms of number
of modules transferred from grass5.0 unless development of grass5.0 is stopped.

Jaro

cheg01@attbi.com wrote:

This may be a philosophic issue rather than a software issue. When I look
at the Grass website I see the words "stable release" and "supported"
associated with 5.0.0 and the words "highly experimental" and "use at you
own risk" associated with 5.1.x. That is not going to encourage a quick
transistion to the next version by the average user. My guess is that many
users are more interested in having a stable GIS even if the functions are
limited than having ideal functionality with unknown stability. I
absolutely support all efforts to improve future versions of Grass, but I
think it is a bit early to abandon efforts to clean up 5.0.0, even in areas
where it is weak, only 5 months after it hit the streets as an official
release. This is just my opinion. I am not a programmer, just an interested
user. I have a hard enough time understanding the geographic part without
using experimental software.

BTW: all of the developers have done a magnificent job making GRASS what it
is today. Thanks.

----- Original Message -----
From: "John Gillette" <JGillette@rfmd.com>
To: "Radim Blazek" <blazek@itc.it>; "Helena Mitasova"
<hmitaso@unity.ncsu.edu>; <cheg01@attbi.com>
Cc: <grass5@grass.itc.it>
Sent: Monday, February 24, 2003 8:00 AM
Subject: RE: [GRASS5] v.digit color name mismatch

This is good information to know. I have been looking at vector
processing modules also and have wondered if I was "wasting"
my time by not looking at 5.1. My concern is that what I do
for 5.0 will change with 5.1. These comments make it clear to me
that I need to compile 5.1 and start looking at what's different.

In particular, I have been looking in v.digit and v.build at
topology building and checking routines to see how lower level
routines can be used to build higher level functions.

I'd also like to document what I figure out. The programming
manual has little information at this level of internals.

It would be good if we can coordinate our work. Or at least share
what areas we are working in. (I'm thinking specifically
of the vector area.)

John

-----Original Message-----
From: Helena Mitasova [mailto:hmitaso@unity.ncsu.edu]
Sent: Monday, February 24, 2003 10:16 AM
To: cheg01@attbi.com
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] v.digit color name mismatch

cheg01@attbi.com wrote:

----- Original Message -----
From: "Radim Blazek" <blazek@itc.it>
To: <cheg01@attbi.com>; <grass5@grass.itc.it>
Sent: Monday, February 24, 2003 12:53 AM
Subject: Re: [GRASS5] v.digit color name mismatch

Hi Chris,

I see that you are working on v.digit, I would like to only note
that work on v.digit in 5.1 was also started:
http://mpa.itc.it/radim/g51/v.digit3.png

Radim

I suspect that 5.0 will continue to have a large user base

for some years

to come. Is there an expeced release date for 5.1?

Chris, if you are doing anything with vector modules I are greatly
encourage you to look at 5.1
and coordinate your work with Radim. The vector capabilities
in 5.0 are
not adequate
and we all need to work on getting 5.0 merged with 5.1 as soon as
possible so that we can have a working version
of GRASS5.1 with everything in it - I expect that people will
switch to
GRASS5.1 as soon as it becomes
usable because of its vector and database support, so I would not put
much effort in fixing 5.0 vector stuff.
This is just my view, others may see it differently.

Helena

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

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

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

Bernhard_Reiter · February 25, 2003, 10:47am

On Tue, Feb 25, 2003 at 08:10:10AM +0100, Jaro Hofierka wrote:

   I am a developer but also a user and
   I understand very well how important
   is a stable and reliable system in critical projects.

   As a developer I
   am a bit uncertain if I should work on modules
   for grass5.1 or grass5.0 because some of grass5.0 modules have been
   already transfered to grass5.1.

This kind of decision comes up more often
with our two lines of development.

To answer it you can try several criteria:

Size and stability of changes:

Bug fixes and stable minor feature enhancements should go to 5.0.x.

Structual changes and major feature enhancements
are more for 5.1.x or even 5.3.x.

How is your skill and engagement:

  Will you be active in GRASS development
  for short fixes or for a longer period (a year) and regular
  also helps to decide between helping the stable
  or the development version.

   It is clear that at some point in the future all development works for
   grass5.0 must be stopped and all effort must be directed
   to transition to grass5.2 (or grass5.1 stable). Otherwise we risk
   wasting time and effort of many people.
   Perhaps a core team of grass5.1 developers should keep grass5.1 as
   minimal as possible in terms of number
   of modules transferred from grass5.0 unless development of grass5.0 is
   stopped.

Experience with other big Free Software projects I follow
and GRASS itself shows that GRASS 5.0.x will be in use for quite a while.
We could switch it to full bug fixing only maintance mode
when usable 5.1.x development releases become available.

We can only stop bug fixing if 5.2.0 is released and stable.
Even then a community might decide to further maintain 5.0.x.

This may be a philosophic issue rather than a software issue. When I look
at the Grass website I see the words "stable release" and "supported"
associated with 5.0.0 and the words "highly experimental" and "use at you
own risk" associated with 5.1.x. That is not going to encourage a quick
transistion to the next version by the average user. My guess is that many
users are more interested in having a stable GIS even if the functions are
limited than having ideal functionality with unknown stability. I
absolutely support all efforts to improve future versions of Grass, but I
think it is a bit early to abandon efforts to clean up 5.0.0, even in areas
where it is weak, only 5 months after it hit the streets as an official
release. This is just my opinion. I am not a programmer, just an interested
user. I have a hard enough time understanding the geographic part without
using experimental software.

When I talked to Markus some years ago,
we found out that GRASS as many very conservative users.
They need very stable bug free versions.
This fact always kept proposed bigger changes from happening
as they will endanger stability.

The solution was to introduce CVS (with minor lines of development)
and two major lines of development like the Linux kernel has.
The drawbacks are that more back- and foreporting of code needs to happen
and more CVS skills are required.
The above mentioned advantages by far outweight the drawbacks, though.

BTW: all of the developers have done a magnificent job making GRASS what it
is today. Thanks.

You are welcome!

Radim_Blazek · February 25, 2003, 11:39am

On Monday 24 February 2003 05:00 pm, John Gillette wrote:

This is good information to know. I have been looking at vector
processing modules also and have wondered if I was "wasting"
my time by not looking at 5.1. My concern is that what I do
for 5.0 will change with 5.1. These comments make it clear to me
that I need to compile 5.1 and start looking at what's different.

In particular, I have been looking in v.digit and v.build at
topology building and checking routines to see how lower level
routines can be used to build higher level functions.

Learning topology in 5.0 is not wasting time, topology is almost
the same in 5.1. Working on modules alredy updated to 5.1
IS wasting of time, I think.

It would be good if we can coordinate our work. Or at least share
what areas we are working in. (I'm thinking specifically
of the vector area.)

If anybody wants to contribute to 5.1, please write to this list or
to me before you start. I'll start to do the same, once I see
that more people work on 5.1.

On Monday 24 February 2003 05:09 pm, Bernhard wrote:

However we try to get 5.1.x out and stable as fast
as possible which you probably should count in quarter of years.

The question is what may be released as 5.1.0, I think that it could
be released when it contains most of vector+sites functionality
from 5.0. Say 90% of modules?

We need people who fix bugs in 5.0.x and do maintance releases.
Vector support is not bad in principle it just could be a lot better.

Unfortunately the system how categories are stored and then attached
to lines and points IS bad in principle. It is not reliable and correct
data imported to 5.0 may lose it's attributes. That was why 5.1 was started.

On Tuesday 25 February 2003 02:39 am, Chris wrote:

This may be a philosophic issue rather than a software issue. When I look
at the Grass website I see the words "stable release" and "supported"
associated with 5.0.0 and the words "highly experimental" and "use at you
own risk" associated with 5.1.x. That is not going to encourage a quick
transistion to the next version by the average user.

Yes, and it will remain as it is if everybody says "it is not stable, I'll
work on stable". If you think that some hidden team of developers exists,
which will suddenly release stable 5.2, then that's not true.

My guess is that many
users are more interested in having a stable GIS even if the functions are
limited than having ideal functionality with unknown stability.

If you are improving v.digit/5.0 for other users than it is OK, I just
worried that you want to use it yourself
I agree that stable is often better, however I don't think that v.digit is
this case. Yes, many tools are missing in v.digit/5.1 but v.digit/5.0 is
realy terribly inefficient. I think that everybody who wants to use v.digit
more than one day, should consider
v.digit/5.1
v.out.ascii/5.1
v.in.ascii/5.0

Radim

Bernhard_Reiter · February 25, 2003, 12:07pm

On Tue, Feb 25, 2003 at 12:39:34PM +0100, Radim Blazek wrote:

On Monday 24 February 2003 05:09 pm, Bernhard wrote:
> However we try to get 5.1.x out and stable as fast
> as possible which you probably should count in quarter of years.

The question is what may be released as 5.1.0, I think that it could
be released when it contains most of vector+sites functionality
from 5.0. Say 90% of modules?

Sounds fine to me, though what about raster?

I agree that we should make a more precise plan if we can.
As you are the one most active on 5.1 I would happy if you can
propose something.

Note (for people just reading this post): 5.1.0 will be a development release.

> We need people who fix bugs in 5.0.x and do maintance releases.
> Vector support is not bad in principle it just could be a lot better.

Unfortunately the system how categories are stored and then attached
to lines and points IS bad in principle. It is not reliable and correct
data imported to 5.0 may lose it's attributes. That was why 5.1 was started.

When do we loose vector attributes?
If the vector support as limited as it is in 5.0. has serious flaws,
then we could consider to limit ourself to only fix this flaw for 5.2
and delay other things for 5.4.

On Tuesday 25 February 2003 02:39 am, Chris wrote:
> This may be a philosophic issue rather than a software issue. When I look
> at the Grass website I see the words "stable release" and "supported"
> associated with 5.0.0 and the words "highly experimental" and "use at you
> own risk" associated with 5.1.x. That is not going to encourage a quick
> transistion to the next version by the average user.

Yes, and it will remain as it is if everybody says "it is not stable, I'll
work on stable". If you think that some hidden team of developers exists,
which will suddenly release stable 5.2, then that's not true.

I agree with Radim that we need to people to progress 5.1.
Which does not mean that we should stop supporting 5.0.x.

> My guess is that many
> users are more interested in having a stable GIS even if the functions are
> limited than having ideal functionality with unknown stability.

If you are improving v.digit/5.0 for other users than it is OK, I just
worried that you want to use it yourself
I agree that stable is often better, however I don't think that v.digit is
this case. Yes, many tools are missing in v.digit/5.1 but v.digit/5.0 is
realy terribly inefficient. I think that everybody who wants to use v.digit
more than one day, should consider
v.digit/5.1
v.out.ascii/5.1
v.in.ascii/5.0

Radim_Blazek · February 25, 2003, 12:49pm

On Tuesday 25 February 2003 08:10 am, Jaro Hofierka wrote:

Hi,

I fully support your opinion. I am a developer but also a user and I
understand very well how important
is a stable and reliable system in critical projects. As a developer I
am a bit uncertain if I should work on modules
for grass5.1 or grass5.0 because some of grass5.0 modules have been
already transfered to grass5.1.
If I want to make some improvements to grass modules should I work on
grass5.0 or grass5.1 modules?

Which modules exactly? RST library? Most of files in that library is linked
from 5.0.

Perhaps a core team of grass5.1 developers should keep grass5.1 as
minimal as possible in terms of number
of modules transferred from grass5.0 unless development of grass5.0 is
stopped.

In other words: "Stop 5.1 development! We have to wait until 5.1 is stable."
Only vector modules are uploaded to 5.1, everything other is linked from 5.0.

I understand, that people using rasters only don't need 5.1, and their
life would be easier without 5.1, but to do something with vectors in 5.0
is realy problem, waiting hours for v.support, then get
WARNING: line xxxx label: xxxx matched another label: xxxx.,
create new vector for each attribute in shapefile, etc.

Radim

Chris_Heg · February 26, 2003, 3:33am

I get the following error building the latest 5.1 source on Solaris 8
Sparc:

make[2]: Entering directory `/usr3/grass51_012403/lib/gis'
gcc -g -Wall -Wall -I/usr3/grass51_012403/include -I/usr3/grass51_012403/
dist.sparc-sun-solaris2.8/include -I/usr3/grass51_012403/include -I/usr
3/grass51_012403/dist.sparc-sun-solaris2.8/include -I/usr/X11R6/include/ -I
/usr/include/gr -I/usr/local/include -I/usr/include -I/usr/local/pgsql/inc
lude -I/usr3/grass51_012403/include -I/usr3/grass51_012403/dist.sparc-sun-
solaris2.8/include \
-o OBJ.sparc-sun-solaris2.8/debug.o -c debug.c

debug.c: In function `G_debug':

debug.c:44: `__builtin_va_alist' undeclared (first use in this function)

Any suggestions?

Glynn_Clements · February 26, 2003, 5:22am

cheg01@attbi.com wrote:

I get the following error building the latest 5.1 source on Solaris 8
Sparc:

make[2]: Entering directory `/usr3/grass51_012403/lib/gis'
gcc -g -Wall -Wall -I/usr3/grass51_012403/include -I/usr3/grass51_012403/
dist.sparc-sun-solaris2.8/include -I/usr3/grass51_012403/include -I/usr
3/grass51_012403/dist.sparc-sun-solaris2.8/include -I/usr/X11R6/include/ -I
/usr/include/gr -I/usr/local/include -I/usr/include -I/usr/local/pgsql/inc
lude -I/usr3/grass51_012403/include -I/usr3/grass51_012403/dist.sparc-sun-
solaris2.8/include \
-o OBJ.sparc-sun-solaris2.8/debug.o -c debug.c

debug.c: In function `G_debug':

debug.c:44: `__builtin_va_alist' undeclared (first use in this function)

Any suggestions?

My suspicion is that the presence of -I/usr/include is causing the
problem; it typically results in Solaris' stdarg.h (which isn't
compatible with gcc) being used instead of gcc's version.

This appears to be due to the following lines in
include/Make/Platform.make.in:

PNGINC = -I/usr/X11R6/include/ -I/usr/include/gr -I/usr/local/include -I/usr/include
PNGLIB = -L/usr/local/lib -L/usr/X11R6/lib -L/usr/lib

I suggest that you change these lines to:

PNGINC = @PNGINC@
PNGLIB = @PNGLIB@

then re-run configure and re-compile.

In turn, this gives rise to two questions for Radim:

1. Why are these paths hardcoded, instead of using the values from the
configure script?

2. Why is $(PNGINC) being used for compiling libgis?

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

Jaro_Hofierka2 · February 26, 2003, 6:41am

Radim Blazek wrote:

On Tuesday 25 February 2003 08:10 am, Jaro Hofierka wrote:

Hi,

I fully support your opinion. I am a developer but also a user and I
understand very well how important
is a stable and reliable system in critical projects. As a developer I
am a bit uncertain if I should work on modules
for grass5.1 or grass5.0 because some of grass5.0 modules have been
already transfered to grass5.1.
If I want to make some improvements to grass modules should I work on
grass5.0 or grass5.1 modules?

Which modules exactly? RST library? Most of files in that library is linked from 5.0.

Perhaps a core team of grass5.1 developers should keep grass5.1 as
minimal as possible in terms of number
of modules transferred from grass5.0 unless development of grass5.0 is
stopped.

In other words: "Stop 5.1 development! We have to wait until 5.1 is stable."

Radim,

I am sorry but you don't understand what I am saying here. I just want avoid future problems and definitely don't want to stop the development of grass5.1.

Jaro

Jaro_Hofierka2 · February 26, 2003, 7:58am

Bernhard Reiter wrote:

  It is clear that at some point in the future all development works for
  grass5.0 must be stopped and all effort must be directed
  to transition to grass5.2 (or grass5.1 stable). Otherwise we risk
  wasting time and effort of many people.
  Perhaps a core team of grass5.1 developers should keep grass5.1 as
  minimal as possible in terms of number
  of modules transferred from grass5.0 unless development of grass5.0 is
  stopped.

Experience with other big Free Software projects I follow
and GRASS itself shows that GRASS 5.0.x will be in use for quite a while.
We could switch it to full bug fixing only maintance mode
when usable 5.1.x development releases become available.

We can only stop bug fixing if 5.2.0 is released and stable.
Even then a community might decide to further maintain 5.0.x.

OK, Bernhard, thanks for the explanation. I read the Description of GRASS 5.1 Milestones: Phase 1 and 2 and did not find any schedule for such development releases of grass5.1/5.2. I understand that it is sometimes difficult to estimate but from my point of view it is important for planning of my own work.
But I appreciate very much all work that has been done so far. Future GRASS looks very promising!

Jaro

neteler · February 26, 2003, 8:52am

On Tue, Feb 25, 2003 at 01:07:06PM +0100, Bernhard Reiter wrote:

On Tue, Feb 25, 2003 at 12:39:34PM +0100, Radim Blazek wrote:
> On Monday 24 February 2003 05:09 pm, Bernhard wrote:
> > However we try to get 5.1.x out and stable as fast
> > as possible which you probably should count in quarter of years.
>
> The question is what may be released as 5.1.0, I think that it could
> be released when it contains most of vector+sites functionality
> from 5.0. Say 90% of modules?

Sounds fine to me, though what about raster?

Let's say 90% of modules. This could be ready within some days
of generating the relevant Makefiles and the entries in the
50-to-51-links tool. Only hybrid modules with raster *and* vector
support such as r.flow need an update (which may be rather easy to
do).

[...]

> Unfortunately the system how categories are stored and then attached
> to lines and points IS bad in principle. It is not reliable and correct
> data imported to 5.0 may lose it's attributes. That was why 5.1 was started.

When do we loose vector attributes?

When you import vector maps. GRASS 5.0 supports only a single attribute.
Real world vector maps often come with a database table of attributes
(such as SHAPE/DBF, E00, MapInfo etc).
It is a real pain to work with such data in 5.0.

If the vector support as limited as it is in 5.0. has serious flaws,
then we could consider to limit ourself to only fix this flaw for 5.2
and delay other things for 5.4.

That means to reinvent the wheel? Bernhard, the idea of 5.1 is to
overcome the serious flaws of 5.0 BTW, it's functional...
I would not waste a minute to change the 5.0/5.2 design in terms of
the vector engine.

[...]

> Yes, and it will remain as it is if everybody says "it is not stable, I'll
> work on stable". If you think that some hidden team of developers exists,
> which will suddenly release stable 5.2, then that's not true.

I agree with Radim that we need to people to progress 5.1.
Which does not mean that we should stop supporting 5.0.x.

Right. But new vector development should be done in 5.1. Fixes may
go into 5.0 as well. Note that the 5.1 vector engine is much (!)
cleaner than that of 5.0.

[...]

> I think that everybody who wants to use v.digit
> more than one day, should consider
> v.digit/5.1
> v.out.ascii/5.1
> v.in.ascii/5.0

This is a good suggestion for the time of transition.

Another example: I have imported the world vector map of UNEP
http://www.grid.unep.ch/data/grid/downloads/boundaries.php
in E00 format (gnv19.tar.Z). With m.in.e00 (5.0) you get doubled
centroids and tons of warnings in v.support.
So I did:

gnv19.tar.Z -> m.in.e00 (5.0) -> v.convert (5.1) -> v.clean (5.1)
-> v.out.ascii (5.1) -> v.in.ascii (5.0)

Note that v.clean (5.0) will fail here...

When OGR will support ASCII E00 one day (already a request in bugzilla
of OGR), it will be much easier:

v.in.ogr (5.1) -> v.clean (5.1) -> v.out.ascii (5.1) -> v.in.ascii (5.0)

The v.in.ogr is already there and supports many formats.

To make GRASS a faster dinosaur, we have to focus on 5.1. Otherwise
it were dead (say, without users) one day.

Markus

PS: There is a 5.1 tutorial:
    http://grass.itc.it/grass51/tutorial/
    and the documented API
    http://grass.itc.it/grass51/manuals/

neteler · February 26, 2003, 8:59am

On Tue, Feb 25, 2003 at 07:33:39PM -0800, cheg01@attbi.com wrote:

I get the following error building the latest 5.1 source on Solaris 8
Sparc:

make[2]: Entering directory `/usr3/grass51_012403/lib/gis'
gcc -g -Wall -Wall -I/usr3/grass51_012403/include -I/usr3/grass51_012403/
dist.sparc-sun-solaris2.8/include -I/usr3/grass51_012403/include -I/usr
3/grass51_012403/dist.sparc-sun-solaris2.8/include -I/usr/X11R6/include/ -I
/usr/include/gr -I/usr/local/include -I/usr/include -I/usr/local/pgsql/inc
lude -I/usr3/grass51_012403/include -I/usr3/grass51_012403/dist.sparc-sun-
solaris2.8/include \
-o OBJ.sparc-sun-solaris2.8/debug.o -c debug.c

debug.c: In function `G_debug':

debug.c:44: `__builtin_va_alist' undeclared (first use in this function)

Any suggestions?

This was discussed some time ago, perhaps this thread is of help
for you?
http://grass.itc.it/pipermail/grass5/2001-July/000443.html

I have no SPARC here...

Markus

neteler · February 26, 2003, 9:01am

On Tuesday 25 February 2003 08:10 am, Jaro Hofierka wrote:

Perhaps a core team of grass5.1 developers should keep grass5.1 as
minimal as possible in terms of number
of modules transferred from grass5.0 unless development of grass5.0 is
stopped.

Jaro, the trick is that only a few files are changes as raster
modules are linked into 5.1. To keep synced the few different files
(e.g. in libgis) is not much work and we happily keep an eye on that.

Markus

Radim_Blazek · February 26, 2003, 9:30am

On Wednesday 26 February 2003 06:22 am, Glynn Clements wrote:

This appears to be due to the following lines in
include/Make/Platform.make.in:

PNGINC = -I/usr/X11R6/include/ -I/usr/include/gr -I/usr/local/include
-I/usr/include PNGLIB = -L/usr/local/lib -L/usr/X11R6/lib -L/usr/lib

I suggest that you change these lines to:

PNGINC = @PNGINC@
PNGLIB = @PNGLIB@

then re-run configure and re-compile.

In turn, this gives rise to two questions for Radim:

General answer for such questions is that I wanted to improve a bit
how vectors are stored and manipulated in GRASS.
It is not my ambition to rewrite whole GRASS, first I hoped that
5.1 will be joint work.

1. Why are these paths hardcoded, instead of using the values from the
configure script?

I used head.in from 5.0 as template for Platform.make.in and there
it was hardcoded. I think, that if something is obviously wrong,
anybody can fix it.

2. Why is $(PNGINC) being used for compiling libgis?

ALLINC = $(INC) $(PNGINC) $(ODBCINC) $(PQINCPATH)
and ALLINC is used in default rules. This is probably wrong,
we can remove $(PNGINC) and use EXTRA_INCL in modules,
but what to do with ODBCINC and PQINCPATH? Those must be used
in all vector libraries and modules. Is it necessary to define something
like EXTRA_INCL = $(VECT_INCL) in all vector modules or it is not harmful
in default rules (ALLINC).

Radim

Bernhard_Reiter · February 26, 2003, 9:52am

On Tue, Feb 25, 2003 at 10:44:43PM -0800, cheg01@attbi.com wrote:

Where can I find the correct proceedure for generating a patch? I assume it
is done with diff but I don't know exactly how.

If you have the right version checkout out via CVS,
you can use the "cvs diff -u" command.

This is the ideal solution as your patch will
most likely go clean into the CVS branch
and you also can see if somebody else changed something in this area.

In other cases you do
diff -u oldfile newfile >x.patch

If you have new and old version in two different directories,
it is easier to use
diff -ur olddirectory newdirectory >x.patch

Check the resulting file.
Rename it to something useful and add some documentation
to the begining. The "patch" program does ignore extra lines.

Some very general hints can also be found at:
http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/patching.html

Thanks,
Bernhard

Date: Mon, 24 Feb 2003 16:41:54 +0100
From: Bernhard Reiter <bernhard@intevation.de>
To: grass5@grass.itc.it
Subject: Re: [GRASS5] v.digit color name mismatch

Can you add your solution to bug report #1670?

https://intevation.de/rt/webrt?serial_num=1670&display=History
This is possible using email.
mail to grass-bugs a t intevation.de
having the following string within the subject line:
[bug #1670]

If you can produce a patch against CVS head
somebody with CVS access will commit it.

Radim_Blazek · February 26, 2003, 9:52am

On Tuesday 25 February 2003 01:07 pm, Bernhard Reiter wrote:

> The question is what may be released as 5.1.0, I think that it could
> be released when it contains most of vector+sites functionality
> from 5.0. Say 90% of modules?

Sounds fine to me, though what about raster?

5.0 and 5.1 may be run simultaneously, 5.0 commands may be run
from 5.1 shell after GISBASE export or we could copy compiled
modules from 5.0 to 5.1 during compilation.

> Unfortunately the system how categories are stored and then attached
> to lines and points IS bad in principle. It is not reliable and correct
> data imported to 5.0 may lose it's attributes. That was why 5.1 was
> started.

When do we loose vector attributes?

If lines cross or overlap or are close to each other. Have you never seen
WARNING: line xxxx label: xxxx matched another label: xxxx?

If the vector support as limited as it is in 5.0. has serious flaws,
then we could consider to limit ourself to only fix this flaw for 5.2
and delay other things for 5.4.

Fix? Do you think that to change format and consequently to rewrite all
vector modules may be called fix? 5.1 is such 'fix'. If you realy
want to do that, consider to use 5.1 format so that we don't have
to change format twice in 2 minor versions.

Radim

Bernhard_Reiter · February 26, 2003, 10:07am

On Wed, Feb 26, 2003 at 10:52:50AM +0100, Radim Blazek wrote:

On Tuesday 25 February 2003 01:07 pm, Bernhard Reiter wrote:
> > The question is what may be released as 5.1.0, I think that it could
> > be released when it contains most of vector+sites functionality
> > from 5.0. Say 90% of modules?
>
> Sounds fine to me, though what about raster?

5.0 and 5.1 may be run simultaneously, 5.0 commands may be run
from 5.1 shell after GISBASE export or we could copy compiled
modules from 5.0 to 5.1 during compilation.

Good.

> > Unfortunately the system how categories are stored and then attached
> > to lines and points IS bad in principle. It is not reliable and correct
> > data imported to 5.0 may lose it's attributes. That was why 5.1 was
> > started.
>
> When do we loose vector attributes?

If lines cross or overlap or are close to each other. Have you never seen
WARNING: line xxxx label: xxxx matched another label: xxxx?

Important to know.
I did not check the documentation for 5.0
is that problem properly documented?
It could avoid wasting time answering questions.

> If the vector support as limited as it is in 5.0. has serious flaws,
> then we could consider to limit ourself to only fix this flaw for 5.2
> and delay other things for 5.4.

Fix? Do you think that to change format and consequently to rewrite all
vector modules may be called fix? 5.1 is such 'fix'. If you realy
want to do that, consider to use 5.1 format so that we don't have
to change format twice in 2 minor versions.

You missunderstood me here.

I meant that
we should declare the main aim of 5.2
as the attempt to overcome the vector weaknesses
Naturally based on your efforts and the improved format.

The second point I was trying to make was
that we should then refrain from other big changes for 5.2
and only focus on improving the vector side.

This will shorten the time until your vector work is available for everybody.

Bernhard_Reiter · February 26, 2003, 10:18am

On Wed, Feb 26, 2003 at 08:58:44AM +0100, Jaro Hofierka wrote:

I appreciate very much all work that has been done so far.
Future GRASS looks very promising!

Wanted to highlight the kind words for all developers to see.

The main three guys earning the credit in my point of view are

  Radim for his 5.1 vector efforts
  Glynn sorting out the difficult C problems
  Markus still the sole main force behind the webpages

I've also noticed Eric and Roger (Bivand) being quite active
answering questions lately.

Bernhard_Reiter · February 26, 2003, 10:24am

On Wed, Feb 26, 2003 at 10:30:32AM +0100, Radim Blazek wrote:

On Wednesday 26 February 2003 06:22 am, Glynn Clements wrote:

> In turn, this gives rise to two questions for Radim:

General answer for such questions is that I wanted to improve a bit
how vectors are stored and manipulated in GRASS.
It is not my ambition to rewrite whole GRASS, first I hoped that
5.1 will be joint work.

Radim you are doing good work!
I hope that you feel the support of the development community,
because it is there.

In this situation I think Glynn just plainly wanted to know
if there is a special reason for it or not.
So it was not meant offensive at all.
It is clear that no single developer can completely master GRASS,
but together we stand a chance.