I am a new subscriber to this list and hence apologise if I am asking a
question that has been recently discussed.
I am experiencing the Linux (RedHat 6.1) segmentation error when running
r.in.tiff and was wondering if there have been any recent "innovations"
with regard this problem? The last reference in the on-line archive was
dated from early december.
Peter Earle
Biology Department
Memorial University
St. John's, NF
Canada
A1B 3X9
On Fri, Mar 10, 2000 at 05:10:53PM -0330, Peter Earle wrote:
I am a new subscriber to this list and hence apologise if I am asking a
question that has been recently discussed.I am experiencing the Linux (RedHat 6.1) segmentation error when running
r.in.tiff and was wondering if there have been any recent "innovations"
with regard this problem? The last reference in the on-line archive was
dated from early december.Peter Earle
Biology Department
Memorial University
St. John's, NF
Canada
A1B 3X9
Perhaps you could convert your image to a sunrast or ppm file using
something like ImageMagick. I think r.in.tiff must be broken, I don't
have it with a CVS build from last week.
--
+----------------------------------------------------+
| Eric G. Miller egm2@jps.net |
| GnuPG public key: http://www.jps.net/egm2/gpg.asc |
+----------------------------------------------------+
> I am experiencing the Linux (RedHat 6.1) segmentation error when running
> r.in.tiff and was wondering if there have been any recent "innovations"
> with regard this problem? The last reference in the on-line archive was
> dated from early december.
Hi all,
good news on raster image import/export:
Alex Shavlakov managed to write
r.in.png
r.out.png
with full 24bit support. These modules are uploaded
to CVS repository (as usual).
To overcome patent restrictions I made the proposal
to develop a new open source GIS raster standard:
"geoPNG"
It should be comparing to geoTIFF and may follow
OpenGIS conventions. We discussed this idea with
few people, perhaps it could be discussed in this
forum, too.
The idea of "geoPNG" is to store
- the raster file itself
- additional projection/koordinate information
for easy file exchange.
As r.in.png/r.out.png are existing now we could
proceed on working on this topic.
Kind regards
Markus Neteler
-----------------------------------------------------------------
Geographisches Institut | Schneiderberg 50
+ Physische Geographie 30167 Hannover, Germany
& Landschaftsoekologie + Tel: ++49-(0)511-762-4494
Universitaet Hannover Fax: ++49-(0)511-762-3984
neteler@geog.uni-hannover.de
-----------------------------------------------------------------
On Sat, Mar 11, 2000 at 10:39:44AM +0000, Markus Neteler wrote:
Hi all,
good news on raster image import/export:
Alex Shavlakov managed to write
r.in.png
r.out.pngwith full 24bit support. These modules are uploaded
to CVS repository (as usual).To overcome patent restrictions I made the proposal
to develop a new open source GIS raster standard:"geoPNG"
It should be comparing to geoTIFF and may follow
OpenGIS conventions. We discussed this idea with
few people, perhaps it could be discussed in this
forum, too.The idea of "geoPNG" is to store
- the raster file itself
- additional projection/koordinate information
for easy file exchange.As r.in.png/r.out.png are existing now we could
proceed on working on this topic.
I think we should consider reimplementing r.in.tiff/r.out.tiff without
support for LZW compression. The geoTIFF format(s) is pretty widely used
and there's no requirement that the images be compressed with LZW
compression. For instance, neither of the ESRI products I use at work
(ARC/INFO, ArcView) support LZW compression without extensions for the
very same patent reason. However, they still support geoTIFFs. I see no
reason why GRASS can't do the same. There's also a geoGIF -- same world
file structure, no LZW, and a geoJPG -- same world file, dubious value
due to Lossy compression scheme.
However, I do think the geoPNG is a great idea as well, so kudos to Alex
Shavlakov for implementing it.
--
+----------------------------------------------------+
| Eric G. Miller egm2@jps.net |
| GnuPG public key: http://www.jps.net/egm2/gpg.asc |
+----------------------------------------------------+
Eric G . Miller wrote:
On Fri, Mar 10, 2000 at 05:10:53PM -0330, Peter Earle wrote:
>
> I am a new subscriber to this list and hence apologise if I am asking a
> question that has been recently discussed.
>
> I am experiencing the Linux (RedHat 6.1) segmentation error when running
> r.in.tiff and was wondering if there have been any recent "innovations"
> with regard this problem? The last reference in the on-line archive was
> dated from early december.
>
> Peter Earle
> Biology Department
> Memorial University
> St. John's, NF
> Canada
> A1B 3X9Perhaps you could convert your image to a sunrast or ppm file using
something like ImageMagick. I think r.in.tiff must be broken, I don't
have it with a CVS build from last week.
Are your tiff files by any chance 8 bit format? I had the same problem
with sigfaults with the 24 bit program but when I compiled
r.in.tiff.c.orig_8bit from the source tree it worked fine reading some
scanned USGS DRG Quadrangles in 8 bit format.
I was using the scanned USGS quad to drape over a DEM file for a 3d
topographical map but when I zoom into the small area I'm interested in
I have a stairstep, terraced look. Would changing the site reolution
have any effect or should I use the r.surf.idw2 module to correct this
or some other method or module? Any suggestions?
Frank R. Clower