Dear All,
Another refernce source for CRS is the European Petroleum Survey Group (EPSG -
http://www.epsg.org) database which seems to be the first port of call for anybody in the European marine community with a detailed interest in surveying such as bathymetrists and sea level specialists. I'm not sure what the relationship there is between EPSG, OGC and ISO but there appears to be a linkage with some of the same players involved in EPSG and TC211 processes.
Cheers, Roy.
>>> CJ Beegle-Krause <Cj.Beegle-Krause at noaa.gov> 2/20/2007 10:06 pm >>>
Hello Karl, Phil, Jonathan and others
From my perspective (use case: emergency response) more an more
information is being collected and made available with increasing levels
of sophistication on coordinate system. Resource information from human
census, to biological resources, shoreline, etc. all are being mapped
with more and more accuracy. I support the Open Geospatial Consortium
(OGC) (
http://www.opengeospatial.org/) as the place to start for
connecting the CF process to georeferenced data, as both groups have
similar community goals. Other options are to utilize the ESRI GIS
products selection list for coordinate system attributes. Or point
directly to ISO/TC211 (
http://www.isotc211.org/).
Models have different levels of idealization, and it's important to make
space for highly idealized climate models alongside those that are
coastal scale and intended to serve societal needs on smaller length and
time scales. The shorter the time and length scale of the model
prediction, the more accurate the model position needs to be and the
more geospatially accurate the comparison information is likely to be.
The increasing push to make science serve society means that models must
relate to what people understand and care about.
Creating and streamlining a connection between the CF standards and the
OGC standards will facilitate utilization of information by more users.
Best regards,
CJ
Karl Taylor wrote:
>Dear Phil et al.,
>
>I too know very little about this, but as far as I know:
>
>1) observational datasets used to evaluate model simulations also don't
>supply this information.
>
>2) As Jonathan, says models are idealized. They also sometimes rely on
>an idealized calendar (e.g., assuming each year comprises twelve 30-day
>months). We have allowed for this in the CF convention. Perhaps, we
>should also allow for this in specifying the "datum" by simply
>indicating an idealized earth shape?
>
>3) As we move to higher and higher resolution, the issue will certainly
>become of more concern, so it's good we think about this now.
>
>I second Jonathan's plea for some experts to weigh in.
>
>cheers,
>Karl
>
>
>Jonathan Gregory wrote:
>
>
>>Dear Phil
>>
>>
>>
>>>non-geodesist interpretation of a geodetic datum is that it defines the
>>>mapping of a Coordinate System (such as latitude-longitude) onto a
>>>particular figure of the earth within a given reference frame, thus
>>>providing a Coordinate Reference System.
>>>
>>>
>>That sounds similar to my interpretation (that it defines an ellipsoid).
>>
>>
>>
>>>Although a spherical earth approximation may be appropriate for many
>>>climate applications, I guess there may be plenty of situations where
>>>meteorological datasets are actually referenced to a non-spherical
>>>earth, e.g. met observations referenced against the popular WGS 1984
>>>datum/ellipsoid. In such cases I would have thought that the geodetic
>>>datum information ought indeed to be captured.
>>>
>>>
>>Yes, if the dataset had one, but I'm sure that most lat-lon meteorological
>>datasets (the ones I've come across, anyway) do not specify their datum.
>>They may have been gridded from obs, or they may provide obs on whatever
>>lat-lon system the country concerned uses. That implies a kind of mixture, I
>>suppose, which is OK because the differences don't matter for the purposes for
>>which the dataset is intended. But I really don't know about this. I'm sure
>>someone on the conventions committee must be an expert! For climate model
>>output the datum is genuinely undefined since the world is idealised.
>>
>>
>>
>>>As regards the content and structure of a potential 'geodetic_datum'
>>>grid mapping attribute, would a solution be to adopt the well-known text
>>>format devised by the Petrotechnical Open Standards Consortium (POSC)
>>>and since adopted by the Open Geospatial Consortium (OGC). In Backus-
>>>Naur Form this looks thus:
>>>
>>><datum> ::=
>>> DATUM [ "<name>", <spheroid>
>>> {, <shift-x>, <shift-y>, <shift-z>, <rot-x>, <rot-y>, <scale-
>>>adjust> }
>>> ]
>>>
>>><spheroid> ::=
>>> SPHEROID ["<name>", <semi-major-axis>, <inverse-flattening>]
>>>
>>>And so the WGS 1984 datum example might then look something like:
>>>
>>>DATUM [ "World Geodetic System 1984" SPHEROID ["WGS 1984", 6378137.00
>>>298.257223563 ] ]
>>>
>>>
>>This looks promising. To make it more self-describing and easier to use I
>>suggest we might put those elements of the definition in separate attributes.
>>Is it really that simple though? I would have expected more numbers: perhaps
>>that's what the <shift>s and <rot>s are.
>>
>>My ignorance of this is all too obvious. To proceed we need expertise and
>>use-cases.
>>
>>Cheers
>>
>>Jonathan
>>_______________________________________________
>>CF-metadata mailing list
>>CF-metadata at cgd.ucar.edu
>>http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>>
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
CJ Beegle-Krause, Ph.D.
NOAA/NOS/ORR/Hazmat
7600 Sand Point Way NE
Seattle, WA 98115
voice: (206) 526-6961
fax: (206) 526-6329
<:}}}}}><
<:}}}}}><
\!/ \!/ \!/ >^<**>^< \!/ \!/ \!/
--
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.
Received on Wed Feb 21 2007 - 04:09:31 GMT
