Dear all,
what is this thing about region_names? I only now saw this popping up and must say that I strongly object to adopt these as a standard. Region definitions are so manifold and depend very much on individual applications that I don't see any value in adopting one set of names (here GCMD) and call them "CF region names". In my view this runs completely against what I conceive as the CF philosophy which is trying to be broad and encompass many application areas.
Not only are the names of the regions under dispute, but even more so any definition of their boundaries. For example: for a lake area such as "caspian_sea", do you follow the lake boundaries (and if so in which year?) or do you mean the catchment area including all rivers running into it, or are you referring to a lon/lat rectangle?
I have no problem with a concept that is called "gcmd_regions", for example, if it is detailed somewhere where these definitions come from and how the boundaries are defined. Note that there are indeed various other "prominent" region definitions, for example 6(+1) world regions by WMO, see
https://www.wmo.int/pages/members/index_en.html, or the WMO code table 0161 specifying oceanic areas. But even then, I don't think that this belongs in the CF domain, but instead should be dealt with elsewhere. What CF can do in my opinion is to define suitable attributes how a region (code) and its underlying definition can be provided.
Best regards,
Martin
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Received on Fri Apr 24 2015 - 02:02:25 BST
