here at GeoSolutions we are working towards the implementationof the
org.opengis.temporal interfaces (ISO 19108) in order to propose it as
a possible future GT2 module.
We started from a first implementation made by Alexander Petkov and
continued by adding more features and replacing Date and Time lower
level implemented functionalities with Joda-Time library stuff.
We would like to adopt those APIs for some projects, like the new
ImageIO-ND plugin we are writing, which already supports NetCDF-CF,
HDF and GRIB1 file types and also for the GeoServer W?S temporal
metadata handling.
So … basically what we should do now, is the best way of
marshalling/unmarshalling temporal schema objects.
The GeoServer net.opengis.ows package, and related ones, uses ECore
while GeoTools coverageio stuff uses JAXB. We have not looked deep
into ECore yet, but we used JAXB more than once in the past.
Having the desire to use this stuff with GeoServer as well, what do
you guys think would be the best choice?
here at GeoSolutions we are working towards the implementationof the
org.opengis.temporal interfaces (ISO 19108) in order to propose it as
a possible future GT2 module.
Well... Actually we already started an implementation on our side too. One of our guy has already implemented a fair amount of those class. We have not commited them on GeoTools because I didn't had the time to review them yet, and I'm not sure that the temporal interfaces in GeoAPI are stable (nobody worked on them since Bryce commited them, but we didn't reviewed them neither).
The classes implemented by our guy uses JAXB.
We had a lot of hesitation about JODA vs standard java.util.Calendar. This is well known that Calendar has issues, and JODA is target as the basis of a new time system to appears (maybe) in Java 7. So I'm tempted to wait a little bit in order to see what JODA will looks like in Java 7, in the hope to select only the proper dependencies (even if GeoTools still target Java 5). In the maintime we are building against Calendar, Date and DateFormat.
In the maintime we are building against Calendar, Date and DateFormat.
To be more accurate, the temporal schema is (at least conceptually) somewhat close to referencing. I though that they would live together. Not in the same GeoTools module, but close in the dependencies chain. At this level, the issue of new dependencies tends to be quite sensitive.
Wow that is great news; did you want to CC the geotools list
Alessio Fabiani wrote:
We started from a first implementation made by Alexander Petkov and continued by adding more features and replacing Date and Time lower
level implemented functionalities with Joda-Time library stuff. We would like to adopt those APIs for some projects, like the new ImageIO-ND plugin we are writing, which already supports NetCDF-CF, HDF and GRIB1 file types and also for the GeoServer W?S temporal metadata handling.
So ... basically what we should do now, is the best way of marshalling/unmarshalling temporal schema objects. The GeoServer net.opengis.ows package, and related ones, uses ECore while GeoTools coverageio stuff uses JAXB. We have not looked deep into ECore yet, but we used JAXB more than once in the past.
Having the desire to use this stuff with GeoServer as well, what do you guys think would be the best choice?
You are kind of stuck with both; dependencies ... each has a different value add.
Are you refering to org.eclipse.emf.ecore.xml.type.internal.XMLCalendar? It is marked as "internal" to be repalced with JAXP 1.3 javax.xml.datatype.XMLGregorianCalendar (ie there should not be a conflict between these two).
I am not sure what ECore time representation you are thinking of...
Jody
While we are at it, I should note that date, timestamp, timestamp with TZ handling inside the existing implementation is pretty weak. I have been able to create overriding extensions that behave well enough to support filters and encoding, but a systematic set of test cases in the encoding cases, and per datastore test cases for the weird types that each datastore might provide is required IMHO.
There are also potentially things like forcing the Oracle jdbc driver to behave in a J2EE compliant mode (and return java.sql.Timestamp instead of oracle.sql.Timestamp).
Wow that is great news; did you want to CC the geotools list
Alessio Fabiani wrote:
We started from a first implementation made by Alexander Petkov and
continued by adding more features and replacing Date and Time lower
level implemented functionalities with Joda-Time library stuff. We
would like to adopt those APIs for some projects, like the new
ImageIO-ND plugin we are writing, which already supports NetCDF-CF,
HDF and GRIB1 file types and also for the GeoServer W?S temporal
metadata handling.
So … basically what we should do now, is the best way of
marshalling/unmarshalling temporal schema objects. The GeoServer
net.opengis.ows package, and related ones, uses ECore while GeoTools
coverageio stuff uses JAXB. We have not looked deep into ECore yet,
but we used JAXB more than once in the past.
Having the desire to use this stuff with GeoServer as well, what do
you guys think would be the best choice?
You are kind of stuck with both; dependencies … each has a different
value add.
Are you refering to org.eclipse.emf.ecore.xml.type.internal.XMLCalendar?
It is marked as “internal” to be repalced with JAXP 1.3
javax.xml.datatype.XMLGregorianCalendar (ie there should not be a
conflict between these two).
I am not sure what ECore time representation you are thinking of…
Jody
While we are at it, I should note that date, timestamp, timestamp with TZ handling inside the existing implementation is pretty weak. I have been able to create overriding extensions that behave well enough to support filters and encoding, but a systematic set of test cases in the encoding cases, and per datastore test cases for the weird types that each datastore might provide is required IMHO.
There are also potentially things like forcing the Oracle jdbc driver to behave in a J2EE compliant mode (and return java.sql.Timestamp instead of oracle.sql.Timestamp).
Interesting, so you got patches to improve the situation? Did you provide them to the module maintainers? If not, care to attach each of
them to a jira issue? It would be a pity to see good work lost.
Ciao Martin,
I have suggested to alessio to send the email that started this thread
since I thought that you guys might be working on this as well.
We have started to work on this last week hence we can still try make
plans in order to not duplicate the work, even because as you mention
this work should have a close relationship to referencing.
I would prefer to stick with joda time since we have been using it in
the past and it is a very good library, but anyway we can discuss
about this.
How would you suggesting to proceed?
Simone.
On Fri, May 23, 2008 at 8:01 PM, Martin Desruisseaux
<martin.desruisseaux@anonymised.com> wrote:
Martin Desruisseaux a écrit :
In the maintime we
are building against Calendar, Date and DateFormat.
To be more accurate, the temporal schema is (at least conceptually) somewhat
close to referencing. I though that they would live together. Not in the same
GeoTools module, but close in the dependencies chain. At this level, the issue
of new dependencies tends to be quite sensitive.
While we are at it, I should note that date, timestamp, timestamp with TZ handling inside the existing implementation is pretty weak. I have been able to create overriding extensions that behave well enough to support filters and encoding, but a systematic set of test cases in the encoding cases, and per datastore test cases for the weird types that each datastore might provide is required IMHO.
There are also potentially things like forcing the Oracle jdbc driver to behave in a J2EE compliant mode (and return java.sql.Timestamp instead of oracle.sql.Timestamp).
Interesting, so you got patches to improve the situation? Did you provide them to the module maintainers? If not, care to attach each of
them to a jira issue? It would be a pity to see good work lost.
I will submit patches once I've managed to test them - am having a few build and regression issues with 1.6 I have to get over first.
Regressions on the basic GeoServer modules or in GeoTools?
If you want to nail them down and keep them out once and for all, contribute some unit/functional tests in the affected modules.
