You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have code that depends on that routine and the resulting RotatedPole to do a series of ecliptic calculations. Unfortunately, I've had to copy-and-modify, because the original code - due to the if above - produces discontinuous behaviour when lat (i.e. solar declination) crosses zero. In one half of the annual domain, the behaviour is correct; and in the other half the following happen:
I believe the boundary of behaviour is at the September equinox
delta_sun changes sign, which in itself is not a problem
lat becomes positive; also not a problem
the if expression above abruptly starts evaluating to True
the entire coordinate system abruptly becomes inverted.
I have found that only the second case is correct (i.e. negative latitude). Copying the implementation and removing the conditional, preserving only the second case, produces correct, continuous behaviour.
I suspect that the reason this hasn't been noticed is that the nightshade curve is symmetric and so inversion is "invisible"; but anyone using the CRS owned by Nightshade for asymmetric curves is going to get a nasty surprise.
Code to reproduce
Compare behaviour before and after 3b77fe0, before and after an equinox.
Can you post a screenshot of a specific day/time with incorrect behavior? As far as I understand from the description, this inversion twice a year during the equinox is working as it should, but could not follow the argument about asymmetric curves.
In this 'isochrones' project it only makes sense for the isochrones from west to east to appear as orange, yellow, pink, purple and blue in that order. After the equinox they appear correct. Before the equinox, the coordinate system transformation essentially shows solar time in reverse.
I am also not following exactly what is wrong/what is needed to fix here. Could you make a reproducible example with just Cartopy and the nightshade feature geometry/points explaining what you mean?
Is it that the geometry goes from something like [p0, p1, p2, ...] ascending points before September, and then goes to [... p2, p1, p0] after September and thus the coordinate order is reversed and that causes issues downstream? So it would help to always keep things in the same ascending/descending order within the geometry that is created.
Description
From the beginning, the implementation of
Nightshade
has includedI have code that depends on that routine and the resulting
RotatedPole
to do a series of ecliptic calculations. Unfortunately, I've had to copy-and-modify, because the original code - due to theif
above - produces discontinuous behaviour whenlat
(i.e. solar declination) crosses zero. In one half of the annual domain, the behaviour is correct; and in the other half the following happen:delta_sun
changes sign, which in itself is not a problemlat
becomes positive; also not a problemif
expression above abruptly starts evaluating toTrue
I have found that only the second case is correct (i.e. negative latitude). Copying the implementation and removing the conditional, preserving only the second case, produces correct, continuous behaviour.
I suspect that the reason this hasn't been noticed is that the nightshade curve is symmetric and so inversion is "invisible"; but anyone using the CRS owned by
Nightshade
for asymmetric curves is going to get a nasty surprise.Code to reproduce
Compare behaviour before and after 3b77fe0, before and after an equinox.
Operating system
All
Cartopy version
0.22, but theoretically all versions
pip list
The text was updated successfully, but these errors were encountered: