Hi Tom:
my new algorithm now does this with the troubling rows:
this last one may be a problem -167.257996, -203.448914, 47.010693 ??
this fix will be in 4.3.18 by next week.
John
I do think it's legitimate - it's pretty much going across the pole:
longitude(6612:6612:1, 365:380:1) {-151.92747, -151.65495, -151.29546, -150.79941, -150.07088, -148.89677, -146.69113, -141.069, -105.116974, 5.3398786, 16.867168, 20.193335, 21.76123, 22.672321, 23.26762, 23.68702}
latitude(6612:6612:1, 365:380:1) {-89.22333, -89.3125, -89.40289, -89.49457, -89.587494, -89.6817, -89.77707, -89.87305, -89.96222, -89.91919, -89.82007, -89.71716, -89.61212, -89.50516, -89.39627, -89.28543}
I think it's less about a delta-longitude and more about a physical distance....but you probably don't want to be computing distances all the time.
...but I obviously don't understand the issues -- why do you have to fiddle with the longitude values that are in the file and are within the "valid_range"?
Thanks again for your help with this stuff...
tom
On Tue, Jul 2, 2013 at 10:58 AM, John Caron <address@hidden> wrote:so you think that the grid lon really jumps from -105.116974 to 5.3398786 ? what do you think the maximum legitimate jump is?
i think i can improve algorithm to eliminate addding the +/- 360 when it doesnt create a close number to the previous.
On 7/2/2013 8:20 AM, Tom Whittaker wrote:
Hi John ...
Thanks for taking a look. What I see from a ToolsUI dump of row 6612, though, is that when your output shows a jump to -354, the data in the file shows +5.3398...:
-150.07088, -148.89677, -146.69113, -141.069, -105.116974, 5.3398786, 16.867168, 20
So this is a line that is near the pole and changing longitudes rapidly....but the longitude shouldn't be -354, should it? If the valid_range is give as -180:+180, then I would think (in my naive way) that this should say there is no seam when crossing 0.... Now if the valid_range were 0:360, then I could see doing a modulo 360 or something.
Is there any hope to get this "fixed"?
Thanks.
tom
heres a problem where -105.116974 jumps to -354.660121, seems to be in the data (modulo 360):
6612: -153.953491, -153.952591, -153.951706, -153.950836, -153.949982, -153.949127, -153.948303, -153.947495, -153.946686, -153.945892,
.....
-152.673935, -152.573288, -152.454803, -152.313248, -152.141174, -151.927475, -151.654953, -151.295456, -150.799408, -150.070877, -148.896774, -146.691132, -141.069000, -105.116974, -354.660121, -343.132832, -339.806665, -338.238770, -337.327679, -336.732380,
-- Tom Whittaker University of Wisconsin-Madison Space Science & Engineering Center (SSEC) Cooperative Institute for Meteorological Satellite Studies (CIMSS) 1225 W. Dayton Street Madison, WI 53706 USA ph: +1 608 262 2759
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.