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. |
|