Mr std name

[marqh]

Providing an updated standard name population process based on metarelate

[cpelley]

very minor thing but since strings are immutable, I think its better in this case to:

report = ('''The unit string '{u}' referenced by '{sn}' '''
          'is not recognised by iris.unit.Unit')

[cpelley]

Would it not still be good to have the capability to call setup.py with an argument to build the most recent version of these translations? (i.e. calling your generate_translations.py)

[cpelley]

(I do realise that a pre-generated dictionary of standard names will be provided as a result of this work, lib/iris/std_names.py)

[cpelley]

I'm happy to be reviewer if you like

[marqh]

Would it not still be good to have the capability to call setup.py with an argument to build the most recent version of these translations? (i.e. calling your generate_translations.py)

I don't think so. with this proposed workflow the building will not be part of setup. A user or developer may choose to rerun the script to get up to the minute information, which will require metarelate to be available, in their build but I would be wary of making metarelate a dependency of setup.py at this stage

all built files are under source control and part of the deployment

[pp-mo]

I'm a bit puzzled about the proposal here : Briefly -- why would we want to make the list of recognised standard names depend on Metarelate at all, as neither Iris nor Metarelate seem to actually require it?

If I understand correctly ...

• With the existing method of processing a 'standard' XML file, additions in new editions can be quickly supported in Iris (though not their translation into other metadata formats, of course).
• Under the new proposal, the 'valid names list' is filtered through Metarelate. Hence, any additions provided in newer editions of the 'standard' list will have to be programmed into Metarelate before Iris can incorporate them.
• The existing method is retained as a 'backup' route for non-standard usages.

The existing approach seems perfectly reasonable to me. For instance, in recent work on GRIB i/o extensions (#482), I needed to use recently-added standard names, which were easily incorporated by updating the XML file.

I see that the information in iris.std_names.STD_NAMES presently contains only a name and canonical unit. Also, at least at present, the only use of this in Iris is to check that a name is valid (the units elements aren't referenced anywhere).
So I presume there must be some idea behind this to add additional control information into the STD_NAMES table, which is not currently there (and, presumably, cannot be derived from the XML). But I don't know quite what, as this is not given.

Even if that is the case, I don't think it is clear that this is the obvious approach and a generally good idea : Presumably, any extra per-name information items required could be stored in a separate datastore (as with the various kinds of metadata translation mappings). So it could still prove simpler to retain the existing simple "list of valid names" as a separate concept (which then need not depend on Metarelate).
I don't see how that can logically be a problem, as using standard names as reference keys ought always to be perfectly sensible (as the list of names is defined by CF, hence conflicts can't occur).

[bblay]

the 'valid names list' is filtered through Metarelate.

Convincing arguments, @pp-mo.

[rhattersley]

Closed until re-worked to fit the new plan.