[GRASS5] 0 != no data

GRASS GIS GRASS GIS developer
1

Hello all

Sorry for the late reply, but I had other matters to take care of. As
per Markus' suggestions, some text has been changed in the post I
recommend we send to users. Please take a moment to review the post
below.

Markus Neteler wrote:

thanks for your nice proposal. A few remarks:

- Perhaps (even for the new users), an example may be added to
  demonstrate the 0 to be NULL thing

I'm not sure what you mean here. What kind of example are you thinking
of, a classification example?

- it should be pointed out, that GRASS 5 will keep the feature to
  store NULLs (for those not carefully ready), perhaps in a bottom
  summary
- it should be pointed out, that GRASS 5 will keep the feature to
  convert individual values to NULL and back
- maybe in a bottom summary it should be explained, that, if
  eliminating the feature of 0 to be NULL, that both groups (1) and
  (2) will stay happy, only that a conversion step is required (or
  not?).

OK I've made some changes, see the example post below.

BTW: Does anyone know a free poll server without adult images or
annoying ads? I don't want that they catch all the users' email
adresses and sell them anywhere.

Sorry I can't help you here, but we could simply have them reply to the
message or send their votes to me if we can't find a suitable poll site.

======================== Start of post ===============================

Subject: We need your opinion

Hello all users

Recently on the developers mailing list, there has been a discussion
concerning the current implementation of NULL. When the NULL concept was
first introduced and implemented there were basically 2 groups of users:

1. Those who worked mostly with classes and had a large number of
   files with 0 set as NULL

2. Those who started to use raster maps as representation of
   continuous fields and 0 was a data value

The majority of the users were in group 1 and thus, the decision was
made to keep the feature that 0 could be interpreted as NULL.

In the discussion on the developers list, some developers have indicated
that since GRASS 5.0 has the concept of NULL (which is represented by
non-zero values), it is confusing to also have the feature that 0 can be
interpreted as NULL, especially to new users of GRASS. This feature has
also caused some problems for some users who had greyscale aerial
photographs stored as raster maps in GRASS 4.x, and then transferred
them to GRASS 5.0. The problem was that the color black (value 0) was
being interpreted as NULL causing them to believe that their data had
been corrupted somehow.

In order to eliminate this confusion, a proposal was put forth on the
list that 0 should never be considered as NULL in GRASS 5.0. Also, in
order to facilitate those users who wish to use their GRASS 4.x files
with the new GRASS 5.0, we would provide a script to assist them in
converting the 0 values of their data to appropriate NULL values in
GRASS 5.0.

This script has not been written yet but the proposed usage would be
that a user would run the script and provide a list of GRASS 4.x
databases which contain raster files in which 0 should be interpreted as
NULL. The script will automatically go through all locations and mapsets
in each database and perform the conversion for all raster files. The
only requirement for this script would be that the GRASS 4.x data would
have to be maintained in proper GRASS databases. That is, all
directories under a database will be locations, and all directories
under a location will be mapsets. If a user has files that he/she does
not want converted then either the files can be moved to a different
database, or the user can provide a specific location, or mapset, or
raster file to the script.

In summary, the proposal is to remove the feature of 0 being interpreted
as NULL from GRASS 5.0. It is important to remember that GRASS 5.0 will
store well defined NULL values (non-zero) and that GRASS 5.0 will
provide the capability to convert any value to NULL or vice versa. Note
that the elimination of this feature will satisfy both groups of users
since both NULL values and 0 will be available to users. The only
consequence of this removal is that a conversion process will be
necessary for converting GRASS 4.x data into GRASS 5.0 data.

What we would like you to do is provide us with your opinion on whether
we should keep the feature of 0 being interpreted as NULL. To make
things a little easier, we would like you to reply to this post stating
which of the following options (a or b) you wish to support.

    a) Keep the feature of 0 being optionally interpreted as NULL in
       GRASS 5.0
    b) Eliminate the feature from GRASS 5.0, but a script will be
       provided to convert GRASS 4.x files to GRASS 5.0 format for
       those who wish 0 to be NULL

Thank you for your time in this matter.

========================= End of post ================================

Once again, any comments in the wording of the above post are welcome.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

2

Hello Justin, hello all,

Shouldn't there be an introductory phrase reminding people what this NULL
business is all about ? I would imagine some users out there might not fully
understand what we're talking about.

Moritz

Quoting Justin Hickey <jhickey@hpcc.nectec.or.th>:

Hello all

Sorry for the late reply, but I had other matters to take care of. As
per Markus' suggestions, some text has been changed in the post I
recommend we send to users. Please take a moment to review the post
below.

Markus Neteler wrote:
> thanks for your nice proposal. A few remarks:
>
> - Perhaps (even for the new users), an example may be added to
> demonstrate the 0 to be NULL thing

I'm not sure what you mean here. What kind of example are you thinking
of, a classification example?

> - it should be pointed out, that GRASS 5 will keep the feature to
> store NULLs (for those not carefully ready), perhaps in a bottom
> summary
> - it should be pointed out, that GRASS 5 will keep the feature to
> convert individual values to NULL and back
> - maybe in a bottom summary it should be explained, that, if
> eliminating the feature of 0 to be NULL, that both groups (1) and
> (2) will stay happy, only that a conversion step is required (or
> not?).

OK I've made some changes, see the example post below.

> BTW: Does anyone know a free poll server without adult images or
> annoying ads? I don't want that they catch all the users' email
> adresses and sell them anywhere.

Sorry I can't help you here, but we could simply have them reply to the
message or send their votes to me if we can't find a suitable poll
site.

======================== Start of post ===============================

Subject: We need your opinion

Hello all users

Recently on the developers mailing list, there has been a discussion
concerning the current implementation of NULL. When the NULL concept
was
first introduced and implemented there were basically 2 groups of
users:

1. Those who worked mostly with classes and had a large number of
   files with 0 set as NULL

2. Those who started to use raster maps as representation of
   continuous fields and 0 was a data value

The majority of the users were in group 1 and thus, the decision was
made to keep the feature that 0 could be interpreted as NULL.

In the discussion on the developers list, some developers have
indicated
that since GRASS 5.0 has the concept of NULL (which is represented by
non-zero values), it is confusing to also have the feature that 0 can
be
interpreted as NULL, especially to new users of GRASS. This feature has
also caused some problems for some users who had greyscale aerial
photographs stored as raster maps in GRASS 4.x, and then transferred
them to GRASS 5.0. The problem was that the color black (value 0) was
being interpreted as NULL causing them to believe that their data had
been corrupted somehow.

In order to eliminate this confusion, a proposal was put forth on the
list that 0 should never be considered as NULL in GRASS 5.0. Also, in
order to facilitate those users who wish to use their GRASS 4.x files
with the new GRASS 5.0, we would provide a script to assist them in
converting the 0 values of their data to appropriate NULL values in
GRASS 5.0.

This script has not been written yet but the proposed usage would be
that a user would run the script and provide a list of GRASS 4.x
databases which contain raster files in which 0 should be interpreted
as
NULL. The script will automatically go through all locations and
mapsets
in each database and perform the conversion for all raster files. The
only requirement for this script would be that the GRASS 4.x data would
have to be maintained in proper GRASS databases. That is, all
directories under a database will be locations, and all directories
under a location will be mapsets. If a user has files that he/she does
not want converted then either the files can be moved to a different
database, or the user can provide a specific location, or mapset, or
raster file to the script.

In summary, the proposal is to remove the feature of 0 being
interpreted
as NULL from GRASS 5.0. It is important to remember that GRASS 5.0 will
store well defined NULL values (non-zero) and that GRASS 5.0 will
provide the capability to convert any value to NULL or vice versa. Note
that the elimination of this feature will satisfy both groups of users
since both NULL values and 0 will be available to users. The only
consequence of this removal is that a conversion process will be
necessary for converting GRASS 4.x data into GRASS 5.0 data.

What we would like you to do is provide us with your opinion on whether
we should keep the feature of 0 being interpreted as NULL. To make
things a little easier, we would like you to reply to this post stating
which of the following options (a or b) you wish to support.

    a) Keep the feature of 0 being optionally interpreted as NULL in
       GRASS 5.0
    b) Eliminate the feature from GRASS 5.0, but a script will be
       provided to convert GRASS 4.x files to GRASS 5.0 format for
       those who wish 0 to be NULL

Thank you for your time in this matter.

========================= End of post ================================

Once again, any comments in the wording of the above post are welcome.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5

-------------------------------------------------
This mail sent through Tiscalinet Webmail (http://webmail.tiscalinet.be)

3

Justin and friends,

Would this modified version answer Moritz' question? I agree with him that
we might risk getting a limited response because a regular 4.* user
mightn't grasp the issue. I haven't got a 4.3 installed, but as far as I
remember, there aren't any NULL values in the 4,* series are there? Can
someone please check? I've also added a third, compromise, choice - remove
0 as NULL from 5.1, but retain it in 5.0: the motivation is to lower the
threshold for 4.* users migrating to 5.*. I shortened the draft by taking
out the script details - they are valuable, but could be included as a
link to a note on the website.

Roger

------------------------------------------------------------
Subject: Representation of "no data": we need your opinion

Hello all users

Could we please ask you to review the issue of the representation of
"no data" described below and give us your views on the alternatives we
propose? This affects users of GRASS 4.* considering moving to GRASS 5.*,
and users of GRASS 5.0 beta who depend on using legacy data. This is your
chance to influence a major decision which may impact your use of GRASS!

Recently on the developers' mailing list, there has been a discussion
concerning the current representation of "no data" in raster map
layers. When working with categories/classes, it was convenient to use
integer zero (0) to express "no data", because the classes each had
non-zero numbers - like land-use classes. This is the position in GRASS
up to 4.*. GRASS 5.0 beta integrated experimental work done over many
years by people needing both floating-point raster values, and needing
to use numeric zero as a number.

This meant that representing "no data" raised a conflict of interest:
people with legacy data didn't want their "no data" (0) to "come back to
life", while the numerical people really needed zero, as in zero slope,
to have a meaning other than "no data". The term introduced to cover
"no data" is "NULL", which can include both "no data available", and
other situations where no numeric representation exists, like log of a
negative number, or dividing by zero.

There were then basically 2 groups of users in the mid 1990's:

1. Those who worked mostly with classes and had a large number of
   files with 0 set as "no data"

2. Those who started to use raster maps as representation of
   continuous fields and 0 was a data value

The majority of the users were in group 1 and thus, the decision was
made to keep the feature that 0 could be interpreted as "no data".

In the discussion on the developers' list, some developers have indicated
that, since GRASS 5.0 implements the concept of NULL (which is represented
by machine dependent constants), it is confusing to also have the feature
that 0 can be interpreted as NULL, especially to new users of GRASS. NULL
is implemented as a separate mask of bits representing "data"/"no data",
in principle for each raster map layer, but not all modules generate them
automatically, meaning that users not knowing the history get mixed up.

In order to eliminate this confusion, a proposal was made that 0
should never be considered as "no data" in GRASS 5.0. Also, in order to
facilitate those users who wish to use their GRASS 4.x files with the
new GRASS 5.0, we would provide a script to assist them in converting
the 0 values of their data to appropriate NULL values in GRASS 5.0.

What we would like you to do is provide us with your opinion on whether
we should keep the feature of 0 being interpreted as "no data". To make
things a little easier, we would like you to reply to this post stating
which of the following options you wish to support:

    a) Full legacy interoperability: keep the feature of 0 being
       optionally interpreted as "no data"

    b) Transition from GRASS 5.0 onwards: keep the feature of 0 being
       optionally interpreted as "no data" in GRASS 5.0 only, eliminating
       it in subsequent releases
       
    c) Transition now: eliminate the feature from GRASS 5.0, but provide
       a script to convert GRASS 4.x files to GRASS 5.0 format for those
       who wish 0 to be NULL

Thank you for your time in this matter.

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

From neteler Tue Jun 19 13:25:37 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id NAA25667; Tue, 19 Jun 2001 13:25:37 +0100
Date: Tue, 19 Jun 2001 13:25:36 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: Grass Developers <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Error to compile i.fft
Message-ID: <20010619132536.M19538@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: Grass Developers <grass5@geog.uni-hannover.de>
References: <3B2F1895.3F60653F@hpcc.nectec.or.th>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B2F1895.3F60653F@hpcc.nectec.or.th>; from jhickey@hpcc.nectec.or.th on Tue, Jun 19, 2001 at 04:17:09PM +0700
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 660
Lines: 23

On Tue, Jun 19, 2001 at 04:17:09PM +0700, Justin Hickey wrote:

Hello all

I just compiled the latest sources from the release branch and received
the following error for src/imagery/i.fft

ld32: FATAL 9: I/O error
(/.../grass/src/libes/LIB.mips-sgi-irix6.5/libgmath.a): No such file or
directory
*** Error code 2 (bu21)
*** Error code 1 (bu21)

I thought the gmath library was supposed to be compiled?

Sorry for this! I have accidentally uploaded my new changes to clear up
the numerical methods mess (the idea is to centralize all the fft.c and
friends in src/libes/gmath).

O.k., will finish that now.

Thanks for the hint,

Markus

From neteler Tue Jun 19 14:02:25 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id OAA25980; Tue, 19 Jun 2001 14:02:25 +0100
Date: Tue, 19 Jun 2001 14:02:25 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: Grass Developers <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Error to compile i.fft
Message-ID: <20010619140224.A25873@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: Grass Developers <grass5@geog.uni-hannover.de>
References: <3B2F1895.3F60653F@hpcc.nectec.or.th> <20010619132536.M19538@hgeo02.geog.uni-hannover.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010619132536.M19538@hgeo02.geog.uni-hannover.de>; from neteler@geog.uni-hannover.de on Tue, Jun 19, 2001 at 01:25:36PM +0100
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 1454
Lines: 42

Hi,

again on the "gmath"/numerical functions issue...
I need a recommendation.

Currently we face following situation:

- src/libes/gmath/ has been written by David to support LAPACK/BLAS
   (it contains wrapper functions)
- we have spreading around numerous files containing various numerical
   functions like fft, ifft, matrix operations etc.

My intention is to assemble all functionality in one library. So
I started to migrate all such functions into src/libes/gmath/
(as I did for i.fft and accidentially already uploaded).

A problem arises on those machines, which don't have LAPACK/BLAS and "g2c"
(requirement, which is the former f2c.h) installed.
For example you will get, when compiling "gmath":
  src/include/la.h:28: g2c.h: No such file or directory
  make: *** [OBJ.sparc-sun-solaris2.6/la.o] Error 1

Two solutions may the at our choice:

  (1) split the library into two libraries
         a) LAPACK/BLAS routines
         b) others
  (2) add some clever mechanism to selectively compile with/without
      LAPACK/BLAS support. So far "configure" checks already the presence
      of LAPACK/BLAS.

I would vote for (2), but don't know how to implement it. Must be some
ifdef's around "la.h"?

Assistance is welcome,

Markus

PS: In Russia they have developed a parallelized version of s.surf.idw
    which is available here (MPI):
    http://www.tigers.ru/grass_docs/progs/DESCRIPTION.html
    Where to store this module in CVS?

4

On Tue, 19 Jun 2001, Justin Hickey wrote:

Please take a moment to review the post below.

  The notice is complete and clearly written. FWIW, my vote continues to
treat 0 separate from NULL, and provide a script for the 4.x users. GRASS
has advanced with the 5.x series and will continue to do so. NULL is not
zero and this should be the new paradigm.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                 Making environmentally-responsible mining happen.

5

Roger's introduction really helps to clarify what the message is all about.
I would just slightly modify the following sentence, to make it clear that
only
those GRASS4.* files/databases which use 0 as "no data" need to be converted.

------
Also, in order to facilitate those users who wish to use their GRASS 4.x
files which
use 0 as "no data" with the new GRASS 5.0, we would provide a script to
assist them in converting
the 0 values of their data to appropriate NULL values in GRASS 5.0.
------

Helena

Roger Bivand wrote:

Justin and friends,

Would this modified version answer Moritz' question? I agree with him that
we might risk getting a limited response because a regular 4.* user
mightn't grasp the issue. I haven't got a 4.3 installed, but as far as I
remember, there aren't any NULL values in the 4,* series are there? Can
someone please check? I've also added a third, compromise, choice - remove
0 as NULL from 5.1, but retain it in 5.0: the motivation is to lower the
threshold for 4.* users migrating to 5.*. I shortened the draft by taking
out the script details - they are valuable, but could be included as a
link to a note on the website.

Roger

------------------------------------------------------------
Subject: Representation of "no data": we need your opinion

Hello all users

Could we please ask you to review the issue of the representation of
"no data" described below and give us your views on the alternatives we
propose? This affects users of GRASS 4.* considering moving to GRASS 5.*,
and users of GRASS 5.0 beta who depend on using legacy data. This is your
chance to influence a major decision which may impact your use of GRASS!

Recently on the developers' mailing list, there has been a discussion
concerning the current representation of "no data" in raster map
layers. When working with categories/classes, it was convenient to use
integer zero (0) to express "no data", because the classes each had
non-zero numbers - like land-use classes. This is the position in GRASS
up to 4.*. GRASS 5.0 beta integrated experimental work done over many
years by people needing both floating-point raster values, and needing
to use numeric zero as a number.

This meant that representing "no data" raised a conflict of interest:
people with legacy data didn't want their "no data" (0) to "come back to
life", while the numerical people really needed zero, as in zero slope,
to have a meaning other than "no data". The term introduced to cover
"no data" is "NULL", which can include both "no data available", and
other situations where no numeric representation exists, like log of a
negative number, or dividing by zero.

There were then basically 2 groups of users in the mid 1990's:

1. Those who worked mostly with classes and had a large number of
   files with 0 set as "no data"

2. Those who started to use raster maps as representation of
   continuous fields and 0 was a data value

The majority of the users were in group 1 and thus, the decision was
made to keep the feature that 0 could be interpreted as "no data".

In the discussion on the developers' list, some developers have indicated
that, since GRASS 5.0 implements the concept of NULL (which is represented
by machine dependent constants), it is confusing to also have the feature
that 0 can be interpreted as NULL, especially to new users of GRASS. NULL
is implemented as a separate mask of bits representing "data"/"no data",
in principle for each raster map layer, but not all modules generate them
automatically, meaning that users not knowing the history get mixed up.

In order to eliminate this confusion, a proposal was made that 0
should never be considered as "no data" in GRASS 5.0. Also, in order to
facilitate those users who wish to use their GRASS 4.x files with the
new GRASS 5.0, we would provide a script to assist them in converting
the 0 values of their data to appropriate NULL values in GRASS 5.0.

What we would like you to do is provide us with your opinion on whether
we should keep the feature of 0 being interpreted as "no data". To make
things a little easier, we would like you to reply to this post stating
which of the following options you wish to support:

    a) Full legacy interoperability: keep the feature of 0 being
       optionally interpreted as "no data"

    b) Transition from GRASS 5.0 onwards: keep the feature of 0 being
       optionally interpreted as "no data" in GRASS 5.0 only, eliminating
       it in subsequent releases

    c) Transition now: eliminate the feature from GRASS 5.0, but provide
       a script to convert GRASS 4.x files to GRASS 5.0 format for those
       who wish 0 to be NULL

Thank you for your time in this matter.

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

_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5

From neteler Tue Jun 19 17:13:17 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id RAA27152; Tue, 19 Jun 2001 17:13:17 +0100
Date: Tue, 19 Jun 2001 17:13:17 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 developers list <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] bezier curves
Message-ID: <20010619171316.F25873@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5 developers list <grass5@geog.uni-hannover.de>
References: <3B2EEB37.91763E99@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B2EEB37.91763E99@yahoo.com>; from agarwal_somesh@yahoo.com on Tue, Jun 19, 2001 at 11:33:35AM +0530
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 360
Lines: 13

On Tue, Jun 19, 2001 at 11:33:35AM +0530, Somesh Agarwal wrote:

hi , is there some utility by which i can draw bezier curves on grass
(either on XDRIVER or PPM) ...
thanks

Hi Somesh,

as far as I know no bezier in available in GRASS 5. However (maybe
not useful for you), splines are available in v.digit and some
interpolation modules.

Regards
Markus

6

Hello all

First of all, thank you to all who gave comments and suggested
improvements. They were greatly appreciated.

Roger Bivand wrote:

Justin and friends,

Would this modified version answer Moritz' question? I agree with him
that we might risk getting a limited response because a regular 4.*
user mightn't grasp the issue. I haven't got a 4.3 installed, but as
far as I remember, there aren't any NULL values in the 4,* series are
there? Can someone please check?

If I recall correctly, GRASS 4.x does not have NULL values.

I've also added a third, compromise, choice - remove
0 as NULL from 5.1, but retain it in 5.0: the motivation is to lower
the threshold for 4.* users migrating to 5.*. I shortened the draft
by taking out the script details - they are valuable, but could be
included as a link to a note on the website.

OK thanks for your suggestions.

Below is Roger's post with Helena's suggestion (thanks Helena) added in
as well as a couple of my own. If there are no more comments for this
version, I'll send it to the user's list tomorrow.

Summary of my changes:

Changed

    NULL is implemented as a separate mask of bits representing
    "data"/"no data",

to

    NULL is implemented as a separate mask of bits representing "no
    data",

since I think saying "NULL represents "data" " is confusing.

Added

    Please note that incidents caused by such confusion have been
    reported.

to the same paragraph the above comes from to indicate that this issue
is causing problems for people and it is not just a wish of the
developers to make this change.

Added

    Please see details of the proposed script at the following site

    http://www.geog.uni-hannover.de/grass/nullConvert.html

to indicate where users could find details of the conversion script.

Added

    Note that GRASS 5.0 can convert any value to NULL and vice versa.

to include Markus's earlier comment.

------------------------------------------------------------
Subject: Representation of "no data": we need your opinion

Hello all users

Could we please ask you to review the issue of the representation of "no
data" described below and give us your views on the alternatives we
propose? This affects users of GRASS 4.* considering moving to GRASS
5.*, and users of GRASS 5.0 beta who depend on using legacy data. This
is your chance to influence a major decision which may impact your use
of GRASS!

Recently on the developers' mailing list, there has been a discussion
concerning the current representation of "no data" in raster map layers.
When working with categories/classes, it was convenient to use integer
zero (0) to express "no data", because the classes each had non-zero
numbers - like land-use classes. This is the position in GRASS up to
4.*. GRASS 5.0 beta integrated experimental work done over many years by
people needing both floating-point raster values, and needing to use
numeric zero as a number.

This meant that representing "no data" raised a conflict of interest:
people with legacy data didn't want their "no data" (0) to "come back to
life", while the numerical people really needed zero, as in zero slope,
to have a meaning other than "no data". The term introduced to cover "no
data" is "NULL", which can include both "no data available", and other
situations where no numeric representation exists, like log of a
negative number, or dividing by zero.

There were then basically 2 groups of users in the mid 1990's:

1. Those who worked mostly with classes and had a large number of
   files with 0 set as "no data"

2. Those who started to use raster maps as representation of
   continuous fields and 0 was a data value

The majority of the users were in group 1 and thus, the decision was
made to keep the feature that 0 could be interpreted as "no data".

In the discussion on the developers' list, some developers have
indicated that, since GRASS 5.0 implements the concept of NULL (which is
represented by machine dependent constants), it is confusing to also
have the feature that 0 can be interpreted as NULL, especially to new
users of GRASS. NULL is implemented as a separate mask of bits
representing "no data", in principle for each raster map layer, but not
all modules generate them automatically, meaning that users not knowing
the history get mixed up. Please note that incidents caused by such
confusion have been reported.

In order to eliminate this confusion, a proposal was made that 0 should
never be considered as "no data" in GRASS 5.0. Also, in order to
facilitate those users who wish to use their GRASS 4.x files which use 0
as "no data" with the new GRASS 5.0, we would provide a script to assist
them in converting the 0 values of their data to appropriate NULL values
in GRASS 5.0. Note that GRASS 5.0 can convert any value to NULL and vice
versa. Please see details of the proposed script at the following site

http://www.geog.uni-hannover.de/grass/nullConvert.html

What we would like you to do is provide us with your opinion on whether
we should keep the feature of 0 being interpreted as "no data". To make
things a little easier, we would like you to reply to this post stating
which of the following options you wish to support:

    a) Full legacy interoperability: keep the feature of 0 being
       optionally interpreted as "no data"

    b) Transition from GRASS 5.0 onwards: keep the feature of 0 being
       optionally interpreted as "no data" in GRASS 5.0 only,
       eliminating it in subsequent releases

    c) Transition now: eliminate the feature from GRASS 5.0, but
       provide a script to convert GRASS 4.x files to GRASS 5.0 format
       for those who wish 0 to be NULL

Thank you for your time in this matter.

------------------------------------------------------------

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!