Details Ticket 816


Comment | Reply | Take | Open


Serial Number 816
Subject r.in.bin
Area bug
Queue grass
Requestors delclaux@msem.univ-montp2.fr
Owner none
Status resolved
Last User Contact Wed Nov 28 09:55:16 2001 (7 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Feb 27 05:13:28 2002 (7 yr ago)
Created Wed Oct 10 16:57:07 2001 (7 yr ago)

Transaction History Ticket 816


Wed, Oct 10 2001 16:57:07    Request created by guest  
Subject: r.in.bin

Platform: Linux/Intel
Linux distro: RedHat
linux cpu: Intel (i486, i586, pentium ...)
Xwindows version: Xfree 4.0.x
Xwindows manager: KDE 2.x
TclTk version: tcl/tk 8.3
grass binary for platform: I compiled the sources myself
grass sources source: no, I got a source code package from the server, grass5.0.pre2
c compiler name: gcc

Please enter error description here
When importing binary raster file with r.in.bin, the option "number of bytes/cell"
is not taken into account.

I tried to import lat./long. AVHRR ancillary files.
The projection is Goode Homolosine.
The data are 2 bytes, according the NOAA documentation 
(cf. http://daac.gsfc.nasa.gov/CAMPAIGN_DOCS/FTP_SITE/readmes/pal.html)
________________________________________________________________________ 
 Parm.         bits               Offset        Gain        Bin. min/max
___________________________________________________________________  
  lat          16-bit unsigned       9010        .01         10 / 18010
  lon          16-bit unsigned      18010        .01         10 / 36010  ___________________________
____________________________________________
Consequently, I used the following commands :

r.in.bin  input=avhrrpf.lat.1nnfaf output=avhrrpf.lat.1nnfaf bytes=2 north=38.5
south=-37.8 east=61.3 west=-20 r=1060 c=1100 
r.in.bin  input=avhrrpf.lon.1nnfaf output=avhrrpf.lon.1nnfaf bytes=2 north=38.5
south=-37.8 east=61.3 west=-20 r=1060 c=1100 

But the r.support command gave me 4 bytes/cell.

For getting the correct raster layer, I had to copy the binary files in cell
directory, to edit the cellhd file, and to run the r.support command.

Fri, Nov 9 2001 15:33:22    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@mailman.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <15339.57512.471663.870093@cerise.nosuchdomain.co.uk>
Date Fri, 9 Nov 2001 13:56:56 +0000
To Request Tracker <grass-bugs@intevation.de>
Cc GRASS developers list <grass5@grass.itc.it>, Bob Covill <bcovill@tekmap.ns.ca>
Subject Re: [GRASS5] [bug #816] (grass) r.in.bin
In-Reply-To <20011010145707.E581513A06@mailman.intevation.de>
References <20011010145707.E581513A06@mailman.intevation.de>
X-Mailer VM 6.94 under 21.4 (patch 4) "Artificial Intelligence (candidate #1)" XEmacs Lucid
Request Tracker wrote:

> Subject: r.in.bin

> When importing binary raster file with r.in.bin, the option "number
> of bytes/cell" is not taken into account.
> 
> I tried to import lat./long. AVHRR ancillary files.
> The projection is Goode Homolosine.
> The data are 2 bytes, according the NOAA documentation 
> (cf. http://daac.gsfc.nasa.gov/CAMPAIGN_DOCS/FTP_SITE/readmes/pal.html)
> ________________________________________________________________________ 
>  Parm.         bits               Offset        Gain        Bin. min/max
> ___________________________________________________________________  
>   lat          16-bit unsigned       9010        .01         10 / 18010
>   lon          16-bit unsigned      18010        .01         10 / 36010  _________________________
______________________________________________
> 
> Consequently, I used the following commands :
> 
> r.in.bin  input=avhrrpf.lat.1nnfaf output=avhrrpf.lat.1nnfaf bytes=2 north=38.5
south=-37.8 east=61.3 west=-20 r=1060 c=1100 
> r.in.bin  input=avhrrpf.lon.1nnfaf output=avhrrpf.lon.1nnfaf bytes=2 north=38.5
south=-37.8 east=61.3 west=-20 r=1060 c=1100 
> 
> But the r.support command gave me 4 bytes/cell.
> 
> For getting the correct raster layer, I had to copy the binary files in cell
>  directory, to edit the cellhd file, and to run the r.support command.

1. Is this actually a problem?

2. Is there likely to be any significant space reduction from using
1-byte or 2-byte cells, or will the compression mean that there's no
significant difference?

3. Should r.in.bin set the internal format according to the original
format?

AFAICT, the two formats can only match when importing signed data
without null values. If the data is unsigned, or contains nulls,
presumably the next size up would have to be used (unless the input
data is first scanned to determine its range; is this worthwhile?)

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


Wed, Nov 28 2001 09:55:16    Mail sent by francois.delclaux@msem.univ-montp2.fr  
Return-Path <francois.delclaux@msem.univ-montp2.fr>
Delivered-To grass-bugs@lists.intevation.de
Sender Francois.Delclaux@msem.univ-montp2.fr
Message-ID <3C04A65F.987BA8B8@msem.univ-montp2.fr>
Date Wed, 28 Nov 2001 08:54:55 +0000
From Francois Delclaux <francois.delclaux@msem.univ-montp2.fr>
Organization UMR HSM
X-Mailer Mozilla 4.76 [fr] (X11; U; Linux 2.4.2-ac3 i686)
X-Accept-Language fr-FR, en
MIME-Version 1.0
To Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [bug #816] (grass) Transaction (glynn.clements@virgin.net)
References <20011109143322.1644613A05@mailman.intevation.de>
Content-Type text/plain; charset=iso-8859-1
Content-Transfer-Encoding quoted-printable
Glynn Clements via RT a =E9crit :

> this bug's URL: http://intevation.de/rt/webrt?serial_num=3D816
>
> Fri, Nov 9 2001 15:33:22: Request 816 was acted upon.
>
>  Transaction: Mail sent by glynn.clements@virgin.net
>
>        Queue: grass
>         Area: bug
>      Subject: r.in.bin
>        Owner:
>   Requestors: delclaux@msem.univ-montp2.fr
>       Status: open
>
> -----------------------------------------------------------------------=
--
>
> Request Tracker wrote:
>
> > Subject: r.in.bin
>
> > When importing binary raster file with r.in.bin, the option "number
> > of bytes/cell" is not taken into account.
> >
> > I tried to import lat./long. AVHRR ancillary files.
> > The projection is Goode Homolosine.
> > The data are 2 bytes, according the NOAA documentation
> > (cf. http://daac.gsfc.nasa.gov/CAMPAIGN_DOCS/FTP_SITE/readmes/pal.htm=
l)
> > _____________________________________________________________________=
___
> >  Parm.         bits               Offset        Gain        Bin. min/=
max
> > ___________________________________________________________________
> >   lat          16-bit unsigned       9010        .01         10 / 180=
10
> >   lon          16-bit unsigned      18010        .01         10 / 360=
10  _____________________________________________________________________=
__
> >
> > Consequently, I used the following commands :
> >
> > r.in.bin  input=3Davhrrpf.lat.1nnfaf output=3Davhrrpf.lat.1nnfaf byte=
s=3D2 north=3D38.5 south=3D-37.8 east=3D61.3 west=3D-20 r=3D1060 c=3D1100=

> > r.in.bin  input=3Davhrrpf.lon.1nnfaf output=3Davhrrpf.lon.1nnfaf byte=
s=3D2 north=3D38.5 south=3D-37.8 east=3D61.3 west=3D-20 r=3D1060 c=3D1100=

> >
> > But the r.support command gave me 4 bytes/cell.
> >
> > For getting the correct raster layer, I had to copy the binary files =
in cell
> >  directory, to edit the cellhd file, and to run the r.support command=
=2E
>
> 1. Is this actually a problem?

Yes, because I have more than 100 maps to be integrated in my base,
and the work must be done with a script. But r.support can't be activated=

in a shell.

>
>
> 2. Is there likely to be any significant space reduction from using
> 1-byte or 2-byte cells, or will the compression mean that there's no
> significant difference?

In my mind, the problem is not related to compression.

>
>
> 3. Should r.in.bin set the internal format according to the original
> format?

No, because the input data are 2 bytes/cell, and interpreted data are con=
sidered as 4bytes/cell
by r.support

>
>
> AFAICT, the two formats can only match when importing signed data
> without null values. If the data is unsigned, or contains nulls,
> presumably the next size up would have to be used (unless the input
> data is first scanned to determine its range; is this worthwhile?)

Data are unsigned, but no nulls.

>

As a matter of fact, I solved the problem by  i) integrating the data in =
site ascii layers,
ii) running spline interpolation to get raster layer.
The work is made automaticaly with a script

Sincerely

Francois DELCLAUX
------------------------------------------------------------
UMR HydroSciences Montpellier
BP 5045    34032 Montpellier Cedex           FRANCE
http://www.mpl.ird.fr/hydrologie/mevhysa
mailto: delclaux@msem.univ-montp2.fr
Tel : (33) (0)4 67 14 90 11      Fax : (33) (0)4 67 14 47 74
------------------------------------------------------------


Wed, Feb 27 2002 05:13:28    Status changed to resolved by egmiller  
Wed, Feb 27 2002 05:13:28    Comments added by egmiller  
16-bit unsigned data must be treated a ints, as GRASS has no internal unsigned
type, and therefore might get overflow.
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request