[GRASS-user] problem in exporting grass2idrisi

GRASS GRASS user
,
1

hello

I cannot manage with r.out.gdal for idrisi format:
What am I doing wrong ?

here is what I did.

GRASS 6.3.0RC5 (pro1):~ > gdalinfo --formats | grep -i Idrisi
  RST (rw+): Idrisi Raster A.1
[Raster MASK present]
GRASS 6.3.0RC5 (pro1):~ > r.out.gdal format=RST input=e30a1_DEM
output=e30a1_DEM_id type=Int16
Exporting to GDAL data type: Int16
ERROR 4: `e30a1_DEM_id' not recognised as a supported file format.

ERROR: Unable to create <e30a1_DEM_id> dataset using <RST> driver
[Raster MASK present]

regards
--
Ahmet Temiz
Jeo. Müh.
Afet İşleri Gen. Md.lüğü
Deprem Ar. D.

Ahmet Temiz
Geo. Eng.
General Dir. of
Disaster Affairs

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

2

On Fri, Oct 3, 2008 at 1:11 PM, orkun <temiz@deprem.gov.tr> wrote:

hello

I cannot manage with r.out.gdal for idrisi format:
What am I doing wrong ?

here is what I did.

GRASS 6.3.0RC5 (pro1):~ > gdalinfo --formats | grep -i Idrisi
RST (rw+): Idrisi Raster A.1
[Raster MASK present]
GRASS 6.3.0RC5 (pro1):~ > r.out.gdal format=RST input=e30a1_DEM
output=e30a1_DEM_id type=Int16
Exporting to GDAL data type: Int16
ERROR 4: `e30a1_DEM_id' not recognised as a supported file format.

ERROR: Unable to create <e30a1_DEM_id> dataset using <RST> driver
[Raster MASK present]

I can reproduce the problem.
Using the debugger, it turns out that GDALCreate() fails.

Looking at
http://www.gdal.org/frmt_Idrisi.html
it seems that Int16 is supported:

"This format is basically a raw one. There is just one band per files,
except in the RGB24 data type where the Red, Green and Blue bands are
store interleafed by pixels in the order Blue, Green and Red. The
others data type are unsigned 8 bits integer with values from 0 to 255
or signed 16 bits integer with values from -32.768 to 32.767 or 32
bits single precision floating point.32 bits.
"

Not sure what's going on. Perhaps a GDAL bug? I am using GDAL from trunk.

Testing with GDAL tools:
r.out.gdal geology_30m out=geology_30m.tif type=Int16
Exporting to GDAL data type: Int16
ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF format.
100%
WARNING: Input raster map constains cells with NULL-value (no-data). The
         value -32768 was used to represent no-data values in the input
         map.You can specify nodata value by nodata parameter.
r.out.gdal complete.

gdal_translate -of RST geology_30m.tif geology_30m
Input file size is 1532, 560
0ERROR 4: `geology_30m' not recognised as a supported file format.

I think that this should be reported to GDAL:
http://trac.osgeo.org/gdal/

If you hesitate, I can do it - just let me know.

Possibly I am overlooking something but I think that it should
at least come with a better error message.

Markus

Markus

3

Markus wrote:

Looking at
http://www.gdal.org/frmt_Idrisi.html
it seems that Int16 is supported:

"This format is basically a raw one. There is just one band per files,
except in the RGB24 data type where the Red, Green and Blue bands are
store interleafed by pixels in the order Blue, Green and Red. The
others data type are unsigned 8 bits integer with values from 0 to 255
or signed 16 bits integer with values from -32.768 to 32.767 or 32
bits single precision floating point.32 bits."

Probably not very helpful to the current issue, but I am reminded of this
(old) wish report,
  http://intevation.de/rt/webrt?serial_num=1069

==========================

On Mar 27, 2002, David A Hastings wrote:
> I hope to set up the database so that source (e.g. PERMANENT) data will
> be readable on both GRASS and Idrisi. GRASS and Idrisi 8-bit
> uncompressed cell files are identical, one can use links to headers, so
> that source data are interoperable on both systems. I have been doing
> this since 1995. If GRASS let one specify an actual 2-byte integer, and
> specify the byte ordering (say as enhancements to CELLHD files), as is
> possible in programs such as Photoshop, the interoperability would be
> better. And Idrisi has had floating point cell files since its
> inception - though I won't know about compatibility issues with GRASS 5
> for another few weeks. Finally, if GRASS could let the user force files
> to remain uncompressed (again, a field in the CELLHD file),
> interoperability would be helped at the cost of (now cheap) disk space.

Markus wrote:

If you don't mind, I'll send above to the developers list. Maybe we can
do something.

David wrote:
I'd love to see you make a suggestion. I would do it myself, but I'm
overwhelmed with the move right now. It has been a BIG pain to me that the
history of the Open GRASS Foundation (which became the Open GIS Consortium
when CERL stopped funding OGF for doing things that were inappropriate in
CERL's eyes) causes the Open GIS Consortium to ignore the best starting
platform for open GIS (e.g. GRASS). Nevertheless, GRASS and Idrisi have
existing "de-facto" interoperability at the file level, and are a great
conceptual model for enhancing such interoperability if they could cooperate
on "just a couple of small detials." The complementarity of GRASS and Idrisi
(and perhaps ERDAS, but this might be less likely), and the research aspect
of both GRASS and Idrisi, should be a great motivation to modestly pursue
such interoperability.

> Regards to all,
> David Hastings

===================================
Eric Miller & David then go on to discuss the differences and similarities.

fyi, an interesting read..

Hamish