[CF-metadata] Swath observational data
tjn98 wrote:
> Dear All,
>
> I think there may be two distinct cases here:
>
> 1) Local cross-referencing, where it is only necessary to establish
> a relationship within a well-defined grouping of files,
>
> 2) Referencing to a universal resource, such as a specific file
> held on a server.
>
> For the former, it should only be necessary that every NetCDF file
> within the grouping holds the same unique identifier (this could
> be the product or group name, or an ID string from a managed soure).
> Satellite swath products, where they have this sort of structure,
> almost always fall in the first category. In general, a user would
> want to use his or her local copy of a file, rather than re-download
> a remote file.
>
> This may be redundant by now, but my thoughts were that:
>
> 1) We only consider whether we can extend cross-referencing within
> a local scope,
>
> 2) All related files within the scope should contain the same unique
> identifier, perhaps a global attribute named something like
> ?cross_reference_ID?.
>
> 3) Referenced variable names within the scope should be unique and so
> do not need modifiers. An alternative is that modifiers are not
> needed in references by default, but could be included to
> disambiguate variables - perhaps in a form like ?geo:latitude?
> where geo.nc is the file containing the required latitude variable.
>
> If the attribute contains an empty string or is absent, CF compliant
> systems only look for referenced variables within the same file, as
> at the moment. If present, the system is allowed to search other files
> within a limited scope, containing the same ID.
>
> One possibility is that scope could be modified with, perhaps,
> unix-like relative directory prefixes to the ID, so that
>
> :cross_reference_ID = ?my_unique_id?;
>
> refers just to to files in the same directory, whereas
>
> :cross_reference_ID = ?../*/my_unique_id?;
>
> refers to all files held under the parent directory and its
> subdirectories, and so on.
>
> If the purpose of the ID is only to disambiguate local files, then
> form and integrity of the ID string itself could probably be left
> to the discretion of the data provider, since it would only need to
> be checked within a defined scope. More rigorous implementations
> are a bit beyond my experience.
>
> Anybody who?s interested can find the SAFE format definition at
> earth.esa.int/SAFE. You should probably enjoy UML diagrams to
> appreciate it fully. Note that the format doesn?t discuss NetCDF
> in particular ? this is just the format that Sentinel-3 is adopting
> for its data containers.
>
> Tim.
Hi Tim:
The only thing i saw in SAFE was referencing an absolute path HTTP URL. Do you know if there's anything more along the lines you are suggesting?
Received on Sun Nov 22 2009 - 18:27:27 GMT
This archive was generated by hypermail 2.3.0
: Tue Sep 13 2022 - 23:02:41 BST