comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: problem in using function ll_to_utm.pro
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: problem in using function ll_to_utm.pro [message #60464] Wed, 21 May 2008 06:47
ben.bighair is currently offline  ben.bighair
Messages: 221
Registered: April 2007
Senior Member
On May 20, 9:37 pm, Baikal <royou...@cnu.ac.kr> wrote:
> On 5월21일, 오전10시01분, "ben.bighair" <ben.bigh...@gmail.com> wrote:
>
>
>
>> On May 20, 8:19 pm, Baikal <royou...@cnu.ac.kr> wrote:
>
>>> To all,
>
>>> I am a physical oceanographer who needs to use your idl program in my
>>> model output post-processing.
>
>>> While utilizing your utm conversion program (ll_to_utm.pro) in my
>>> research work, I have a problem due to zone change so that I encounter
>>> a discontinuity problems as follows;
>
>>> test_lon=[125.999,126.000] ; define test lon & lat
>>> test_lat=[36.000,36.000]
>>> ; test output
>>> for i=0,1 do
>>> print,i,test_lon(i),test_lat(i),ll_to_utm(test_lon(i),test_l at(i))
>>> 0 125.999 36.0000 770330.54 3988106.3
>>> 1 126.000 36.0000 229579.34 3988109.1
>
>>> I undrestand this is due to zone change from 51 to 52.
>>> I wonder how I can avoid this trouble in map drawing where my
>>> coastline data points lie over 125 to 127 E longitude.
>
>>> I appreciate your helps.
>
>> Hi,
>
>> I think I might have prepared that routine. To my understanding, you
>> don't want to work across UTM zones. My memory is a little rusty, but
>> I recall that the warping is minimized along central meridian of any
>> zone. I take that to mean that distortion is maximized along the
>> edges.
>
>> On the other hand, I suppose it is possible to offset the values in
>> one zone against the central meridian of the other - after all, the
>> origin of any UTM zone is some arbitrary value. You would have to
>> dive into the Snyder work referenced in the code. In any event, I
>> wonder why you are not mapping with your lat lon values directly. Why
>> bother going to UTM coords?
>
>> While we are at it, I have posted an update to that collection files -
>> in particular to UTM_ZONE so that it behaves a little better with
>> vectors of inputs. See ...
>
>> http://www.tidewater.net/~pemaquid/geo.zip
>
>> Cheers,
>> Ben- 따온 텍스트 숨기기 -
>
>> - 따온 텍스트 보기 -
>
> In my post-processing of model output, I am calculating the trajectory
> coordinates in metric unit so that to display the, trajectories of
> number of particles, I need to set up the coordinate in terms of UTM.
> That's why I bother myself and you in trying to use UTM.
>

Hello,

Hmmm. I don't think I get it. You can calculate trajectories as
range-azimuth pairs if you you know the lat-lon coords of the
trajectories. Range is generally measured in length units (like m or
km) and azimuth gives the direction.

But, suppose you persisted with converting to a UTM style
projection... the divisions that mark the different longitudinal zones
are conventional but arbitrary. There isn't any reason why you can't
change the central meridian from which each of your locations are
subsequently referenced. Doing so means that you need to change the CM
(central meridian) value returned by the UTM_ZONE function. Keep in
mind that if you change the zone definitions to something non-
conventional then you might have trouble comparing your results to the
work of others that use conventional mapping.

Ben
Re: problem in using function ll_to_utm.pro [message #60475 is a reply to message #60464] Tue, 20 May 2008 18:37 Go to previous message
Baikal is currently offline  Baikal
Messages: 4
Registered: May 2008
Junior Member
On 5월21일, 오전10시01분, "ben.bighair" <ben.bigh...@gmail.com> wrote:
> On May 20, 8:19 pm, Baikal <royou...@cnu.ac.kr> wrote:
>
>
>
>
>
>> To all,
>
>> I am a physical oceanographer who needs to use your idl program in my
>> model output post-processing.
>
>> While utilizing your utm conversion program (ll_to_utm.pro) in my
>> research work, I have a problem due to zone change so that I encounter
>> a discontinuity problems as follows;
>
>> test_lon=[125.999,126.000] ; define test lon & lat
>> test_lat=[36.000,36.000]
>> ; test output
>> for i=0,1 do
>> print,i,test_lon(i),test_lat(i),ll_to_utm(test_lon(i),test_l at(i))
>> 0 125.999 36.0000 770330.54 3988106.3
>> 1 126.000 36.0000 229579.34 3988109.1
>
>> I undrestand this is due to zone change from 51 to 52.
>> I wonder how I can avoid this trouble in map drawing where my
>> coastline data points lie over 125 to 127 E longitude.
>
>> I appreciate your helps.
>
> Hi,
>
> I think I might have prepared that routine. To my understanding, you
> don't want to work across UTM zones. My memory is a little rusty, but
> I recall that the warping is minimized along central meridian of any
> zone. I take that to mean that distortion is maximized along the
> edges.
>
> On the other hand, I suppose it is possible to offset the values in
> one zone against the central meridian of the other - after all, the
> origin of any UTM zone is some arbitrary value. You would have to
> dive into the Snyder work referenced in the code. In any event, I
> wonder why you are not mapping with your lat lon values directly. Why
> bother going to UTM coords?
>
> While we are at it, I have posted an update to that collection files -
> in particular to UTM_ZONE so that it behaves a little better with
> vectors of inputs. See ...
>
> http://www.tidewater.net/~pemaquid/geo.zip
>
> Cheers,
> Ben- 따온 텍스트 숨기기 -
>
> - 따온 텍스트 보기 -

In my post-processing of model output, I am calculating the trajectory
coordinates in metric unit so that to display the, trajectories of
number of particles, I need to set up the coordinate in terms of UTM.
That's why I bother myself and you in trying to use UTM.

Thanks for your quick reply

Young Jae Ro
Re: problem in using function ll_to_utm.pro [message #60478 is a reply to message #60475] Tue, 20 May 2008 18:01 Go to previous message
ben.bighair is currently offline  ben.bighair
Messages: 221
Registered: April 2007
Senior Member
On May 20, 8:19 pm, Baikal <royou...@cnu.ac.kr> wrote:
> To all,
>
> I am a physical oceanographer who needs to use your idl program in my
> model output post-processing.
>
> While utilizing your utm conversion program (ll_to_utm.pro) in my
> research work, I have a problem due to zone change so that I encounter
> a discontinuity problems as follows;
>
> test_lon=[125.999,126.000] ; define test lon & lat
> test_lat=[36.000,36.000]
> ; test output
> for i=0,1 do
> print,i,test_lon(i),test_lat(i),ll_to_utm(test_lon(i),test_l at(i))
> 0 125.999 36.0000 770330.54 3988106.3
> 1 126.000 36.0000 229579.34 3988109.1
>
> I undrestand this is due to zone change from 51 to 52.
> I wonder how I can avoid this trouble in map drawing where my
> coastline data points lie over 125 to 127 E longitude.
>
> I appreciate your helps.

Hi,

I think I might have prepared that routine. To my understanding, you
don't want to work across UTM zones. My memory is a little rusty, but
I recall that the warping is minimized along central meridian of any
zone. I take that to mean that distortion is maximized along the
edges.

On the other hand, I suppose it is possible to offset the values in
one zone against the central meridian of the other - after all, the
origin of any UTM zone is some arbitrary value. You would have to
dive into the Snyder work referenced in the code. In any event, I
wonder why you are not mapping with your lat lon values directly. Why
bother going to UTM coords?

While we are at it, I have posted an update to that collection files -
in particular to UTM_ZONE so that it behaves a little better with
vectors of inputs. See ...

http://www.tidewater.net/~pemaquid/geo.zip

Cheers,
Ben
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Least square fitting
Next Topic: DLM 32/64 bits

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 13:45:41 PDT 2025

Total time taken to generate the page: 0.00685 seconds