Hi, grass comunity.
I've manage to get a program to convert the GTOPO30 maps to grass raster
ascii format and import them in grass (for version 4.0- I don't know if
it works with any other...) but it's kind of slow (only one of the many
files that comprises it took 3 hours on a Pentium II - 233 MHz...). I
need to know something that any low-level programmer knows (not me...).
What's the faster algorithm to exchange from Most Significant Byte first
(MBR) of Motorola's processors to the PC format of saving binary
numbers. We're talking of 57 Mb of 16-bit integer...
Thanks for any hand
----------------- // --------------
Luís Filipe Franco
Computers, Maths and Music-> Mankind greatest work (in any order)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Luis Franco wrote:
Hi, grass comunity.
I've manage to get a program to convert the GTOPO30 maps to grass raster
ascii format and import them in grass (for version 4.0- I don't know if
it works with any other...) but it's kind of slow (only one of the many
files that comprises it took 3 hours on a Pentium II - 233 MHz...). I
need to know something that any low-level programmer knows (not me...).
What's the faster algorithm to exchange from Most Significant Byte first
(MBR) of Motorola's processors to the PC format of saving binary
numbers. We're talking of 57 Mb of 16-bit integer...
If the contents is *only* 16-bits integer (not mixed with
strings, 32-bits ints, etc...) use dd with option conv=swab :
"dd if=<MBR_file> of=<Intel_bin_file> conv=swab"
You may also use dd as a filter.
BTW, I doubt that the binary conversion is slow, but I know that
binary/ascii conversion is slow : why don't you write directly
a grass binary raster file ? you have just to swap bytes in the
original raster (result in cell directory) and create an ascii
header (in cellhd directory). r.support let you create other
files automaticaly and choosing a color rendition...
Direct binary conversion took me only a few minuts on a 486DX33
(file was not GTOPO30, but a 22 Mb 16-bits compressed raster ...)
--
Michel Wurtz ENGEES - Laboratoire Territoires & Environnement
1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
Tel: +33 03.88.25.34.62 Fax: +33 03.88.37.04.97
With 16-bit integers, you could use the bit-shift operators in C to
extract the two bytes separately, then add them together.
All you would need to do is an 8-bit shift left and an 8-bit shift right,
then sum the results.
If you need a function example, drop me a note.
Angus Carr.
On Sat, 13 Jun 1998, Luis Franco wrote:
Hi, grass comunity.
I've manage to get a program to convert the GTOPO30 maps to grass raster
ascii format and import them in grass (for version 4.0- I don't know if
it works with any other...) but it's kind of slow (only one of the many
files that comprises it took 3 hours on a Pentium II - 233 MHz...). I
need to know something that any low-level programmer knows (not me...).
What's the faster algorithm to exchange from Most Significant Byte first
(MBR) of Motorola's processors to the PC format of saving binary
numbers. We're talking of 57 Mb of 16-bit integer...
Thanks for any hand
----------------- // --------------
Luís Filipe Franco
Computers, Maths and Music-> Mankind greatest work (in any order)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Luis Franco wrote (many days ago):
I've manage to get a program to convert the GTOPO30 maps to grass raster
ascii format and import them in grass (for version 4.0- I don't know if
it works with any other...) but it's kind of slow (only one of the many
files that comprises it took 3 hours on a Pentium II - 233 MHz...). I
need to know something that any low-level programmer knows (not me...).
What's the faster algorithm to exchange from Most Significant Byte first
(MBR) of Motorola's processors to the PC format of saving binary
numbers. We're talking of 57 Mb of 16-bit integer...
I know 2 ways of importing GTOPO30 (and GLCC) maps:
-------------------------------------------------------------------------
1) use the standard module "r.in.ll" to import in a UTM region
-------------------------------------------------------------------------
Ex:
r.in.ll -s input=E020N90.DEM output=gtopo30 bpc=2
corner=sw,40:00:15N,20:00:15E dimension=6000,4800 res=30,30
spheroid=wgs84
-------------------------------------------------------------------------
2) use "r.in.bin", a module I wrote, which is similar to r.in.ascii,
to import in a (x,y) region.
-------------------------------------------------------------------------
Ex:
r.in.bin -s input=E020N90.DEM output=gtopo30 bytes=2 north=90 south=40
east=60 west=20 r=6000 c=4800
(you can add "subst=-9999,0" if you want sea level to have 0 value)
These 2 modules exist in GRASS4.2.1 V17 from Markus Neteler, but:
* r.in.ll doesn't handle negative cell values properly (I corrected
that)
* I have upgraded r.in.bin.
Until they are updated by Markus Neteler in his distribution,
I can mail the 2 new Intel-binaries to anyone who needs them.
Jacques
...
importing a GTOPO30 map (57 Mb) takes:
- 8'30" with r.in.ll
- 2'30" with r.in.bin
on my Linux box (Pentium 120MHz with 32Mb of RAM).
Jacques
Hi Jacques, hi all,
I have to import gtopo30 to my GRASS, but unfortunatly my region falls
into two tiles of USGS data and the resolution differs:
g.region:
CURRENT REGION: N=60S S=80S RES=0:06 ROWS=200
E=45E W=45W RES=0:20 COLS=270
PROJECTION: 3 (Latitude-Longitude)
ZONE: 0
Could your r.in.bin be a solution? If so: I am using an IRIX system,
so I would have to compile it, or does anybody have the SGI/IRIX binary
and is willing to send it to me.
If not:
Does anybody now a better solution than
- converting gtopo to lat lon height (treating the elevation as sites)
- piping it to s.surf.idw
- waiting and waiting and waiting and drinking coffee ... ?
Regards,
Stephan
--
------------------------------------------------------------------------
Stephan Eickschen Tel. : +49 (0)251 83-34704
Westfaelische Wilhelms-Universitaet Fax. : +49 (0)251 83-36100
Institute for Geophysics
Research Unit of Physical Glaciology email: eicksch@uni-muenster.de
Corrensstrasse 24
48149 Muenster
Germany
------------------------------------------------------------------------
Stephan Eickschen wrote:
Hi Jacques, hi all,
I have to import gtopo30 to my GRASS, but unfortunatly my region falls
into two tiles of USGS data and the resolution differs:
Are these points really an issue? You can extend a UTM zone by up to 10km (or
thereabouts) and different resolutions is a common problem which GRASS handles
quite well, provided that you are prepared to work at the lower (more coarse) of
the two.
--
Terry Duell
Terry,
Are these points really an issue? You can extend a UTM zone by up to 10km (or
thereabouts) and different resolutions is a common problem which GRASS handles
quite well, provided that you are prepared to work at the lower (more coarse) of
the two.
I am sorry that I am soooo stupid 
(Can you imagine all the trouble you have if you have no one to ask
but the mailing list ? BTW I am working with lat lon and not UTM, if
it matters ?!?)
Cheers,
Stephan
--
------------------------------------------------------------------------
Stephan Eickschen Tel. : +49 (0)251 83-34704
Westfaelische Wilhelms-Universitaet Fax. : +49 (0)251 83-36100
Institute for Geophysics
Research Unit of Physical Glaciology email: eicksch@uni-muenster.de
Corrensstrasse 24
48149 Muenster
Germany
------------------------------------------------------------------------
Hi Stephan,
I have to import gtopo30 to my GRASS, but unfortunatly my region falls
into two tiles of USGS data and the resolution differs:
g.region:
CURRENT REGION: N=60S S=80S RES=0:06 ROWS=200
E=45E W=45W RES=0:20 COLS=270
PROJECTION: 3 (Latitude-Longitude)
ZONE: 0
Could your r.in.bin be a solution? If so: I am using an IRIX system,
so I would have to compile it, or does anybody have the SGI/IRIX binary
and is willing to send it to me.
Yes r.in.bin is a solution. Here is how you can do:
r.in.bin input=W060S60/W060S60.DEM output=w060s60 north=-60 south=-90
east=0 west=-60 r=3600 c=7200 subst=-9999,0 bytes=2 -s
r.in.bin input=W000S60/W000S60.DEM output=w000s60 north=-60 south=-90
east=60 west=0 r=3600 c=7200 subst=-9999,0 bytes=2 -s
r.mapcalc elevation.dem=w060s60+w000s60
g.remove rast=w060s60,w000s60
You will need some space for the temporary raster maps,
but the final raster map will be quite small:
-rw-r--r-- 1 root root 52757 Jul 27 11:17 elevation.dem
-rw-r--r-- 1 root root 15082536 Jul 27 11:17 w000s60
-rw-r--r-- 1 root root 10727262 Jul 27 11:15 w060s60
The r.in.bin binary I have attached is for SGI IRIX 6.2.
Bye
Jacques
(attachments)
r.in.bin.gz (41.2 KB)