[GRASS5] STDS(DEM)2ASC and Possible Bug

GRASS GRASS developer
1

Attached which will convert STDS DEM files to a format suitable for
reading with r.in.ascii. It is a modified version of STDS2ARC based on the
information presented at
http://www.baylor.edu/~grass/faq/importing_usgs_7_5min.html. It used the
Grass 5 "null:" field to set the null value.

Also, I think I found a bug 5.0beta10: When I import the file GRASS
draws two random dots in the upper left corner of the grid file being
imported. In particular when I converted and imported the Savage, MD grid
I got a dot of value 0 in the corner and a dot of value 107 on the
left edge a little farther down. Those values are not in the grid file.

I suggest you update the above mentioned page to use my utility instead and
also change the title to "USGS 7.5min STDS DEM data" as I originally
overlooked it when trying to figure out how to make use of the STDS DEM
files as it only said "USGS 7.5min DEM data".

I do not plan to farther enhance this utility other then to fix obvious
bugs as I am have a gazillion other projects which are higher on priority
list. I also have no plans on becoming a grass developer.

I am not subscribed to the list so please CC me.

Thanks.

---
Kevin Atkinson
kevina at users sourceforge net
http://metalab.unc.edu/kevina/

(attachments)

sdts2asc (60.5 KB)

2

On Tue, Jan 16, 2001 at 11:08:51PM -0500, Kevin Atkinson wrote:

Attached which will convert STDS DEM files to a format suitable for
reading with r.in.ascii. It is a modified version of STDS2ARC based on the
information presented at
http://www.baylor.edu/~grass/faq/importing_usgs_7_5min.html. It used the
Grass 5 "null:" field to set the null value.

Also, I think I found a bug 5.0beta10: When I import the file GRASS
draws two random dots in the upper left corner of the grid file being
imported. In particular when I converted and imported the Savage, MD grid
I got a dot of value 0 in the corner and a dot of value 107 on the
left edge a little farther down. Those values are not in the grid file.

I suggest you update the above mentioned page to use my utility instead and
also change the title to "USGS 7.5min STDS DEM data" as I originally
overlooked it when trying to figure out how to make use of the STDS DEM
files as it only said "USGS 7.5min DEM data".

I do not plan to farther enhance this utility other then to fix obvious
bugs as I am have a gazillion other projects which are higher on priority
list. I also have no plans on becoming a grass developer.

I am not subscribed to the list so please CC me.

Sourcecode? A single executable is not generally useful.

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

Kevin Atkinson wrote:

Attached which will convert STDS DEM files to a format suitable for
reading with r.in.ascii. It is a modified version of STDS2ARC based on the
information presented at
http://www.baylor.edu/~grass/faq/importing_usgs_7_5min.html. It used the
Grass 5 "null:" field to set the null value.

Also, I think I found a bug 5.0beta10: When I import the file GRASS
draws two random dots in the upper left corner of the grid file being
imported. In particular when I converted and imported the Savage, MD grid
I got a dot of value 0 in the corner and a dot of value 107 on the
left edge a little farther down. Those values are not in the grid file.

I suggest you update the above mentioned page to use my utility instead and
also change the title to "USGS 7.5min STDS DEM data" as I originally
overlooked it when trying to figure out how to make use of the STDS DEM
files as it only said "USGS 7.5min DEM data".

I do not plan to farther enhance this utility other then to fix obvious
bugs as I am have a gazillion other projects which are higher on priority
list. I also have no plans on becoming a grass developer.

Kevin,

For what it's worth, r.in.gdal will read SDTS DEM files directly to GRASS
raster if GDAL is setup properly. I just downloaded the binary distribution,
ensured I had a /usr/local/lib/libgdal.1.1.so installed, and it worked fine.

Markus - I would like to include libgdal.1.1.so in the pre-built
distributions, at least the Linux one. When are you thinking of doing
a beta 11 or final 5.0 release? To make this work smoothly I would like
to have the libgdal.1.1.so just distributed in the grass5 tree, perhaps
/usr/local/grass5/lib, and to slightly update r.in.gdal to look there
as well as the usual locations.

Best regards,
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Wed, 17 Jan 2001, Frank Warmerdam wrote:

Kevin Atkinson wrote:
>
> Attached which will convert STDS DEM files to a format suitable for
> reading with r.in.ascii. It is a modified version of STDS2ARC based on the
> information presented at
> http://www.baylor.edu/~grass/faq/importing_usgs_7_5min.html. It used the
> Grass 5 "null:" field to set the null value.
>
> Also, I think I found a bug 5.0beta10: When I import the file GRASS
> draws two random dots in the upper left corner of the grid file being
> imported. In particular when I converted and imported the Savage, MD grid
> I got a dot of value 0 in the corner and a dot of value 107 on the
> left edge a little farther down. Those values are not in the grid file.
>
> I suggest you update the above mentioned page to use my utility instead and
> also change the title to "USGS 7.5min STDS DEM data" as I originally
> overlooked it when trying to figure out how to make use of the STDS DEM
> files as it only said "USGS 7.5min DEM data".
>
> I do not plan to farther enhance this utility other then to fix obvious
> bugs as I am have a gazillion other projects which are higher on priority
> list. I also have no plans on becoming a grass developer.

Kevin,

For what it's worth, r.in.gdal will read SDTS DEM files directly to GRASS
raster if GDAL is setup properly. I just downloaded the binary distribution,
ensured I had a /usr/local/lib/libgdal.1.1.so installed, and it worked fine.

Thanks for the info. I did not release this. Perhaps you can make it
more obvious by putting a note in the FAQ about importing formats with
GDAL and/or dummy modules such as r.in.gdal.stds, etc to make it more
about to someone browsing the manual pages. The USGS 7.5min DEM data
should REALLY be rewritten, at very least it should include a note in the
beginning saying "NOTE: GDAL will import STDS DEM directly. See r.in.gdal
for more info. Somewhere near the beginning."

If I new this I would have download GDAL and saved my self a decent deal
of time.

---
Kevin Atkinson
kevina at users sourceforge net
http://metalab.unc.edu/kevina/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

On Tue, 16 Jan 2001, Eric G . Miller wrote:

Sourcecode? A single executable is not generally useful.

OOPS: That was suppose to be the sourcecode, Sorry. :-|.

---
Kevin Atkinson
kevina at users sourceforge net
http://metalab.unc.edu/kevina/

(attachments)

sdts2asc.c (31.5 KB)

6

On Wed, Jan 17, 2001 at 12:08:59AM -0500, Frank Warmerdam wrote:

For what it's worth, r.in.gdal will read SDTS DEM files directly to GRASS
raster if GDAL is setup properly. I just downloaded the binary distribution,
ensured I had a /usr/local/lib/libgdal.1.1.so installed, and it worked fine.

Markus - I would like to include libgdal.1.1.so in the pre-built
distributions, at least the Linux one. When are you thinking of doing
a beta 11 or final 5.0 release? To make this work smoothly I would like
to have the libgdal.1.1.so just distributed in the grass5 tree, perhaps
/usr/local/grass5/lib, and to slightly update r.in.gdal to look there
as well as the usual locations.

1. I vote we just publish a final GRASS 5.0 real soon. We'll just be
upfront about outstanding bugs (Note: we *really* need to turn off that
LZW code then... seems most the other license/patent issues have been
moved out of main src/compile tree).

2. Re: r.in.gdal. libgdal has several dependencies above what GRASS
already relies on. I think it would be a good inclusion, but I think we
might have difficuly meeting all the dependency requirements. I found
it less than trivial to get libgeotiff compiled, for instance, since it
wanted to live in a certain place with respect to libtiff sources and
requires private headers. I don't think it's [libgeotiff] ubiquitous
enough to be able to rely on it (though it certainly is desirable).
Perhaps there's some minimal set of requirements that would still
preserve it's [r.in.gdal] utility?

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

On Tue, Jan 16, 2001 at 09:45:35PM -0800, Eric G . Miller wrote:

On Wed, Jan 17, 2001 at 12:08:59AM -0500, Frank Warmerdam wrote:
> For what it's worth, r.in.gdal will read SDTS DEM files directly to GRASS
> raster if GDAL is setup properly. I just downloaded the binary distribution,
> ensured I had a /usr/local/lib/libgdal.1.1.so installed, and it worked fine.
>
> Markus - I would like to include libgdal.1.1.so in the pre-built
> distributions, at least the Linux one. When are you thinking of doing
> a beta 11 or final 5.0 release? To make this work smoothly I would like
> to have the libgdal.1.1.so just distributed in the grass5 tree, perhaps
> /usr/local/grass5/lib, and to slightly update r.in.gdal to look there
> as well as the usual locations.

[another mail...]

2. Re: r.in.gdal. libgdal has several dependencies above what GRASS
already relies on. I think it would be a good inclusion, but I think we
might have difficuly meeting all the dependency requirements. I found
it less than trivial to get libgeotiff compiled, for instance, since it
wanted to live in a certain place with respect to libtiff sources and
requires private headers. I don't think it's [libgeotiff] ubiquitous
enough to be able to rely on it (though it certainly is desirable).
Perhaps there's some minimal set of requirements that would still
preserve it's [r.in.gdal] utility?

Frank,

I would be glad if GDAL is included as it reduces the extra work
for the users. For GRASS 5.1 I proposed a "plugin" directory (maybe
only for the binaries) to place extra libs there.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

Hi all,

again days are passing by... We have to act now!

On Tue, Jan 16, 2001 at 09:45:35PM -0800, Eric G . Miller wrote:
[...]

1. I vote we just publish a final GRASS 5.0 real soon. We'll just be
upfront about outstanding bugs (Note: we *really* need to turn off that
LZW code then... seems most the other license/patent issues have been
moved out of main src/compile tree).

GRASS 5.0 final:
- do we want a beta11 release?
   -> Maybe yes, as we want to know
        o if the graphical login is really stable now
        o the updated Makefile works properly on any machine (I think yes)
        o test the LZW-removal

- generally we need to agree about "what's final". As several bugs are
   still open, we have to consider if we can live with that and/or
   eventually comment buggy modules from the default compile list.
  
- If we don't push the final release, we'll never get it out.

- Personal minimum requirement for 5.0 stable is
    - working import/export modules (at least for the common formats)
    - configure stable
    - ?
    The current CVS version nearly fulfils it.

GRASS 5.1:
- obviously there is no final agreement yet about the directory structure.
   Andreas pointed out that this directory structure might not be that
   important.
- Question is
    - if we need to split into core and topic oriented packages
    - if we could split into core and topic oriented packages *without*
      splitting the source code

Generally I think we should keep the sources directory structure as simple
as possible. Something like
    /include
    /lib
    /display
    /raster
    ...
So it differs slightly from my last proposal :slight_smile:

Cheers

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

On Wed, Jan 17, 2001 at 09:49:20AM +0000, Markus Neteler wrote:

GRASS 5.0 final:
- do we want a beta11 release?
   -> Maybe yes, as we want to know
        o if the graphical login is really stable now
        o the updated Makefile works properly on any machine (I think yes)
        o test the LZW-removal

I vote for a beta11 as soon as possible.
It will be definitely better than beta10
and will generate reports on serious problems.

As soon as we see there are not major issues,
we should agree on what to do until 5.0.

- generally we need to agree about "what's final". As several bugs are
   still open, we have to consider if we can live with that and/or
   eventually comment buggy modules from the default compile list.

drop buggy modules where no one says he/she will fix it within 4 weeks.
(I am not sure whether 4 is the time table you think of, just a proposal :slight_smile:

- If we don't push the final release, we'll never get it out.

right.

  Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

"Eric G . Miller" wrote:

2. Re: r.in.gdal. libgdal has several dependencies above what GRASS
already relies on. I think it would be a good inclusion, but I think we
might have difficuly meeting all the dependency requirements. I found
it less than trivial to get libgeotiff compiled, for instance, since it
wanted to live in a certain place with respect to libtiff sources and
requires private headers. I don't think it's [libgeotiff] ubiquitous
enough to be able to rely on it (though it certainly is desirable).
Perhaps there's some minimal set of requirements that would still
preserve it's [r.in.gdal] utility?

Eric,

There are various ways to build libgdal. In this case I think I would build
it with pretty much all the dependencies, including libgeotiff, libpng,
libjpeg, libtiff and so forth "built in". While this doesn't factor well
in general, it should be fine when it is only being used by r.in.gdal.

I will update r.in.gdal today to search the $GISBASE/lib directory for the
gdal shared library, and prepare a "fully built-in" libgdal.1.1.so suitable
for distribution with GRASS. If there is sufficient interest I could do the
same for Solaris and IRIX.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

Hi Frank

Frank Warmerdam wrote:

If there is sufficient interest I could do the
same for Solaris and IRIX.

I would really appreciate it if you could do this for IRIX.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

Jan-Oliver Wagner wrote:

I vote for a beta11 as soon as possible.
It will be definitely better than beta10
and will generate reports on serious problems.

Agreed.

drop buggy modules where no one says he/she will fix it within 4
weeks.

I think this would be a good idea. However, are there any well used
modules that are broken? If so, then we should at least fix those.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

13

On Thu, Jan 18, 2001 at 11:03:10AM +0700, Justin Hickey wrote:

Jan-Oliver Wagner wrote:
> I vote for a beta11 as soon as possible.
> It will be definitely better than beta10
> and will generate reports on serious problems.

Agreed.

> drop buggy modules where no one says he/she will fix it within 4
> weeks.

I think this would be a good idea. However, are there any well used
modules that are broken? If so, then we should at least fix those.

Yes,

o the r.*.tiff is still causing some problems. Eric Miller
  already spend much time on this pretty confusing piece of code,
  however there are still problems.

  r.in.tiff: segfault on Linux (was working once)
  r.out.tiff: minor bug on extensions if -t is used (segfaults when
            writing the .tfw file on Linux

  This is in my opinion such an important module.

o CELL driver: obviously some problems with colors (no 24bit)

o r.in.png: unstable, no 24bit yet

o v.out.e00: Doesn't output any information about projection, datum, etc.

The import/export functionality is one of the most important issues
in a GIS (here: acceptance of GRASS beside other stuff of course).

On BUGS:
- I have decreased the bugs status here:
   - r.contour: no RC (shall we keep it?)
   - r.cost: here is is working well
   - r.null: I have added the comment to html/html/r.null.html
             and removed in BUGS.

Recent new bug: GRASS 5 beta10 startup crash occurs with Linux and csh.

So far,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

14

Hi Markus

Markus Neteler wrote:

Recent new bug: GRASS 5 beta10 startup crash occurs with Linux and
csh.

I thought we fixed this, is it still causing problems? Please send any
output and I'll try to track it down. This is strange, since csh should
perform the same as tcsh which is what I use without problems.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

15

On Fri, Jan 19, 2001 at 06:07:12PM +0700, Justin Hickey wrote:

Hi Markus

Markus Neteler wrote:
> Recent new bug: GRASS 5 beta10 startup crash occurs with Linux and
> csh.

I thought we fixed this, is it still causing problems? Please send any
output and I'll try to track it down. This is strange, since csh should
perform the same as tcsh which is what I use without problems.

Hi Justin,

thanks for your offer. However, that machine runs windows regularly.
I discuss to get it on Linux in the morning time.

On the other hand nobody else reported it. So it might be a local
problem.

Unfortunately there is one left with G3d on CRAY:

CC-147 cc: ERROR File = tilewrite.c, Line = 344
  Declaration is incompatible with
          "int G3d_putFloat(G3D_Map *, int, int, int, float)" (declared at
          line 499 of
"/home/t3e/fsn/nhdc/nhdcmark/grass/src/include/G3d.h").

  G3d_putFloat (map, x, y, z, value)
  ^

1 error detected in the compilation of "tilewrite.c".

I don't have an idea here...

Have a nice weekend

Markus

PS: Hope to get out beta11 today.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

16

Hi Markus

Markus Neteler wrote:

Unfortunately there is one left with G3d on CRAY:

CC-147 cc: ERROR File = tilewrite.c, Line = 344
  Declaration is incompatible with
          "int G3d_putFloat(G3D_Map *, int, int, int, float)" (declared at
          line 499 of
"/home/t3e/fsn/nhdc/nhdcmark/grass/src/include/G3d.h").

  G3d_putFloat (map, x, y, z, value)
  ^

Strange. Try changeing the declaration in tilewrite.c to the same as the
include file. That is change

int
G3d_putFloat (map, x, y, z, value)

     G3D_Map *map;
     int x, y, z;
     float value;

to the following

int G3d_putFloat(G3D_Map *map, int x, int y, int z, float value)

in tilewrite.c. Maybe the extra spacing is confused or something. Gotta
go now.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

17

Hi Justin,

got it! Now src/libes/g3d/ compiles well on CRAY (Linux, ...).

On Fri, Jan 19, 2001 at 06:27:45PM +0700, Justin Hickey wrote:

Hi Markus

Markus Neteler wrote:
> Unfortunately there is one left with G3d on CRAY:
>
> CC-147 cc: ERROR File = tilewrite.c, Line = 344
> Declaration is incompatible with
> "int G3d_putFloat(G3D_Map *, int, int, int, float)" (declared at
> line 499 of
> "/home/t3e/fsn/nhdc/nhdcmark/grass/src/include/G3d.h").
>
> G3d_putFloat (map, x, y, z, value)
> ^
>

Strange. Try changeing the declaration in tilewrite.c to the same as the
include file. That is change

int
G3d_putFloat (map, x, y, z, value)

     G3D_Map *map;
     int x, y, z;
     float value;

to the following

int G3d_putFloat(G3D_Map *map, int x, int y, int z, float value)

in tilewrite.c. Maybe the extra spacing is confused or something. Gotta
go now.

That's it. It must be explicitly identical. CRAY cc is somewhat
paranoid.

So far on g3d - another chapter finished :slight_smile:

Yours
Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'