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
{{ message }}
Repository navigation
cross_section() does not match requested start and end #1089
importpickleimportnumpyasnpimportmetpyfrommetpy.interpolateimportcross_sectionimportxarrayasxrimportcartopyimportcartopy.crsasccrswithopen('ds2.pickle', 'rb') asf:
ds2=pickle.load(f)
start= (40.0, -105.0)
end= (45.0, -68.0)
cross=cross_section(ds2, start, end)
cross.set_coords(('lat', 'lon'), True)
print(cross.lat[0].values, cross.lon[0].values)
print(cross.lat[-1].values, cross.lon[-1].values)
# Extra printouts to verify projection information agreed#print(ds2.crs.to_dict()['data'].to_dict())#print(ds2.LambertConformal)print(metpy.__version__)
print(xr.__version__)
print(cartopy.__version__)
The output:
xsecbug.py:16: FutureWarning: The inplace argument has been deprecated and will be removed in a future version of xarray.
cross.set_coords(('lat', 'lon'), True)
42.14027577619222 -91.72784705269194
43.045485539202936 -54.08897522118793
0.10.2
0.12.2
0.17.0
Expected output
I would hope the start and end points in the cross section would be much closer to the (40, -105) and (45,-68) requested.
Would you be able to determine how the original lat/lon values in dataset were computed (and on what datum)?
As far as I can tell looking at the dataset, they don't seem to match the x/y dimension coordinates and crs given (which are what MetPy uses for finding the cross section) under cartopy transforms. For example, it looks like the longitude values given are off by around 10-17 degrees from what would be expected from the x/y coordinates and crs:
OK, I figured something wonky was going on in the coordinate calculations. This is WRF output that has been post-processed. What's weird is a different WRF output file (albeit for a different domain), when processed in the same way, generates the proper cross section. I'll need to spend some time reducing the post-processing piece to its essence (right now the "bad" WRF output is a 44 GB netCDF file), and then I'll post it here.
In the meantime, I am wondering if it might be a good idea for cross_section to perform some of these sanity checks and error out when confronted with a DataArray/Dataset like this.
I definitely like the idea of being able to sanity check the coordinates of a DataArray/Dataset, but I hesitate in making it tied to cross_section specifically, since any coordinate errors will not just affect cross_section, but also the kinematics functions in the near future (ref #893). Unless there are suggestions to the contrary, I think I'll just try including something like this as I work on dataset helpers.
This would also require identification of both lat/lon auxiliary coordinates and x/y dimension coordinates at the same time, which the current implementation of coordinate identification cannot do. But, I think it would be a worthwhile change (see #1090).
Aha, I see the WRF output that works has CEN_LON and STAND_LON attributes that are the same, but for the wonky output, CEN_LON is -72.26288, but STAND_LON is -85.5. This is suspiciously within the range of 10-17 degrees found by @jthielen above. I will cross my fingers that x0 in my posted code should be CEN_LON, not STAND_LON, but I suppose it is possible I need CEN_LON for some parts of the calculation, and STAND_LON for others. I'll find out soon enough!
It's the latter case (and I should have written xp0 above). Looks like I need both STAND_LON and CEN_LON, and I'll need to figure out where to use each one.
OK, I think I have it figured out. The relevant sections of the code should be modified as follows, where xs is STAND_LON, and xp0 is CEN_LON:
# The pyproj object should use the STAND_LON value:
wrf_proj = pyproj.Proj(proj='lcc',
lat_1=yp1, lat_2=yp2,
lat_0=yp0, lon_0=xs,
a=6370000, b=6370000)
To compute easting and northing, use CEN_LON:
e, n = pyproj.transform(wgs_proj, wrf_proj, xp0, yp0_m)
The xarray metadata should use STAND_LON (consistent with pyproj):
Activity
jthielen commentedon Jul 10, 2019
Would you be able to determine how the original lat/lon values in dataset were computed (and on what datum)?
As far as I can tell looking at the dataset, they don't seem to match the x/y dimension coordinates and crs given (which are what MetPy uses for finding the cross section) under cartopy transforms. For example, it looks like the longitude values given are off by around 10-17 degrees from what would be expected from the x/y coordinates and crs:
As a sanity check, the computed lat/lons from the cross section match the desired start and end points:
sgdecker commentedon Jul 10, 2019
OK, I figured something wonky was going on in the coordinate calculations. This is WRF output that has been post-processed. What's weird is a different WRF output file (albeit for a different domain), when processed in the same way, generates the proper cross section. I'll need to spend some time reducing the post-processing piece to its essence (right now the "bad" WRF output is a 44 GB netCDF file), and then I'll post it here.
In the meantime, I am wondering if it might be a good idea for
cross_sectionto perform some of these sanity checks and error out when confronted with a DataArray/Dataset like this.sgdecker commentedon Jul 10, 2019
Here's an updated testcase:
wrfout1.nc fails, but change line 71 to refer to wrfout2.nc and it works as expected. The two netCDF files are at
https://drive.google.com/file/d/1VbpkIKsEX2tHHi07KCeDuJ1iFq3G6xSJ/view?usp=sharing
and
https://drive.google.com/file/d/1Vd5HLck8R3Md11gVSiOBsLsHflE2-4Cs/view?usp=sharing
respectively.
jthielen commentedon Jul 10, 2019
I definitely like the idea of being able to sanity check the coordinates of a DataArray/Dataset, but I hesitate in making it tied to
cross_sectionspecifically, since any coordinate errors will not just affectcross_section, but also the kinematics functions in the near future (ref #893). Unless there are suggestions to the contrary, I think I'll just try including something like this as I work on dataset helpers.This would also require identification of both lat/lon auxiliary coordinates and x/y dimension coordinates at the same time, which the current implementation of coordinate identification cannot do. But, I think it would be a worthwhile change (see #1090).
sgdecker commentedon Jul 11, 2019
Aha, I see the WRF output that works has CEN_LON and STAND_LON attributes that are the same, but for the wonky output, CEN_LON is -72.26288, but STAND_LON is -85.5. This is suspiciously within the range of 10-17 degrees found by @jthielen above. I will cross my fingers that
x0in my posted code should be CEN_LON, not STAND_LON, but I suppose it is possible I need CEN_LON for some parts of the calculation, and STAND_LON for others. I'll find out soon enough!sgdecker commentedon Jul 11, 2019
It's the latter case (and I should have written
xp0above). Looks like I need both STAND_LON and CEN_LON, and I'll need to figure out where to use each one.sgdecker commentedon Jul 11, 2019
OK, I think I have it figured out. The relevant sections of the code should be modified as follows, where
xsis STAND_LON, andxp0is CEN_LON:To compute easting and northing, use CEN_LON:
The xarray metadata should use STAND_LON (consistent with pyproj):
dopplershift commentedon Jul 26, 2019
Looks like things have been figured out, but we'll leave this open as a reminder for more sanity checking in the cross section code.