NIMROD loading

[bblay]

No description provided.

[bblay]

This is where #52 is needed. The code is commented out, ready to use after #52 has been brought in.

[esc24]

@bblay I've taken a look at nimrod.py and put a bunch of comments inline. I've also looked over your proposed changes to the file format mechanism. I have a number of issues that I'd like to discuss on this, and I'd rather not mix up the two discussions or hold up the NIMROD functionality any more than necessary. Could you split these two sets of changes out into two separate pull requests?

[bblay]

All review avctions implemented except:

• CF coord systems #52 (not yet available)
• NIMROD loading #54 (comment) (isn't that behaviour what we want?)
  • (answering myself, no it's not what we want. implement this change)

Format recognition moved into https://github.com/bblay/iris/tree/formats for later.

[pelson]

Not sure about this behaviour. Have you come across such units?

[bblay]

yeah, the sample data I'm loading is in m/2-25k !

[esc24]

I'm a little uneasy about this too, but improving the unit handling is a significant chunk of work. Although this differs from the rest of the loaders (which don't attempt to catch the exception) I think it's reasonable workaround. I think a warning is in order though to let the user know the units could not be parsed and have been squirrelled away.

[pelson]

On the whole, I think the nimrod reading would benefit from using numpy.fromfile rather than struct. Other than that, I think its a good start into reading Nimrod.

[pelson]

I should add that it would be nice to extract the names of the nimrod variables out to a tuple so that should anyone wish to implement saving in the future, the process would be fairly straight forward.

[esc24]

Should there be a double ':' here?