| BYTES to LONG [message #22341] |
Tue, 07 November 2000 00:00  |
Kelly Dean
Messages: 92
Registered: March 1997
|
Member |
|
|
I am reading in a combination ASCII/BINARY file with USGS DLG
information as a binary file.
I am able to convert the bytes into ASCII with STRING([72B, 101B, 108B,
108B, 111B]).
However, I cannot figure out how to convert the 4 bytes into LONG, whihc
is the UTM X and Y numbers. Any suggestions?
Kelly
|
|
|
|
| Re: BYTES to LONG [message #22412 is a reply to message #22341] |
Thu, 09 November 2000 00:00  |
Kelly Dean
Messages: 92
Registered: March 1997
|
Member |
|
|
I'll try your suggest. However, so far, floats produced by TOTAL hasn't been
a problem yet with the handful of sample files I have worked on.
Your right, there is a ENDIAN issue. Especially on the Windows 2000 machine I
am currently working on. I solved this by using IDL's OPENR keyword -
SWAP_ENDIAN.
Thanks for the tip,
Kelly
Craig Markwardt wrote:
> Kelly Dean <krdean@lamar.colostate.edu> writes:
>
>> Thanks Paul,
>>
>> Your suggestion solved my problem.
>>
>> long_x = TOTAL( ISHFT( LONG(x), [24,16,8,0] ) )
>
> Hi Kelly--
>
> While this may seem to work, I agree with JD that this is a bit
> dangerous since it converts to floating point. The expression
>
> long_x = long(x, 0, 1)
>
> should produce the same, and correct, result, without invoking any
> floating point conversions. However you may have to worry about
> so-called "endian" issues, that is byte ordering differences between
> machines. A routine in the IDL Astronomy Library like IEEE_TO_HOST
> should be able to help you there.
>
> Craig
>
> --
> ------------------------------------------------------------ --------------
> Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
> Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
> ------------------------------------------------------------ --------------
|
|
|
|
| Re: BYTES to LONG [message #22413 is a reply to message #22341] |
Thu, 09 November 2000 00:00 |
Kelly Dean
Messages: 92
Registered: March 1997
|
Member |
|
|
My original idea for reading the USGS DLG files in the SDTS format was very similar to Med
Bennett suggestion and it does work.
OPENR, ReadU, POINT_LUN, then ReadU them in as LONG
However, from my (FORTRAN) experience, looping thru an I/O is a slow process.
I thought, if I read the SDTS file as one binary array with one ReadU statement to limit the
I/O operation, then loop thru it later would speed the process up - which it doesn't. I still
need to use the FOR...ENDFOR which is slow in IDL anyway.
However for some reason, in the USGS conversion process of these SDTS files, they are
sticking LF (13B) in the data and they are randomly located throughout the file. Or these LF
maybe in some original master file and they leave them in there by mistake. Something I plan
to send an E-Mail to USGS about.
Anyway, by removing the 13B from the data, I get correct UTM numbers. This is easier, if I
read in the file as a binary array and use the WHERE function to remove the 13B before I
start looping thru it. Reading in the LONG value with ReadU as I originally done ( and Med
suggested ), picked up these LFs producing bad UTM numbers.
The reason why I took on this task -- CIRA managers are questioning our GIS compatibility
with other agencies. I just wanted to prove to them that we don't need to purchase new
hardware and GIS programs to solve this problem. It can be all done in IDL ( ENVI and River
Tools not required either ).
The USGS SDTS files with DEM and DLG are ugly, but free. USGS conversion process is still
underway, so not all DEMs and DLGs are available yet in the new Internet friendly (
programmers nightmare ) SDTS format.
I plan to post my simple SDTS read routine soon.
Kelly
Paul van Delst wrote:
> Kelly Dean wrote:
>>
>> Thanks Paul,
>>
>> Your suggestion solved my problem.
>>
>> long_x = TOTAL( ISHFT( LONG(x), [24,16,8,0] ) )
>>
>> It converted the 4 Bytes into a LONG UTM number.
>
> Wow. I posted a useful solution...excuse me while I get up from the floor! :o)
>
> I have to admit, I treated your question as a little IDL exercise rather than think a bit
> harder and ask a few more questions to help you solve your problem. If, as Med Bennett
> suggested, you can read the data in as a LONG, isn't that a better method? Or didn't that
> work for you? I have no idea what the format of a USGS SDTS file is so it may be a
> braindead question.
>
> paulv
>
> --
> Paul van Delst Ph: (301) 763-8000 x7274
> CIMSS @ NOAA/NCEP Fax: (301) 763-8545
> Rm.207, 5200 Auth Rd. Email: pvandelst@ncep.noaa.gov
> Camp Springs MD 20746
|
|
|
|
| Re: BYTES to LONG [message #22419 is a reply to message #22341] |
Wed, 08 November 2000 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Kelly Dean <krdean@lamar.colostate.edu> writes:
> Thanks Paul,
>
> Your suggestion solved my problem.
>
> long_x = TOTAL( ISHFT( LONG(x), [24,16,8,0] ) )
Hi Kelly--
While this may seem to work, I agree with JD that this is a bit
dangerous since it converts to floating point. The expression
long_x = long(x, 0, 1)
should produce the same, and correct, result, without invoking any
floating point conversions. However you may have to worry about
so-called "endian" issues, that is byte ordering differences between
machines. A routine in the IDL Astronomy Library like IEEE_TO_HOST
should be able to help you there.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
