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

Home » Public Forums » archive » Map_set limits
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: Map_set limits [message #10516 is a reply to message #10462] Mon, 08 December 1997 00:00 Go to previous messageGo to previous message
nick is currently offline  nick
Messages: 4
Registered: July 1993
Junior Member
In article <3483EC71.7861@ias.fr>, =?iso-8859-1?Q?St=E9phane?= Erard
<Erard@ias.fr> writes:
|>
|> My original question was about the reason why somebody took the pain
to
|> make this change (modication made in march 1993, that should be
version
|> 3.6). Perhaps David is right in suggesting I'm optimistic in
supposing
|> there is a reason, but still... I'm planning to adapt map_set to
|> planetary mapping, so I need to correct also problems like this one.
If
|> it was a bug correction, I wouldn't like to resurect an old ghost.
|> Anybody has an idea?
|>
|>
i had a discussion about this with idl support a couple of years ago.
i often plot a rectangular array of global data, and overlay the
continents.
when version 3.5.1 came out, i began to see that the overlay didn't
quite
reach the edges of the window, so that the outline no longer matched
the
lat/lon of the data. supposedly setting xmargin/ymargin to zero was
supposed
help with this (at least as i read the documentation) but didn't.

after some convincing, i received the following e-mail form rsi tech
support,
with some explanation of why the change was made to map_set.

-------------------------------------------
> The following is a suggested workaround from development here at RSI
> regarding the problem you were having with map_set.pro. I hope this
> helps.
>
> Sincerely,
> Mark
> RSI
>
> ---
> suggest that for now you tell the customer to copy map_set.pro
> and make the following change.
>
> About line 300, is the curious line,
>
> fudge=0.01
>
> Which the user should replace with something like,
>
> if not(border) and total(xmargin) eq 0 and total(ymargin) eq 0 then $
> fudge=0.0 else fudge=0.01
>
> The 'fudge' is a protector against near zero values of the
transformation
> coordinates (U,V). On some projections, this is necessary, while on
others
> it may not be. I agree that there should be some way to turn this off,
so
> I propose this solution.

--


Nick DiGirolamo
nick@boingo.gsfc.nasa.gov
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Subscript sizes
Next Topic: Re: Fresnel Integrals

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

Current Time: Sun Oct 12 07:22:16 PDT 2025

Total time taken to generate the page: 1.11869 seconds