| number problem [message #61198] |
Wed, 09 July 2008 03:50  |
d.poreh
Messages: 406
Registered: October 2007
|
Senior Member |
|
|
folks
i have a .TXt file like this:
499750.95298079 3387735.57676302 1259.18847656 34.63407516
499730.95491979 3387755.57503202 1259.18847656 34.66235733
499710.95685879 3387775.57330102 1257.50012207 34.69063950
499690.95879779 3387795.57157002 1255.97583008 34.71892166
and i did some analyze in IDL but result is like this:
499750. 3.38774e+006 1259.00 34.0000
499730. 3.38776e+006 1259.00 34.0000
499710. 3.38778e+006 1257.00 34.0000
499690. 3.38780e+006 1255.00 34.0000
but as you can see the result are not same. i used long-float and
ULL. but no answer.
any help
Cheeres
|
|
|
|
| Re: number problem [message #61227 is a reply to message #61198] |
Thu, 10 July 2008 13:14  |
pgrigis
Messages: 436
Registered: September 2007
|
Senior Member |
|
|
R.G. Stockwell wrote:
> <pgrigis@gmail.com> wrote in message
> news:c8f5bb5a-7b15-4abd-bf13-1587add65abe@j22g2000hsf.google groups.com...
>> R.G. Stockwell wrote:
>>> <d.poreh@gmail.com> wrote in message
>>> news:43fbf367-1b18-473e-a047-3ce39612f806@x35g2000hsb.google groups.com...
>>> .... snipped ...
>>>
>>>> yes that was the problem!!1
>>>> it is works properly.but for lat-lon data as you can see it is not:
>>>> 499690.96 3387795.6
>>>
>>>> i need more details like this
>>>> 499690.95879779 3387795.57157002
>>>
>>> WHOA WHOA WHOA WHOA!!
>>>
>>> While we are being pleasant and thinking about what we are doing,
>>> let's think about what it means when you say you need 8 digits of
>>> lat and lon. (hint, think in millimeters)
>>>
>>>
>>> Granted this is somewhat beside the point of how to read data, but if
>>> anyone
>>> ever reviews a lat or a lon with more than 2 decimal points, they will
>>> flag
>>> it.
>>
>> On the other hand, google maps will pinpoint
>> the location of my office at
>>
>> 42.381009N, 71.128014W
>>
>> whereas that would be a bit off if it only
>> had 2 decimals... ;-)
>>
>> Ciao,
>> Paolo
>
> True, 2 decimals places is about 1km (roughly). But 71.128014W
> implies a precision of about 10 cm. That is smaller than the window.
> Geophysical data - that is large enough to use lat and lon, is quite
> often not taken on a resolution of cms.
>
> Incidentally, three decimal places works just fine.
> 42.381N, 71.128W (100 m resolution)
Yes, that's also better suited to ward off the horde of IDL-
programmers
wannabes that would otherwise knock on my door ;-) ;-)
Ciao,
Paolo
>
> I used latitude with minutes and seconds in my phd defense, noting the
> position of
> an instrument. The examiner called me on it. Luckily I had used
> extremely detailed plots of the land to determine the lat and lon,
> and it did have an accuracy down to 10 meters. :)
>
>
> Cheers,
> bob
|
|
|
|
| Re: number problem [message #61232 is a reply to message #61198] |
Thu, 10 July 2008 12:17 |
R.G. Stockwell
Messages: 363
Registered: July 1999
|
Senior Member |
|
|
<pgrigis@gmail.com> wrote in message
news:c8f5bb5a-7b15-4abd-bf13-1587add65abe@j22g2000hsf.google groups.com...
> R.G. Stockwell wrote:
>> <d.poreh@gmail.com> wrote in message
>> news:43fbf367-1b18-473e-a047-3ce39612f806@x35g2000hsb.google groups.com...
>> .... snipped ...
>>
>>> yes that was the problem!!1
>>> it is works properly.but for lat-lon data as you can see it is not:
>>> 499690.96 3387795.6
>>
>>> i need more details like this
>>> 499690.95879779 3387795.57157002
>>
>> WHOA WHOA WHOA WHOA!!
>>
>> While we are being pleasant and thinking about what we are doing,
>> let's think about what it means when you say you need 8 digits of
>> lat and lon. (hint, think in millimeters)
>>
>>
>> Granted this is somewhat beside the point of how to read data, but if
>> anyone
>> ever reviews a lat or a lon with more than 2 decimal points, they will
>> flag
>> it.
>
> On the other hand, google maps will pinpoint
> the location of my office at
>
> 42.381009N, 71.128014W
>
> whereas that would be a bit off if it only
> had 2 decimals... ;-)
>
> Ciao,
> Paolo
True, 2 decimals places is about 1km (roughly). But 71.128014W
implies a precision of about 10 cm. That is smaller than the window.
Geophysical data - that is large enough to use lat and lon, is quite
often not taken on a resolution of cms.
Incidentally, three decimal places works just fine.
42.381N, 71.128W (100 m resolution)
I used latitude with minutes and seconds in my phd defense, noting the
position of
an instrument. The examiner called me on it. Luckily I had used
extremely detailed plots of the land to determine the lat and lon,
and it did have an accuracy down to 10 meters. :)
Cheers,
bob
|
|
|
|
|
|
|
|
| Re: number problem [message #61248 is a reply to message #61198] |
Thu, 10 July 2008 08:20 |
d.poreh
Messages: 406
Registered: October 2007
|
Senior Member |
|
|
On Jul 10, 5:12 pm, Paul van Delst <Paul.vanDe...@noaa.gov> wrote:
> d.po...@gmail.com wrote:
>> On Jul 10, 4:50 pm, Spon <christoph.b...@gmail.com> wrote:
>>> On Jul 10, 3:22 pm, David Fanning <n...@dfanning.com> wrote:
>
>>>> Paul van Delst writes:
>>>> > Think about what this line is doing:
>>>> >> a=0&b=0&c=0&d=0&e=0&f=0
>>>> > ...and how you subsequently use the variables.
>>>> This is why I love this newsgroup. I couldn't possibly
>>>> be this gentle this morning. :-)
>>>> Cheers,
>>>> David
>>>> --
>>>> David Fanning, Ph.D.
>>>> Fanning Software Consulting, Inc.
>>>> Coyote's Guide to IDL Programming:http://www.dfanning.com/
>>>> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
>>> I think this:
>>> dist=(dblarr(10000))
>>> dist(count)=f
>
>>> could potentially cause major headaches as there's an in-built IDL
>>> function called DIST. I don't know how rigorous IDL is about checking
>>> if something's a local variable before assuming it's a function -
>>> you'd probably get away with it - but it's not something I'd like to
>>> risk...
>
>>> In general, this looks like another case for Read_ASCII and
>>> ASCII_Template, to be honest. This is another wheel that doesn't need
>>> reinventing, IMHO :-)
>
>>> Regards
>
>> yes that was the problem!!1
>> it is works properly.but for lat-lon data as you can see it is not:
>> 499690.96 3387795.6
>
>> i need more details like this
>> 499690.95879779 3387795.57157002
>
> Now you need to read the IDL help manual section entitled: "Format Codes"
>
> It is available via
> IDL Programmers' Guides > Application Programming > Part II: Components of the IDL
> Language > Files and Input/Output
>
> The visual and internal representation of a floating point number are two very different
> things.
>
> Yea verily, here endeth the lesson.
>
> :o)
>
> cheers,
>
> paulv
>
> p.s. FWIW, this exact same question occurs quite regularly in the Fortran newsgroup as well.
thanks every body for help
Cheers
|
|
|
|
|
|
| Re: number problem [message #61250 is a reply to message #61198] |
Thu, 10 July 2008 08:12 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
d.poreh@gmail.com wrote:
> On Jul 10, 4:50 pm, Spon <christoph.b...@gmail.com> wrote:
>> On Jul 10, 3:22 pm, David Fanning <n...@dfanning.com> wrote:
>>
>>
>>
>>> Paul van Delst writes:
>>>> Think about what this line is doing:
>>>> > a=0&b=0&c=0&d=0&e=0&f=0
>>>> ...and how you subsequently use the variables.
>>> This is why I love this newsgroup. I couldn't possibly
>>> be this gentle this morning. :-)
>>> Cheers,
>>> David
>>> --
>>> David Fanning, Ph.D.
>>> Fanning Software Consulting, Inc.
>>> Coyote's Guide to IDL Programming:http://www.dfanning.com/
>>> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
>> I think this:
>> dist=(dblarr(10000))
>> dist(count)=f
>>
>> could potentially cause major headaches as there's an in-built IDL
>> function called DIST. I don't know how rigorous IDL is about checking
>> if something's a local variable before assuming it's a function -
>> you'd probably get away with it - but it's not something I'd like to
>> risk...
>>
>> In general, this looks like another case for Read_ASCII and
>> ASCII_Template, to be honest. This is another wheel that doesn't need
>> reinventing, IMHO :-)
>>
>> Regards
>
> yes that was the problem!!1
> it is works properly.but for lat-lon data as you can see it is not:
> 499690.96 3387795.6
>
> i need more details like this
> 499690.95879779 3387795.57157002
Now you need to read the IDL help manual section entitled: "Format Codes"
It is available via
IDL Programmers' Guides > Application Programming > Part II: Components of the IDL
Language > Files and Input/Output
The visual and internal representation of a floating point number are two very different
things.
Yea verily, here endeth the lesson.
:o)
cheers,
paulv
p.s. FWIW, this exact same question occurs quite regularly in the Fortran newsgroup as well.
|
|
|
|
|
|
| Re: number problem [message #61253 is a reply to message #61198] |
Thu, 10 July 2008 08:04 |
d.poreh
Messages: 406
Registered: October 2007
|
Senior Member |
|
|
On Jul 10, 4:50 pm, Spon <christoph.b...@gmail.com> wrote:
> On Jul 10, 3:22 pm, David Fanning <n...@dfanning.com> wrote:
>
>
>
>> Paul van Delst writes:
>>> Think about what this line is doing:
>>>> a=0&b=0&c=0&d=0&e=0&f=0
>
>>> ...and how you subsequently use the variables.
>
>> This is why I love this newsgroup. I couldn't possibly
>> be this gentle this morning. :-)
>
>> Cheers,
>
>> David
>
>> --
>> David Fanning, Ph.D.
>> Fanning Software Consulting, Inc.
>> Coyote's Guide to IDL Programming:http://www.dfanning.com/
>> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
>
> I think this:
> dist=(dblarr(10000))
> dist(count)=f
>
> could potentially cause major headaches as there's an in-built IDL
> function called DIST. I don't know how rigorous IDL is about checking
> if something's a local variable before assuming it's a function -
> you'd probably get away with it - but it's not something I'd like to
> risk...
>
> In general, this looks like another case for Read_ASCII and
> ASCII_Template, to be honest. This is another wheel that doesn't need
> reinventing, IMHO :-)
>
> Regards
yes that was the problem!!1
it is works properly.but for lat-lon data as you can see it is not:
499690.96 3387795.6
i need more details like this
499690.95879779 3387795.57157002
Thanks
|
|
|
|
|
|
|
|
|
|
|
|
| Re: number problem [message #61262 is a reply to message #61198] |
Thu, 10 July 2008 07:18 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
d.poreh@gmail.com wrote:
>
> i don't know still not work this is my idl to read some data:
> function read_DE,file
>
>
> file=dialog_pickfile(filter='*.txt')
> openr,lun,file,/get_lun
> header=strarr(5)
> readf,lun,header
> utx=(dblarr(10000))
> uty=(dblarr(10000))
> elv=(dblarr(10000))
> col=(dblarr(10000))
> row=(dblarr(10000))
> dist=(dblarr(10000))
Think about what this line is doing:
> a=0&b=0&c=0&d=0&e=0&f=0
...and how you subsequently use the variables.
> count=0
> while (NOT EOF(lun)) DO BEGIN
> readf,lun,a,b,c,d,e,f
> utx(count)=a
> uty(count)=b
> elv(count)=c
> col(count)=d
> row(count)=e
> dist(count)=f
> count=count+1
> endwhile
> utx=utx(0:count-1)
> uty=uty(0:count-1)
> elv=elv(0:count-1)
> col=col(0:count-1)
> row=row(0:count-1)
> dist=dist(0:count-1)
> data=fltarr(4,count)
> data[0,*]=utx
> data[1,*]=uty
> data[2,*]=elv
> data[3,*]=dist
>
>
> free_lun, lun
> return,data
> end
> and this is a few lines of import data:
>
>
> RiverTools Channel Profile
>
> Number of profile points: 1472
>
> UTM-x UTM-y Elev Col
> Row Distance
>
> 521228.87049479 3394754.96918202 2221.55273438 1078
> 592 0.00000000
> 521208.87243379 3394754.96918202 2218.10253906 1077
> 592 0.01999806
> 521188.87437279 3394754.96918202 2215.02856445 1076
> 592 0.03999612
> 521168.87631179 3394754.96918202 2212.82934570 1075
> 592 0.05999418
> 521148.87825079 3394754.96918202 2210.48925781 1074
> 592 0.07999224
> 521128.88018979 3394754.96918202 2207.43017578 1073
> 592 0.09999030
> 521108.88212879 3394754.96918202 2204.14746094 1072
> 592 0.11998836
> 521088.88406779 3394754.96918202 2201.20776367 1071
> 592 0.13998643
> 521068.88600679 3394754.96918202 2198.28808594 1070
> 592 0.15998448
> 521048.88794579 3394754.96918202 2195.11572266 1069
> 592 0.17998254
> 521028.88988479 3394754.96918202 2192.23193359 1068
> 592 0.19998060
> 521008.89182379 3394754.96918202 2190.31323242 1067
> 592 0.21997866
> 520988.89376279 3394774.96745102 2187.50000000 1066
> 591 0.24826033
> 520968.89570179 3394774.96745102 2185.21508789 1065
> 591 0.26825839
> 520948.89764079 3394774.96745102 2183.00000000 1064
> 591 0.28825647
> 520928.89957979 3394794.96572002 2181.38085938 1063
> 590 0.31653816
> 520908.90151879 3394794.96572002 2180.30151367 1062
> 590 0.33653623
> 520888.90345779 3394794.96572002 2177.80688477 1061
> 590 0.35653430
> 520868.90539679 3394794.96572002 2174.75122070 1060
> 590 0.37653238
>
>
> but still i can't get proper answer, this is lat-lon data and i need
> exact data.
>
|
|
|
|
| Re: number problem [message #61264 is a reply to message #61198] |
Thu, 10 July 2008 07:14 |
d.poreh
Messages: 406
Registered: October 2007
|
Senior Member |
|
|
On 10 Jul., 07:01, Vince Hradil <hrad...@yahoo.com> wrote:
> On Jul 9, 11:59 pm, d.po...@gmail.com wrote:
>
>
>
>
>
>> On 9 Jul., 11:11, Conor <cmanc...@gmail.com> wrote:
>
>>> On Jul 9, 6:50 am, d.po...@gmail.com wrote:
>
>>>> folks
>>>> i have a .TXt file like this:
>
>>>> 499750.95298079 3387735.57676302 1259.18847656 34.63407516
>>>> 499730.95491979 3387755.57503202 1259.18847656 34.66235733
>>>> 499710.95685879 3387775.57330102 1257.50012207 34.69063950
>>>> 499690.95879779 3387795.57157002 1255.97583008 34.71892166
>
>>>> and i did some analyze in IDL but result is like this:
>
>>>> 499750. 3.38774e+006 1259.00 34.0000
>>>> 499730. 3.38776e+006 1259.00 34.0000
>>>> 499710. 3.38778e+006 1257.00 34.0000
>>>> 499690. 3.38780e+006 1255.00 34.0000
>
>>>> but as you can see the result are not same. i used long-float and
>>>> ULL. but no answer.
>>>> any help
>>>> Cheeres
>
>>> I'm afraid you're going to have to include a lot more information
>>> before anyone can help. How are you reading in the data? It looks
>>> like you're just reading in the data as a long integer, when in
>>> reality you want doubles.- Zitierten Text ausblenden -
>
>>> - Zitierten Text anzeigen -
>
>> yes i just read the data and keep it in the 4*1470 array. i just want
>> to get the same data in the resualt.
>
> Yes - we need more info to go on...
>
> IDL> arr = dblarr(4,4)
> IDL> openr, 1, 'c:\test.txt'
> IDL> readf, 1, arr
> IDL> free_lun, 1
> IDL> print, arr
> 499750.95 3387735.6 1259.1885 34.634075
> 499730.95 3387755.6 1259.1885 34.662357
> 499710.96 3387775.6 1257.5001 34.690640
> 499690.96 3387795.6 1255.9758 34.718922
>
> Hmmm... looks okay to me?- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -
i don't know still not work this is my idl to read some data:
function read_DE,file
file=dialog_pickfile(filter='*.txt')
openr,lun,file,/get_lun
header=strarr(5)
readf,lun,header
utx=(dblarr(10000))
uty=(dblarr(10000))
elv=(dblarr(10000))
col=(dblarr(10000))
row=(dblarr(10000))
dist=(dblarr(10000))
a=0&b=0&c=0&d=0&e=0&f=0
count=0
while (NOT EOF(lun)) DO BEGIN
readf,lun,a,b,c,d,e,f
utx(count)=a
uty(count)=b
elv(count)=c
col(count)=d
row(count)=e
dist(count)=f
count=count+1
endwhile
utx=utx(0:count-1)
uty=uty(0:count-1)
elv=elv(0:count-1)
col=col(0:count-1)
row=row(0:count-1)
dist=dist(0:count-1)
data=fltarr(4,count)
data[0,*]=utx
data[1,*]=uty
data[2,*]=elv
data[3,*]=dist
free_lun, lun
return,data
end
and this is a few lines of import data:
RiverTools Channel Profile
Number of profile points: 1472
UTM-x UTM-y Elev Col
Row Distance
521228.87049479 3394754.96918202 2221.55273438 1078
592 0.00000000
521208.87243379 3394754.96918202 2218.10253906 1077
592 0.01999806
521188.87437279 3394754.96918202 2215.02856445 1076
592 0.03999612
521168.87631179 3394754.96918202 2212.82934570 1075
592 0.05999418
521148.87825079 3394754.96918202 2210.48925781 1074
592 0.07999224
521128.88018979 3394754.96918202 2207.43017578 1073
592 0.09999030
521108.88212879 3394754.96918202 2204.14746094 1072
592 0.11998836
521088.88406779 3394754.96918202 2201.20776367 1071
592 0.13998643
521068.88600679 3394754.96918202 2198.28808594 1070
592 0.15998448
521048.88794579 3394754.96918202 2195.11572266 1069
592 0.17998254
521028.88988479 3394754.96918202 2192.23193359 1068
592 0.19998060
521008.89182379 3394754.96918202 2190.31323242 1067
592 0.21997866
520988.89376279 3394774.96745102 2187.50000000 1066
591 0.24826033
520968.89570179 3394774.96745102 2185.21508789 1065
591 0.26825839
520948.89764079 3394774.96745102 2183.00000000 1064
591 0.28825647
520928.89957979 3394794.96572002 2181.38085938 1063
590 0.31653816
520908.90151879 3394794.96572002 2180.30151367 1062
590 0.33653623
520888.90345779 3394794.96572002 2177.80688477 1061
590 0.35653430
520868.90539679 3394794.96572002 2174.75122070 1060
590 0.37653238
but still i can't get proper answer, this is lat-lon data and i need
exact data.
|
|
|
|
| Re: number problem [message #61282 is a reply to message #61232] |
Sat, 12 July 2008 14:58 |
Jeremy Bailin
Messages: 618
Registered: April 2008
|
Senior Member |
|
|
On Jul 10, 3:17 pm, "R.G. Stockwell" <notha...@noemail.com> wrote:
> <pgri...@gmail.com> wrote in message
>
> news:c8f5bb5a-7b15-4abd-bf13-1587add65abe@j22g2000hsf.google groups.com...
>
>
>
>> R.G. Stockwell wrote:
>>> <d.po...@gmail.com> wrote in message
>>> news:43fbf367-1b18-473e-a047-3ce39612f806@x35g2000hsb.google groups.com...
>>> .... snipped ...
>
>>>> yes that was the problem!!1
>>>> it is works properly.but for lat-lon data as you can see it is not:
>>>> 499690.96 3387795.6
>
>>>> i need more details like this
>>>> 499690.95879779 3387795.57157002
>
>>> WHOA WHOA WHOA WHOA!!
>
>>> While we are being pleasant and thinking about what we are doing,
>>> let's think about what it means when you say you need 8 digits of
>>> lat and lon. (hint, think in millimeters)
>
>>> Granted this is somewhat beside the point of how to read data, but if
>>> anyone
>>> ever reviews a lat or a lon with more than 2 decimal points, they will
>>> flag
>>> it.
>
>> On the other hand, google maps will pinpoint
>> the location of my office at
>
>> 42.381009N, 71.128014W
>
>> whereas that would be a bit off if it only
>> had 2 decimals... ;-)
>
>> Ciao,
>> Paolo
>
> True, 2 decimals places is about 1km (roughly). But 71.128014W
> implies a precision of about 10 cm. That is smaller than the window.
> Geophysical data - that is large enough to use lat and lon, is quite
> often not taken on a resolution of cms.
>
> Incidentally, three decimal places works just fine.
> 42.381N, 71.128W (100 m resolution)
>
> I used latitude with minutes and seconds in my phd defense, noting the
> position of
> an instrument. The examiner called me on it. Luckily I had used
> extremely detailed plots of the land to determine the lat and lon,
> and it did have an accuracy down to 10 meters. :)
>
> Cheers,
> bob
Well, that's an accuracy of 36 microarcsec. If those were sky
coordinates (ie. RA, dec) instead of lat, long, that's perfectly
reasonable in certain circumstances (eg. GAIA is supposed to give
better astrometry than that).
-Jeremy.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
