Re: [CF-metadata] standard names for stations
Dear Nan, John, Jeff I think variable attributes are generally better than global attributes, because it's possible or indeed likely that you might have data from different sources in the same file. I prefer data variables to describe themselves. We can provide global attributes as a default for the whole file, but it seems safer to me to repeat the attributes per variable. Following John's point, I agree that this station ID information will not be usable by machine or guaranteed to be unique unless we standardise it in some way. I don't know about this subject, but I am sure there are people who are well-informed about it! If we want the station ID attribute(s) to be machine- readable, we can propose a standard format for them. If we want an attr where the data-writer can informally record ID information that another human could interpret, we don't need a standard format. Which do we want - any views? Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
Hi Jonathan, My vote would go to something that is both human and machine-readable. There are standards designed for this such as JSON. Some might consider this comes down on the side of the machine more than the human, but I find once I get my in I can read JSON much easier than XML. If this is considered to be going over the top then we need to at least specify the order in which the component parts of the string are included and preferably we should specify a delimiter to separate the components. Even an ultra-light standard such as this makes the life of any programmer writing code to parse the string infinitely easier. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 16 September 2011 15:32 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] standard names for stations Dear Nan, John, Jeff I think variable attributes are generally better than global attributes, because it's possible or indeed likely that you might have data from different sources in the same file. I prefer data variables to describe themselves. We can provide global attributes as a default for the whole file, but it seems safer to me to repeat the attributes per variable. Following John's point, I agree that this station ID information will not be usable by machine or guaranteed to be unique unless we standardise it in some way. I don't know about this subject, but I am sure there are people who are well-informed about it! If we want the station ID attribute(s) to be machine- readable, we can propose a standard format for them. If we want an attr where the data-writer can informally record ID information that another human could interpret, we don't need a standard format. Which do we want - any views? Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
For what it is worth, we migrated a lot of our systems metadata and config to JSON and it works like a charm. The primary reason was to enable humans and computers to co exist better. We tried XML but JSON won the day for us. Regards Pk - Original Message - From: cf-metadata-boun...@cgd.ucar.edu cf-metadata-boun...@cgd.ucar.edu To: Jonathan Gregory j.m.greg...@reading.ac.uk; cf-metadata@cgd.ucar.edu cf-metadata@cgd.ucar.edu Sent: Fri Sep 16 23:13:56 2011 Subject: Re: [CF-metadata] standard names for stations Hi Jonathan, My vote would go to something that is both human and machine-readable. There are standards designed for this such as JSON. Some might consider this comes down on the side of the machine more than the human, but I find once I get my in I can read JSON much easier than XML. If this is considered to be going over the top then we need to at least specify the order in which the component parts of the string are included and preferably we should specify a delimiter to separate the components. Even an ultra-light standard such as this makes the life of any programmer writing code to parse the string infinitely easier. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 16 September 2011 15:32 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] standard names for stations Dear Nan, John, Jeff I think variable attributes are generally better than global attributes, because it's possible or indeed likely that you might have data from different sources in the same file. I prefer data variables to describe themselves. We can provide global attributes as a default for the whole file, but it seems safer to me to repeat the attributes per variable. Following John's point, I agree that this station ID information will not be usable by machine or guaranteed to be unique unless we standardise it in some way. I don't know about this subject, but I am sure there are people who are well-informed about it! If we want the station ID attribute(s) to be machine- readable, we can propose a standard format for them. If we want an attr where the data-writer can informally record ID information that another human could interpret, we don't need a standard format. Which do we want - any views? Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
Heres a few comments on this discussion from my POV: 1) to summarize whats already in CF1.6: section A9.2: It is strongly recommended that there should be a station variable (which may be of any type) with the attribute cf_role=”timeseries_id”, whose values uniquely identify the stations. It is recommended that there should be station variables with standard_name attributes station_description, surface_altitude and “station_wmo_id” when applicable. Since surface_altitude already exists, the other two are called out at the end: New standard names to be added to the standard name table - station_description : variable of character type containing a description of a time series station - station_wmo_id : variable of character or integer type, containing the WMO identifier of an observing station (i dont see this last part on the web site at http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6 so here is the final version in pdf for reference: http://www.unidata.ucar.edu/staff/caron/public/CFch9-may10.pdf note that this is not a draft, but been accepted for 1.6. However, we can always amend and extend it for 1.7.) 2) the NetCDF Attribute Convention for Dataset Discovery is at http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html but doesnt have anything about stations. it does have a naming authority which was intended to create globally unique dataset ids 3) the attribute cf_role=”timeseries_id” has the same effect as a standard name. our intention was to start to separate structural meatdata vs naming physical quantities via standard names. so cf_role=”timeseries_id” indicates a unique identifier for the station. 4) There is an important wrinkle introduced in 1.6 wrt the global vs variable attributes. The info for a particular station is associated by way of the station dimension, and all variables with just that dimension are station variables. The set of variables for a station are also associated by various mechanism involving dimensions. So: 1. any metadata intended to describe the station should be a station variable or an attribute on a station variable. 2. if the data, for example, came from multiple instruments, you might want to annotate the variables with that info, understanding that the variable is already associated with a specific station and must be consistent. 5) Generally i like the idea of richer metadata for stations and platforms etc, and a naming authority is a really good idea. In service of Getting Things Done, i would recommend that we agree on something that works for human readable metadata, and then start to experiment with machine readable versions, eg JSON. whether the naming authority is part of the name or not is a bit of style, but ill say that i like it. 6) So what would be helpful would be to start with the existing new things in 1.6: 1) station variable (which may be of any type) with the attribute cf_role=”timeseries_id”, whose values uniquely identify the stations. 2) station variable with standard_name station_description 3) station variable with standard_name “station_wmo_id” and propose clarification and extensions to that. The concrete proposal has come from Jeffery, so perhaps he wants to revise it based on feedback so far and propose another reversion? ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
Dear Jeff platform_primary_id: variable of character type containing an ID or name of an observing station or other platform platform_primary_id_authority: variable of character type, specifying the naming authority or system used to choose platform_primary_id platform_secondary_id: variable of character type containing a second ID or name of an observing station or other platform. platform_primary_id must be present. platform_secondary_id_authority: variable of character type, specifying the naming authority or system used to choose platform_secondary_id platform_description: variable of character type which describes an observing station or other platform I think these are OK, thanks. Still, I'd like to suggest something different - not necessarily arguing for it, but just as an idea. The authority seems to be metadata about metadata i.e. you can't understand the ID without the authority. If that is so, could we put the authority and the ID in the same string e.g. WMO station id 03808? Since we're not standardising the format of the ID and authority strings, I don't these attributes could be processed automatically anyway, so really they are a long_name for the platform. Again, if they are not standardised, why not put primary, second (and any other) IDs all in the same string? Unless we have standard rules for the contents and purposes of the various attributes to make sure they are used consistently, I am not sure it helps to split up the information in this way. Perhaps this would be just as good: platform_name=cambourne platform_id=wmo station id 03808, midas station number 1395 Probably there are good arguments against this which I have missed, and people may have good use cases for separate attributes. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
Refining Jonathan's point, though I too would accept the original: I like the concept of merging, though merging the authority and the ID per the example makes it more likely that only a human can process the identifier (where does the authority stop and the identifier start?). The world of the web is moving toward open linked data, and it would be nice to enable that wherever possible. It seems useful if the user can be sure the ID is really an ID, meaning unique and unambiguous, but this is hard if the format isn't precisely specified. (Is '001' a different ID than '1'? Not clear.) One way to put the authority into the ID string and maintain an identifier that is verifiable is to use (require) URIs. This guarantees uniqueness, precise authority determination, and computability in a way that a string like wmo station id 03808 can not. (With some URI types dereferencing is also possible, but maybe we don't want to go so far as all that!) Yes, this enforces some (fairly trivial) work on the provider. But only on those providers who already think providing a unique platform identification is important, so I think they would be receptive to this approach. These may be comments to be made to NACDD/UDDC as well, but if CF is going to recommend an approach, it may provide an opportunity to make it maximally effective. john On Sep 15, 2011, at 06:25, Jonathan Gregory wrote: Dear Jeff platform_primary_id: variable of character type containing an ID or name of an observing station or other platform platform_primary_id_authority: variable of character type, specifying the naming authority or system used to choose platform_primary_id platform_secondary_id: variable of character type containing a second ID or name of an observing station or other platform. platform_primary_id must be present. platform_secondary_id_authority: variable of character type, specifying the naming authority or system used to choose platform_secondary_id platform_description: variable of character type which describes an observing station or other platform I think these are OK, thanks. Still, I'd like to suggest something different - not necessarily arguing for it, but just as an idea. The authority seems to be metadata about metadata i.e. you can't understand the ID without the authority. If that is so, could we put the authority and the ID in the same string e.g. WMO station id 03808? Since we're not standardising the format of the ID and authority strings, I don't these attributes could be processed automatically anyway, so really they are a long_name for the platform. Again, if they are not standardised, why not put primary, second (and any other) IDs all in the same string? Unless we have standard rules for the contents and purposes of the various attributes to make sure they are used consistently, I am not sure it helps to split up the information in this way. Perhaps this would be just as good: platform_name=cambourne platform_id=wmo station id 03808, midas station number 1395 Probably there are good arguments against this which I have missed, and people may have good use cases for separate attributes. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata John Graybeal mailto:jgrayb...@ucsd.edu phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
Since we're storing station information in a variable, would it be more normal to use variable attributes for naming authority, description, and (optionally) naming_authority_reference (for URLS)? Also, I have to admit that it might be going overboard to have a standard name or set of standard names for secondary ids; we got into this discussion because of a need for a station name for the draft version 1.6 of the CF Conventions manual, and maybe we've gone a bit too far beyond the original need. For example, the OceanSITES project uses an id AND a WMO number, but there does not seem to me to be a need for these to be variables - either one or both can be a global attribute. In general, standards seem to be calling for more general metadata to be stored as a global attribute rather than (or in addition to) being a data variable; time and location extents are one example. So this proposal is going in the opposite direction - I wonder if we could just make a minor change to the draft 1.6 and store station as a required attributes? Nan On 9/15/11 6:25 AM, Jonathan Gregory wrote: Dear Jeff platform_primary_id: variable of character type containing an ID or name of an observing station or other platform platform_primary_id_authority: variable of character type, specifying the naming authority or system used to choose platform_primary_id platform_secondary_id: variable of character type containing a second ID or name of an observing station or other platform. platform_primary_id must be present. platform_secondary_id_authority: variable of character type, specifying the naming authority or system used to choose platform_secondary_id platform_description: variable of character type which describes an observing station or other platform I think these are OK, thanks. Still, I'd like to suggest something different - not necessarily arguing for it, but just as an idea. The authority seems to be metadata about metadata i.e. you can't understand the ID without the authority. If that is so, could we put the authority and the ID in the same string e.g. WMO station id 03808? Since we're not standardising the format of the ID and authority strings, I don't these attributes could be processed automatically anyway, so really they are a long_name for the platform. Again, if they are not standardised, why not put primary, second (and any other) IDs all in the same string? Unless we have standard rules for the contents and purposes of the various attributes to make sure they are used consistently, I am not sure it helps to split up the information in this way. Perhaps this would be just as good: platform_name=cambourne platform_id=wmo station id 03808, midas station number 1395 Probably there are good arguments against this which I have missed, and people may have good use cases for separate attributes. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
Suggest variable of character type containing a unique identifier (may be numeric, name, or URI) of an observing station or platform Because the primary_id has to be unique to be a useful ID. I could tolerate duplicate names for the secondary ID, personally. And 'observing station or other platform' implied observing station IS a platform, but some observing stations (M1 at MBARI) are conceptual, being populated by a sequence of actual physical platforms. Otherwise, I like. Also is smart to let the practice of specifying the authority evolve. Sooner or later we'll have a formal vocabulary, *then* CF can be modified to insist upon the formal vocabulary, if there is support for that. (You could specify the naming authority for the vocabulary used to specify the naming authority ... ;-) John On Sep 14, 2011, at 16:25, Jeffrey F. Painter wrote: Here's another attempt to meet everyone's criteria. Any comments? platform_primary_id: variable of character type containing an ID or name of an observing station or other platform platform_primary_id_authority: variable of character type, specifying the naming authority or system used to choose platform_primary_id platform_secondary_id: variable of character type containing a second ID or name of an observing station or other platform. platform_primary_id must be present. platform_secondary_id_authority: variable of character type, specifying the naming authority or system used to choose platform_secondary_id platform_description: variable of character type which describes an observing station or other platform Regarding the change from (platform_name, platform_id) to (platform_primary_id, platform_secondary_id): Character IDs seem to be common, and Jonathan suggested that numeric IDs wouldn't really be treated as numbers. So I think it makes sense to use only character type. But we still need two of them, per Nan's comment. With two IDs we need two naming authorities. I purposely didn't try to write detailed specifications of how to express the naming authority or format the description. I think there's no hope of getting a consensus on that until we have at least settled on the names. - Jeff On 9/6/11 6:29 AM, Schultz, Martin wrote: Date: Wed, 31 Aug 2011 10:33:26 +0100 From: Jonathan Gregoryj.m.greg...@reading.ac.uk Subject: Re: [CF-metadata] standard names for stations Dear Nan Do we need to specify whether the _id is numeric or character? I'd prefer to leave that to the user and his code. Yes, I think we have to specify this for standard_names; in the standard name table, all of them are either assigned units = numeric, or stated to be string. Of course, a number can be written in a string, and maybe that's the right thing to do if this variable would never be processed as a number. Best wishes Jonathan Dear Jonathan, ... but strings may be formatted differently. 001 is not the same as 1 or 01. I think you are right about using strings instead of numbers (if sometimes the ID can actually be a string), but someone (in the user community) then needs to define the formatting of number IDs. Martin Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata John Graybeal mailto:jgrayb...@ucsd.edu phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations (Jonathan Gregory)
Date: Wed, 31 Aug 2011 10:33:26 +0100 From: Jonathan Gregory j.m.greg...@reading.ac.uk Subject: Re: [CF-metadata] standard names for stations Dear Nan Do we need to specify whether the _id is numeric or character? I'd prefer to leave that to the user and his code. Yes, I think we have to specify this for standard_names; in the standard name table, all of them are either assigned units = numeric, or stated to be string. Of course, a number can be written in a string, and maybe that's the right thing to do if this variable would never be processed as a number. Best wishes Jonathan Dear Jonathan, ... but strings may be formatted differently. 001 is not the same as 1 or 01. I think you are right about using strings instead of numbers (if sometimes the ID can actually be a string), but someone (in the user community) then needs to define the formatting of number IDs. Martin Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
Dear Nan Do we need to specify whether the _id is numeric or character? I'd prefer to leave that to the user and his code. Yes, I think we have to specify this for standard_names; in the standard name table, all of them are either assigned units = numeric, or stated to be string. Of course, a number can be written in a string, and maybe that's the right thing to do if this variable would never be processed as a number. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
On 8/27/11 5:10 AM, Lowry, Roy K. wrote: I would suggest some fine tuning of this to: platform_name platform_id (note this needs to be alphanumeric to support ICES ship codes widely used in oceanography) platform_id_authority (mandatory if platform_id present) platform_description I wonder if the concept of authority is relevant to names - who is the authority for a ship's name? Even if relevant, there is no guarantee that the authority will be the same as the platfom_id and somebody will want to include both a name and an id. If people feel that a name authority is required then I would label it platform_name_authority rather than having one name doing two jobs. Agreed - multiple authorities are needed. Our buoys have a platform_name conferred by OceanSITES and, usually, a WMO platform_id as well. Naming_authority seems to me to be especially important for ships' names; the 'authority' could be any body that maintains, or, preferably serves, a list of these names in a standard form. That would enable us to e.g. equivalence R.V. Ronald H. Brown and brown. Do we need to specify whether the _id is numeric or character? I'd prefer to leave that to the user and his code. The nature of the platform dscription merits a little discussion. Controlled terms, particularly if accompanied by definitions, are always much more helpful than plaintext. There is an internationally-governed platform type vocabulary used in the SeaDataNet and ICES systems (http://vocab.ndg.nerc.ac.uk/list/L06). There is also at least one relevant WMO vocabulary (VOS types). This is another good resource; thanks, Roy. If formalisation of the description is agreed then we could either keep 'platform_description' for plaintext and add 'platform_type' plus 'platform_type_authority' or standardise 'platform_description' by adding 'platform_description_authority'. Finally, I think we need to agree how an authority is represented. My choice would be a namespace URL, but maybe there are other ideas. I'd have thought something like 'WMO' or SeaDataNet would be enough, but ... maybe not. We really don't want to get into needing to use a platform_id_authority_authority. On the other hand, if it's got to be a namespace URL, I sincerely hope it's allowed to, or required to, be human-readable. It won't go well if my platform_id is 372224 and my platform_id_authority is a url ending in term/P00/4/41. My CF files are written by human-generated code, and I like the CDL files to convey meaning to humans as well. Maybe put the URL in yet another field, platform_id_authority_reference? Cheers - Nan From: ...Jeffrey F. Painter [paint...@llnl.gov] Sent: 27 August 2011 01:27 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] standard names for stations It seems to me that we would need four standard_names to satisfy everyone's needs. How does this sound? platform_name: variable of character type containing a character ID or name of an observing station or other platform platform_id: variable of integer type, identifying an observing station or other platform platform_naming_authority: variable of character type, specifying the naming authority or system used to choose a platform_id or platform_name platform_description: variable of character_type which describes an observing station or other platform A typical station would have a platform_name or platform_id, but rarely both. The reason for having both is that I expect that the numerical WMO identifiers (of various lengths) will be used very frequently, and it can be helpful to represent numbers as numbers. But Eiji's message shows that we must allow for character identifiers. A relatively short character identifier would have a different function from the kind of long description suggested by Øystein. The most common platform_naming_authority would be the originally conceived WMO, of course. - Jeff On 8/26/11 12:36 AM, Øystein Godøy wrote: Date: Wed, 24 Aug 2011 16:26:55 -0700 From: Jeffrey F. Painterpaint...@llnl.gov Subject: [CF-metadata] standard names for stations To: cf-metadatacf-metadata@cgd.ucar.edu Message-ID:4e5588bf.2090...@llnl.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed The draft version 1.6 of the CF Conventions manual recommends use of two standard names which don't exist yet but are needed to describe discrete data such as observations from stations or other discrete points. So I'd like to propose the following two standard names: - station_description : variable of character type containing a description of a time series station - wmo_platform_id : variable of integer type, containing the WMO identifier of an observing station or other platform - Jeff Painter Hi, I clearly see the need for this. Concerning station_description, I think this is useful whether it is a time series or not. There is a need to describe the actual location for the station. E.g. describe
Re: [CF-metadata] standard names for stations
Dear All, I would suggest some fine tuning of this to: platform_name platform_id (note this needs to be alphanumeric to support ICES ship codes widely used in oceanography) platform_id_authority (mandatory if platform_id present) platform_description I wonder if the concept of authority is relevant to names - who is the authority for a ship's name? Even if relevant, there is no guarantee that the authority will be the same as the platfom_id and somebody will want to include both a name and an id. If people feel that a name authority is required then I would label it platform_name_authority rather than having one name doing two jobs. The nature of the platform dscription merits a little discussion. Controlled terms, particularly if accompanied by definitions, are always much more helpful than plaintext. There is an internationally-governed platform type vocabulary used in the SeaDataNet and ICES systems (http://vocab.ndg.nerc.ac.uk/list/L06). There is also at least one relevant WMO vocabulary (VOS types). If formalisation of the description is agreed then we could either keep 'platform_description' for plaintext and add 'platform_type' plus 'platform_type_authority' or standardise 'platform_description' by adding 'platform_description_authority'. Finally, I think we need to agree how an authority is represented. My choice would be a namespace URL, but maybe there are other ideas. Cheers, Roy. From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jeffrey F. Painter [paint...@llnl.gov] Sent: 27 August 2011 01:27 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] standard names for stations It seems to me that we would need four standard_names to satisfy everyone's needs. How does this sound? platform_name: variable of character type containing a character ID or name of an observing station or other platform platform_id: variable of integer type, identifying an observing station or other platform platform_naming_authority: variable of character type, specifying the naming authority or system used to choose a platform_id or platform_name platform_description: variable of character_type which describes an observing station or other platform A typical station would have a platform_name or platform_id, but rarely both. The reason for having both is that I expect that the numerical WMO identifiers (of various lengths) will be used very frequently, and it can be helpful to represent numbers as numbers. But Eiji's message shows that we must allow for character identifiers. A relatively short character identifier would have a different function from the kind of long description suggested by Øystein. The most common platform_naming_authority would be the originally conceived WMO, of course. - Jeff On 8/26/11 12:36 AM, Øystein Godøy wrote: Date: Wed, 24 Aug 2011 16:26:55 -0700 From: Jeffrey F. Painterpaint...@llnl.gov Subject: [CF-metadata] standard names for stations To: cf-metadatacf-metadata@cgd.ucar.edu Message-ID:4e5588bf.2090...@llnl.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed The draft version 1.6 of the CF Conventions manual recommends use of two standard names which don't exist yet but are needed to describe discrete data such as observations from stations or other discrete points. So I'd like to propose the following two standard names: - station_description : variable of character type containing a description of a time series station - wmo_platform_id : variable of integer type, containing the WMO identifier of an observing station or other platform - Jeff Painter Hi, I clearly see the need for this. Concerning station_description, I think this is useful whether it is a time series or not. There is a need to describe the actual location for the station. E.g. describe the surface, horizon, and other aspects that may affect the observations. Concerning wmo_platform_id, I think Nan Galbraiths suggestion using an id and a naming authority is useful and more flexible than specifying a WMO reference directly. Concerning my institution, all stations operated by us, whether being WMO stations or not, always have an internal ID. Not all stations have a WMO id. It may even be useful to be able to use multiple ids for stations to cover situations like the one I mention. NACCD is good but it does not have the momentum that CF has. Many other such discovery conventions for NetCDF files exist and are used, most of course differing only slightly. I believe they will merge in time, but for now I think NACDD is less used than CF. I certainly agree it should be promoted (and we will probably move towards it), but these things take time. Thus I would prefer put as much information as possible as CF-compliant variables in the dataset, even if it means duplicating them as global attributes for discovery purposes. All the best Øystein
Re: [CF-metadata] standard names for stations
Date: Wed, 24 Aug 2011 16:26:55 -0700 From: Jeffrey F. Painter paint...@llnl.gov Subject: [CF-metadata] standard names for stations To: cf-metadata cf-metadata@cgd.ucar.edu Message-ID: 4e5588bf.2090...@llnl.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed The draft version 1.6 of the CF Conventions manual recommends use of two standard names which don't exist yet but are needed to describe discrete data such as observations from stations or other discrete points. So I'd like to propose the following two standard names: - station_description : variable of character type containing a description of a time series station - wmo_platform_id : variable of integer type, containing the WMO identifier of an observing station or other platform - Jeff Painter Hi, I clearly see the need for this. Concerning station_description, I think this is useful whether it is a time series or not. There is a need to describe the actual location for the station. E.g. describe the surface, horizon, and other aspects that may affect the observations. Concerning wmo_platform_id, I think Nan Galbraiths suggestion using an id and a naming authority is useful and more flexible than specifying a WMO reference directly. Concerning my institution, all stations operated by us, whether being WMO stations or not, always have an internal ID. Not all stations have a WMO id. It may even be useful to be able to use multiple ids for stations to cover situations like the one I mention. NACCD is good but it does not have the momentum that CF has. Many other such discovery conventions for NetCDF files exist and are used, most of course differing only slightly. I believe they will merge in time, but for now I think NACDD is less used than CF. I certainly agree it should be promoted (and we will probably move towards it), but these things take time. Thus I would prefer put as much information as possible as CF-compliant variables in the dataset, even if it means duplicating them as global attributes for discovery purposes. All the best Øystein -- Dr. Oystein Godoy Norwegian Meteorological Institute P.O.BOX 43, Blindern, N-0313 OSLO, Norway Ph: (+47) 2296 3000 (switchb) 2296 3334 (direct line) Fax:(+47) 2296 3050 Institute home page: http://met.no/ ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
There is also a 'station_name' as recommended attribute in a discrete geometries section, see http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/aphs02.html/ and even more info on the station (like station_info anf station_elevation) in the Example H.3. Timeseries of station data Greetings, Renata Renata McCoy PCMDI/ LLNL, (925) 424-5237, ren...@llnl.gov On Aug 25, 2011, at 5:50 AM, Jonathan Gregory wrote: Dear Jeff I think this one is fine - wmo_platform_id : variable of integer type, containing the WMO identifier of an observing station or other platform For this one - station_description : variable of character type containing a description of a time series station I now wonder what we mean by description. What is probably expected is a geographical location of some sort, isn't it. Could we call it station_name? Like long_name and standard_name, it could still be several words. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names for stations
Dear Colleagues, I guess you are talking about five-digit number to identify stations in SYNOP or TEMP. Please note that the number is called station index number in WMO. There are several other systems of symbol to identify observation platforms in WMO: - moored and fixed buoys have different number system - GAW (Global Atmosphere Watch) stations uses three-letter code http://gaw.empa.ch/gawsis/ Best Regards, -- Eizi TOYODA (aka Eiji) - Original Message - From: Jeffrey F. Painter To: Renata McCoy ; cf-metadata Sent: Friday, August 26, 2011 1:34 AM Subject: Re: [CF-metadata] standard names for stations good point - The auxiliary coordinate variable station_name in these examples is missing a standard_name; and indeed station_description or station_name would fit the bill. I'd be happy with either or both. For that matter, if one of the stations in the examples had a WMO ID, then it would also need a variable wmo_platform_id (btw, that's a name change from the text's station_wmo_id) The example variable station_info also has no standard_name, but the example variable station_elevation already has one. - Jeff On 8/25/11 8:47 AM, Renata McCoy wrote: There is also a 'station_name' as recommended attribute in a discrete geometries section, see http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/aphs02.html/ and even more info on the station (like station_info anf station_elevation) in the Example H.3. Timeseries of station data Greetings, Renata Renata McCoy PCMDI/ LLNL, (925) 424-5237, ren...@llnl.gov On Aug 25, 2011, at 5:50 AM, Jonathan Gregory wrote: Dear Jeff I think this one is fine - wmo_platform_id : variable of integer type, containing the WMO identifier of an observing station or other platform For this one - station_description : variable of character type containing a description of a time series station I now wonder what we mean by description. What is probably expected is a geographical location of some sort, isn't it. Could we call it station_name? Like long_name and standard_name, it could still be several words. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] standard names for stations
The draft version 1.6 of the CF Conventions manual recommends use of two standard names which don't exist yet but are needed to describe discrete data such as observations from stations or other discrete points. So I'd like to propose the following two standard names: - station_description : variable of character type containing a description of a time series station - wmo_platform_id : variable of integer type, containing the WMO identifier of an observing station or other platform - Jeff Painter ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
