| Re: reading dem [message #21595 is a reply to message #21573] |
Fri, 01 September 2000 03:28  |
Sylvain Carette
Messages: 19
Registered: May 2000
|
Junior Member |
|
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Well it didnt work.. :-(</tt>
<br><tt>I got:</tt>
<br><tt>% Input line is too long for input buffer of 32767 characters.</tt>
<br><tt>% READF: Error encountered reading from file. Unit: 100, File:
D:\gis\DEM250\montrealw.dem</tt><tt></tt>
<p><tt>Now I'm stuck... is there a way to make readf read only no more
than 32767 char?</tt>
<br><tt>I though to split the file in little chunks but if I do that I
cant use anymore readf since it need a lun if I understand correctly. This
bring me back to my first post in which I divide one record b into 8 1024
chunks and use "reads, string(chunk), var".</tt>
<br><tt>On the command line, each line ok. In the loop:</tt>
<br><tt>% READS: End of input data encountered: <STRING
(' 366 366 359 ...')></tt>
<br><tt>Either too many or not enough.... :-(</tt><tt></tt>
<p><tt>I noticed that you used long instead of int, what is the reason
for this?</tt>
<br><tt>Wait a minute: do I have more chance if I use assoc subdividing
the file in 1024 byte arrays before calling readf? Do assoc effectively
will make readf read only 1024 byte chunk at a time without complain?(I'll
try anyway but comment welcome)</tt>
<br><tt>And about the file pointer, once you place it what happen after?
I mean, do you have any control over it or it just drive crazy by itself
up to EOF?</tt>
<br><tt>I begin to have a fuzzy feel that I begin to understand.. or its
because its already 6am and I need to sleep</tt><tt></tt>
<p><tt>Sylvain Carette</tt>
<br><tt>VRML designer-composer</tt><tt></tt>
<p><tt>Craig Markwardt wrote:</tt>
<blockquote TYPE=CITE><tt>Sylvain,</tt><tt></tt>
<p><tt>Part of the problem is that very few people have any direct experience</tt>
<br><tt>with what you are trying. Some, including me, offered some
general</tt>
<br><tt>advice, hoping that would help, but reading byte-level DEM's is
not</tt>
<br><tt>exactly common knowledge. Also realize that a topic so focussed
and</tt>
<br><tt>specific as yours is not likely to pique anybody's interst.
In the</tt>
<br><tt>future you would do better to describe what you need to do at a
higher</tt>
<br><tt>level, and help us by providing documentation, like I do now.</tt><tt></tt>
<p><tt>The documentation is here:</tt>
<br><tt><a href="http://rockyweb.cr.usgs.gov/nmpstds/demstds.html">http://rockyweb.cr.usgs.gov/nmpstds/demstds.html</a></tt><tt></tt>
<p><tt>The DEM's are digital elevation maps, and are stored in 1024 byte</tt>
<br><tt>blocks. The first block contains a type "A" record.
The next blocks</tt>
<br><tt>contain a type "B" record which have the actual elevation data.
The</tt>
<br><tt>actual data start at offset 144 of the record (where offset 0 is
the</tt>
<br><tt>beginning); there are 1201x1201 elements stored, 146 in the first</tt>
<br><tt>1024-block, and then 170 in the successive 1024-blocks. Elevation</tt>
<br><tt>values are stored as ASCII format=(I6).</tt><tt></tt>
<p><tt>The key thing to realize that all the data is in ASCII, separated
by</tt>
<br><tt>blanks. Therefore, while we could read each 1024-block in
turn, it's</tt>
<br><tt>better to just do a formatted READF. There is no need to
work at the</tt>
<br><tt>byte level, except at the beginning to get to the right file offset.</tt>
<br><tt>Unfortunately IDL can only read 32k elements at a time, so I read
a</tt>
<br><tt>row at a time as a compromise.</tt><tt></tt>
<p><tt>pro readdem250, file, im</tt>
<br><tt> m = 1201L & n = 1201L ;; Really get this from Type A,
element 16</tt>
<br><tt> im = lonarr(m, n) ;; Formally defined
as INTEGER*4</tt><tt></tt>
<p><tt> openr, lun, file, /get_lun</tt>
<br><tt> ;; Skip past type A record and 144 bytes of Type B record</tt>
<br><tt> point_lun, lun, 1024L + 144L</tt><tt></tt>
<p><tt> ;; Read data, one row at a time</tt>
<br><tt> row = im(*,0)</tt>
<br><tt> for i = 0, 1200 do begin</tt>
<br><tt> readf, lun, row, format='(1201(I6))'</tt>
<br><tt> im(*,i) = row</tt>
<br><tt> endfor</tt>
<br><tt> free_lun, lun</tt>
<br><tt>end</tt><tt></tt>
<p><tt>Of course I haven't tested this, but you can use this as a starting</tt>
<br><tt>point.</tt><tt></tt>
<p><tt>Craig</tt><tt></tt>
<p><tt>P.S. If you are still interested in the block structure, then
you</tt>
<br><tt>would read the blocks like this:</tt><tt></tt>
<p><tt>bb = bytarr(1024)*nblocks</tt>
<br><tt>readu, lun, bb</tt><tt></tt>
<p><tt>This avoids some extraneous STRING calls.</tt><tt></tt>
<p><tt>--</tt>
<br><tt> ------------------------------------------------------------ -------------- </tt>
<br><tt>Craig B. Markwardt, Ph.D. & nbsp;
EMAIL: craigmnet@cow.physics.wisc.edu</tt>
<br><tt>Astrophysics, IDL, Finance, Derivatives | Remove "net" for better
response</tt>
<br><tt> ------------------------------------------------------------ -------------- </tt></blockquote>
<tt></tt></html>
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
