Add support for Lambert Azimuthal Equal Area Projection #187
Conversation
…t azimuthal equal area projection.
update to latest
|
bump |
|
@lbdreyer @bjlittle @alastair-gemmell Apologies for tagging you all but I wasn't sure who to contact to review and I'm not able to assign reviewers. This one has been hanging around since Jan, is there anything extra that needs doing before this gets merged? This is required to load MO UKV GRIB files into Iris. |
| @@ -143,6 +143,9 @@ def data(self): | |||
| raise TranslationError(msg) | |||
| if template in (20, 30, 90): | |||
| shape = (grid_section['Ny'], grid_section['Nx']) | |||
| elif template == 140: | |||
| shape = (grid_section['numberOfPointsAlongYAxis'], | |||
| grid_section['numberOfPointsAlongXAxis']) | |||
There was a problem hiding this comment.
Have you checked that we can't just use "Nx" and "Ny", and so integrate this into the section above ?
There was a problem hiding this comment.
noted, unfortunately when I tried this it didn't work hence adding these more complete names.
| nx = section['Nx'] | ||
| ny = section['Ny'] | ||
| if section['gridDefinitionTemplateNumber'] == 140: | ||
| dx = section['xDirectionGridLengthInMillimetres'] |
There was a problem hiding this comment.
Did you check that the shorter names don't in fact work?
-- if not, we wouldn't need this test, or this section because the generic ("else") code can do it.
I ask because I can see that the template definition 3.140 in the official docs (https://community.wmo.int/activity-areas/wmo-codes/manual-codes/volume-i2) does at least reference the shorter names,
e.g. "31–34 Nx – number of points along the x-axis".
In the end though, we can only use what implemented in eccodes.
|
@tpowellmeto Sorry for raising points after making you wait for ages Your test is very tidy, thanks. |
|
@tpowellmeto I'm just wondering if you also have some "real data" which you could release in public (in iris-test-data), so we can have a practical fallback when doing code development ? Whereas a focussed unit-test is very useful for picking up odd mistakes and changes, "real" data is needed to support integration testing, which is invaluable if code needs refactoring. I say this because we have had many problems in the past with GRIB compatibility |
|
@pp-mo WRT the request for "real-data", unfortunately I don't have the authority off the bat to release operational data into the wild. I will take this as an action and follow up with Service Hub owners to see what is possible. So as not to block this change if I can get some I'll raise as a future PR. :) |
|
Thanks @tpowellmeto ! |
Add support for loading GRIB2 template 3.140
https://apps.ecmwf.int/codes/grib/format/grib2/templates/3/140