[geotk] WKT and TemporalCRS

Aaron Braeckel braeckel at ucar.edu
Mon Dec 6 19:05:13 EST 2010


Just to close the loop on this thread, as we discussed in person in
Exeter it appears that I have no actual need for TemporalCRSs.  Merely
spatial.  I do have the need for parsing GML-defined spatial CRSs, and
possibly parameterized projected CRSs with datum assumptions
(urn:ogc:def:method:EPSG::9802:25:-95:25:25:0:0). 

I have been moved onto other tasks for the moment, but when I get back
to this I think I will first look at the GML parsing capabilities
currently in Geotk.  Parameterized CRSs make potentially dangerous
assumptions about everything except the projected CRS itself.

Just out of curiosity, does Geotk currently have any parameterized CRS
parsing?

Aaron

On 11/16/2010 12:53 PM, Martin Desruisseaux wrote:
> Hello Aaron
>
> Le 16/11/10 18:36, Aaron Braeckel a écrit :
>> just following up on a conversation with Martin today.  I am building
>> a 4-D temporal CRS, writing it out to WKT, and trying to read it back
>> in.  I need to go both ways for my client/server app.  It sounds like
>> the TemporalCRS is not standardized, and there is not currently any
>> WKT reading support for it.  I can think of two options:
>>
>> 1) Decide on a format and implement TemporalCRS support
>> 2) I change courses and use another standardized format (GML or
>> something else) for CRS representations
>>
>> Any thoughts?
> While GML support is definitively on the radar, extending the WKT
> specification to support TemporalCRS is by far much easier than
> providing a full GML support in current Geotoolkit.org implementation.
> What we need however is to agree on a "standard" WKT specification for
> temporal CRS.
>
> The current WKT specification is available there:
>
> http://www.geoapi.org/snapshot/javadoc/org/opengis/referencing/doc-files/WKT.html
>
>
> This specification defines horizontal and vertical CRS, but no
> temporal CRS.
>
> Proposed approach:
>
> 1) Agree on a WKT specification for TemporalCRS on this mailing list.
> 2) Publish the proposal on GeoAPI pending.
> 3) Propose to the OGC to make the updated WKT specification part of
> GeoAPI.
>
> What we need to agree on:
>
> 1) A standard name for TemporalCRS in WKT. I propose "TIME_CS" for
> consistency with the existing "VERT_CS" (WKT uses "CS" for what ISO
> 19111 call "CRS". This disagreement exists for historical reason and I
> think we should follow WKT tradition for new WKT element even if it
> doesn't match ISO 19111 naming).
>
> 2) Standards axis direction for the time axis. I suggest "PAST" and
> "FUTURE".
>
> 3) A syntax for the temporal datum. I suggest something close to the
> existing "VERT_DATUM":
>
> TIME_DATUM["<name>", <epoch>, {,<authority>}]
>
> where <epoch> is the Julian day of the temporal axis origin (the day 0
> in the TIME_CS).
>
> Example of what we may get, for a TemporalCRS where day 0 in January
> 1st, 2000 at miday, and units are days:
>
> TIME_CS["My Temporal CRS",
>     TIME_DATUM["My Temporal Datum", 2451545],
>     UNIT["day"],
>     AXIS["Time", FUTURE]]
>
> Any though on that?
>
>     Regards,
>
>         Martin


More information about the Geotoolkit mailing list