[Requests] OGC Seeks Comments on Candidate GeoAPI 3.0 Interface Standard

Adrian Custer acuster at gmail.com
Sat May 1 08:47:47 EDT 2010

This comment is submitted in response to the GeoAPI 3.0 Interface


1. Evaluator:

        Adrian Vance Custer
        acuster at gmail.com

2. Submission: [OpenGIS Project Document Number, Name]

        GeoAPI Implementation Specification
        OGC 09-083r2


1. Requirement: [General, #] 

        The proposed data types to use for the ISO 19103 Date and ISO
        19103 Time types must be changed from java.util.Date to a new
        Java type.
        Possible alternatives for resolving this issue are declaring two
        new GeoAPI interfaces, mapping to other types from the standard
        Java library, or mapping to data types from a third party

2. Implementation Specification Section number: [General, #]

        Section 8.1.1 Primitive Types

3. Criticality: [Major, Minor, Editorial, etc.]


4. Comments/justifications for changes: [Comments]

        The type java.util.Date is unsuitable to represent the data
        structures required by the ISO 19103 Date and ISO 19103 Time
        types. Specifically it is impossible to represent a particular
        day or a particular time but only possible
        ISO 19103 says: (p15, 19103:2005-07-15)
                A date gives values for year, month, and day. ...
                Character encoding of a date is a string that shall
                follow the format for date specified in ISO 8601.
                A time is given by an hour, minute and second. ...
                Character encoding of a time is a string that follows
                the ISO 8601 format.
        The Java source code documentation for java.util.Date says:
                The class {java.util.}Date represents a specific instant
                in time, with millisecond precision.
        Semantically, these objects have different roles and functions.
        The ISO data types embody representations of time whereas the
        Java type embodies a particular temporal moment. While it is
        possible to represent January 1955 with the ISO types, with the
        Java type one can only represent the first millisecond of
        January 1955. Even worse, it is simply impossible with
        java.util.Date to represent the ISO time 16:20---java.util.Date
        can only represent a four twenty on a particular day. The Java
        type java.util.Date is simply unsuitable for this task as we
        have discovered recently.
        The misnaming and misuse of java.util.Date have long been
        recognized in the Java community so that not reusing the simple
        object from the Java standard library will not prove
        particularly surprising to programmers. Many have moved on to
        use the newer java.util.Calendar data structure or to use the
        widely praised objects from the Joda time library
        GeoAPI could declare new interfaces for these types, which could
        be implemented trivially by backing implementations. These could
        be as simple as:
        public interface Date {
                String getCentury();
                String /*or null*/ getYear();
                String /*or null*/ getMonth();
                String /*or null*/ getDay();
                String toString();//in ISO 8601 format
        public interface Time {
                String getHour();
                String /*or null*/ getMinute();
                String /*or null*/ getSecond();
                String /*or null*/ getTimezone();
                String toString();//in ISO 8601 format
        with the comments being part of the source code documentation
        When constructing these interfaces, it would be worthwhile
        documenting how they can be used to instantiate objects whose
        actual value is undefined. Since both have a field that must
        return a String, a special value (or values) could be used to
        indicate an undefined temporal period for each.
        The great advantage of this approach comes from not imposing on
        any implementation any particular internal data structure. This
        can be important for implementations which use annotations to
        map their data structures into relational databases or into text
        (such as XML).
        Other alternatives are possible but none seems as elegant or
        flexible. Handling time is hard, the advantage of this approach
        comes from addressing exactly what is needed by these ISO data

More information about the Requests mailing list