[GRASS-user] MOLA data elevation problem

GRASS GRASS user
1

Hello Grass Users

I have problem with MOLA data, i managed to import MOLA binary file to grass using r.in.bin
but some cells seems to have invalid values (see pictures in attachment).
Anyone know how to solve this problem??? and set correct elevation values.
Thanks in advance
best regards
maciej

Maciej Tomaszczyk
Polish Geological Institute
Geological Mapping Department

(attachments)

MOLA_32.jpg
histogram_mola.jpg

2

Hello Maciej,

It seems that your file contains negative values. They are coded with the values
form 32768 to 65535 with 32765 meaning -32768 and 65535 meaning -1 (you can see
in your histogram that you have values in the low value (0...) which are the
positive values and in the high values (...65535) which are the negative values
(-1...).

I don't have Grass right here but you can check wether or not r.in.bin have a
flag to tell him to use to convert negative value.

The other way would be tu use r.mapcalc with an expression doing the following:
if value<32767 return value ( the positive value kept as is )
else return value-65636 (convert to negative value)

It should be something like (once again, I'm not sure of the syntax and I don't
have access to grass to check):
out=if(value<32767,value,value-65636)

Let me know if it works an,d which solutions use used.

Laurent

Selon Maciej Tomaszczyk <mtom@pgi.gov.pl>:

Hello Grass Users

I have problem with MOLA data, i managed to import MOLA binary file to grass
using r.in.bin
but some cells seems to have invalid values (see pictures in attachment).
Anyone know how to solve this problem??? and set correct elevation values.
Thanks in advance
best regards
maciej

Maciej Tomaszczyk
Polish Geological Institute
Geological Mapping Department

3

Dear Laurent

There is in r.in.bin a -s flag(high bit means negative value) but when i used it, effect was the same.
The r.mapcalc fixed it. Now everything is ok.
Thanks for your advice
best regards
maciej

Maciej Tomaszczyk
Polish Geological Institute
Geological Mapping Department

-----Wiadomość oryginalna-----
Od: laurent.caribou@free.fr [mailto:laurent.caribou@free.fr]
Wysłano: Wt 2007-02-06 14:49
Do: Maciej Tomaszczyk
DW: grassuser@grass.itc.it
Temat: Re: [GRASS-user] MOLA data elevation problem

Hello Maciej,

It seems that your file contains negative values. They are coded with the values
form 32768 to 65535 with 32765 meaning -32768 and 65535 meaning -1 (you can see
in your histogram that you have values in the low value (0…) which are the
positive values and in the high values (…65535) which are the negative values
(-1…).

I don’t have Grass right here but you can check wether or not r.in.bin have a
flag to tell him to use to convert negative value.

The other way would be tu use r.mapcalc with an expression doing the following:
if value<32767 return value ( the positive value kept as is )
else return value-65636 (convert to negative value)

It should be something like (once again, I’m not sure of the syntax and I don’t
have access to grass to check):
out=if(value<32767,value,value-65636)

Let me know if it works an,d which solutions use used.

Laurent

Selon Maciej Tomaszczyk mtom@pgi.gov.pl:

Hello Grass Users

I have problem with MOLA data, i managed to import MOLA binary file to grass
using r.in.bin
but some cells seems to have invalid values (see pictures in attachment).
Anyone know how to solve this problem??? and set correct elevation values.
Thanks in advance
best regards
maciej

Maciej Tomaszczyk
Polish Geological Institute
Geological Mapping Department

4

Maciej Tomaszczyk wrote:

> I have problem with MOLA data, i managed to import MOLA binary file
> to grass using r.in.bin
> but some cells seems to have invalid values (see pictures in
> attachment). Anyone know how to solve this problem??? and set
> correct elevation values. Thanks in advance

Laurent wrote:

It seems that your file contains negative values. They are coded with
the values form 32768 to 65535 with 32765 meaning -32768 and 65535
meaning -1 (you can see in your histogram that you have values in the
low value (0...) which are the positive values and in the high values
(...65535) which are the negative values (-1...).

Maciej wrote:

There is in r.in.bin a -s flag(high bit means negative value) but when
i used it, effect was the same. The r.mapcalc fixed it. Now everything
is ok. Thanks for your advice

Glad it is working. FYI in an article in GRASSNews vol 1 (page 11) I use
this r.in.bin command to load in MOLA data:

GRASS:~ > r.in.bin input=megt90n000fb.img \
    title="MGS/MOLA Gridded Data, 1/32 degree" \
    output=mars_mola_32 -b bytes=2 rows=5760 \
    cols=11520 n=90N s=90S e=180E w=180W

Hamish

5

Maciej Tomaszczyk wrote:

Dear Laurent

There is in r.in.bin a -s flag(high bit means negative value) but when i used it, effect was the same.

That's because (after the manual) "The -s flag is used for importing
signed one byte data (range -128 - 127)."

It would be very useful to have it extended to support 2 and 4 byte data.

Maciek

P.S.

Note that r.in.gdal supports bil format too, via EHdr driver. The bil
raster has to accompanied with an appropriate hdr file. Look into the
r.in.srtm script for an example. If the header file contains a
"PIXELTYPE SIGNEDINT" tag the data will be treated as a signed integer.

6

Maciej Sieczka wrote:

> There is in r.in.bin a -s flag(high bit means negative value) but when i used it, effect was the same.

That's because (after the manual) "The -s flag is used for importing
signed one byte data (range -128 - 127)."

It would be very useful to have it extended to support 2 and 4 byte data.

That should be easy enough; I'll commit the following patch once I've
tested it.

--
Glynn Clements <glynn@gclements.plus.com>

(attachments)

r.in.bin.patch (678 Bytes)