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

Home » Public Forums » archive » Re: Transverse cylidrical map projection.
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Transverse cylidrical map projection. [message #19450] Fri, 24 March 2000 00:00 Go to previous message
James Kuyper is currently offline  James Kuyper
Messages: 425
Registered: March 2000
Senior Member
Liam Gumley wrote:
>
> James Kuyper <kuyper@wizard.net> wrote in message
> news:38DA1B88.7A690089@wizard.net...
>> I want to plot data using a transverse cylindrical map projection. An
>> equal-area one would be best, but equidistant or mercator would be
>> almost as good, just so as long as it's transverse version of one of the
>> cylindrical projections. MAP_SET accepts a tilt angle, which doesn't do
>> what I want for most of the cylindrical projections. The user's guide
>> contains an example command:
>>
>> map_set,0,0,45,londel=20,latdel=20,/grid,$
>> /continent,/cyl,title='Oblique Cylindrical Equidistant'
>>
>> which is shown in the book as producing a map with the projection axis
>> tilted by 45 degrees: the lines of constant latitude and longitude are
>> curved. When I try it, I get a map tilted by 45 degrees, which is a very
>> different thing: The lines of constant latitude and longitude are
>> strait, tilted by 45 degrees. This suggests that the book was printed
>> using a different (hopefully later) version of IDL than I'm using. I saw
>> the problem first in version 5.0.3, but I've recently discovered where
>> they've hidden version 5.2 on our machine, and I still see the same
>> results using it.
>>
>> Luckily, I've found that the transverse mercator projection does
>> implement the tilt properly. However, in large maps it often considers

It turns out I was mistaken. In both cases, it was tilting the map,
rather than the axis of the projection.

>> one or more of my limit points unmappable, for reasons that escape me.
>> For example,
>>
>> map_set,-15.7970,-90.4190,260.1820, limit=[78.548,-31.494, $
>> -27.66,-64.441, -64.066,103.55, -0.792,-114.296],$
>> /continents,/grid,/label,/isotropic,/transverse_mercator
>>
>> Produces the complaints:
>> % MAP_SET_LIMITS: Unmappable limit point: -31.4940 78.5480
>> % MAP_SET_LIMITS: Unmappable limit point: 103.550 -64.0660
...
> James,
>
> I haven't bothered with the LIMIT keyword to MAP_SET since I discovered the
> SCALE keyword:
>
> map_set, -15.7970, -90.4190, 260.1820, /transverse, scale=50e6
> map_continents, /hires
> map_grid, /label
>
> The map is always isotropic, and it always fills the current display. You
> usually need to experiment a little with the scale factor, but it beats
> trying to guess map limits.

I don't want to do it that way. I'm conveying an extra level of
information by my choice of boundaries; they corresponding to the
farthest distance the satellite could see in each direction at any time
during the data collection, if it had been pointed in that direction.
This provides a context for displaying the images it saw in the
direction it was actually pointing.

In any event, I resolved the problem. The feature I wanted is controlled
by the 'central_azimuth' parameter, rather than by the 'rot' parameter.
Looking at their descriptions, I can't figure out why they work the way
they do. 'rot' has basically the effect I would expect given the
description of 'central_azimuth', and vice-versa. Once I figured out the
correct central_azimuth angle, MAP_SET had no problems with my limit
points.
[Message index]
 
Read Message
Read Message
Previous Topic: pvwave
Next Topic: VDE2000 Reminder and Update

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

Current Time: Wed Oct 08 19:13:18 PDT 2025

Total time taken to generate the page: 0.00474 seconds