Hi guys,
sorry for cross-posting, but the topic is of interest for both GeoTools and GeoServer developers.
In the WCS 1.0.0 protocol there’s the possibility to parse an EnvelopeWithTime, i.e. a spatial envelope with a time period or two time positions associated, in order to briefly describe the domain of a spatio-temporal coverage.
My problem is how to handle such a thing at the GeoTools level. What could be the best way to manage the envelopeWithTime? … I thought about two possible ways:
Modify/using/improving the GeneralEnvelope
Create a new EnvelopeWithTime object which extends the GeneralEnvelope
On Wed, 2008-07-02 at 15:22 +0200, Alessio Fabiani wrote:
Hi guys,
sorry for cross-posting, but the topic is of interest for both
GeoTools and GeoServer developers.
In the WCS 1.0.0 protocol there's the possibility to parse an
EnvelopeWithTime, i.e. a spatial envelope with a time period or two
time positions associated, in order to briefly describe the domain of
a spatio-temporal coverage.
My problem is how to handle such a thing at the GeoTools level. What
could be the best way to manage the envelopeWithTime? ... I thought
about two possible ways:
1. Modify/using/improving the GeneralEnvelope
Why would it need to be modified?
Envelopes are very simple conceptually and completely general---it
doesn't matter what your axes are and in what combination they come, if
you have data in some axis space, no matter what the axes mean, you can
define an envelope for that data.
Do remember however:
(1) Envelopes are not bounding
(2) the DirectPositions in the envelope have no intrinsic
meaning, they are merely convenient informatic structure for the
information.
Adrian is right. You don't need to modify GeneralEnvelope. Just gives him a CompoundCRS having a TemporalCRS element. This is what we do on our postgrid side for 5 years.
Adrian is right. You don’t need to modify GeneralEnvelope. Just gives him a CompoundCRS having a TemporalCRS element. This is what we do on our postgrid side for 5 years.
Hi guys,
sorry for cross-posting, but the topic is of interest for both GeoTools and GeoServer developers. In the WCS 1.0.0 protocol there's the possibility to parse an EnvelopeWithTime, i.e. a spatial envelope with a time period or two time positions associated, in order to briefly describe the domain of a spatio-temporal coverage.
My problem is how to handle such a thing at the GeoTools level. What could be the best way to manage the envelopeWithTime? ... I thought about two possible ways:
1. Modify/using/improving the GeneralEnvelope
2. Create a new EnvelopeWithTime object which extends the GeneralEnvelope
Right now we have BoundingBox as a subclass of GeneralEnveloper; you could make EnvelopeWithTime as a subclass of that... and add some methods to get the Range<Date,Date> at the same time.
Right now we have BoundingBox as a subclass of GeneralEnveloper; you could make EnvelopeWithTime as a subclass of that... and add some methods to get the Range<Date,Date> at the same time.
It is possible but I would not recommand that. BoundingBox is really a convenience class assuming X=dimension 0 and Y=dimension 1, which is the kind of assumption that I try very hard to discourage. Code working on GeneralEnvelope with inspection of CRS axes is likely to be more generic.
I noticed that the default implementation of both TemporalCRS and TemporalDatum on GeoTools rely on java.util.Date to store the axis origin and perform the different conversions along with javax.measure.Unit stuff.
I’m wondering if wouldn’t be better to use the temporal schema implementation instead in order to have better aligned code, more coherent conversions and temporal frames and also avoid to convert a posteriori util Dates into opengis Positions, Instants or Periods.
Hi guys,
sorry for cross-posting, but the topic is of interest for both GeoTools and GeoServer developers. In the WCS 1.0.0 protocol there’s the possibility to parse an EnvelopeWithTime, i.e. a spatial envelope with a time period or two time positions associated, in order to briefly describe the domain of a spatio-temporal coverage.
My problem is how to handle such a thing at the GeoTools level. What could be the best way to manage the envelopeWithTime? … I thought about two possible ways:
Modify/using/improving the GeneralEnvelope
Create a new EnvelopeWithTime object which extends the GeneralEnvelope
Right now we have BoundingBox as a subclass of GeneralEnveloper; you could make EnvelopeWithTime as a subclass of that… and add some methods to get the Range<Date,Date> at the same time.
I noticed that the default implementation of both TemporalCRS and TemporalDatum on GeoTools rely on java.util.Date to store the axis origin and perform the different conversions along with javax.measure.Unit stuff.
I'm wondering if wouldn't be better to use the temporal schema implementation instead in order to have better aligned code, more coherent conversions and temporal frames and also avoid to convert a posteriori util Dates into opengis Positions, Instants or Periods.
Yes this is something worth considering. The above-cited implementation methods were wrote before the temporal package has been added to GeoTools. Closer alignment between existing TemporalCRS and temporal package is on my todo list.
On Thu, 2008-07-03 at 02:42 +0200, Jody Garnett wrote:
Alessio Fabiani wrote:
> I thought about two possible ways:
>
> 1. Modify/using/improving the GeneralEnvelope
> 2. Create a new EnvelopeWithTime object which extends the GeneralEnvelope
Right now we have BoundingBox as a subclass of GeneralEnveloper; you
could make EnvelopeWithTime as a subclass of that...
Why? What does that buy you apart from breaking the generality of
Envelope?
Envelopes are neither bounding nor boxes so the subclass is broken by
semantics. Then you want to extend that broken concept to handle a new
axis of a totally different kind, exactly what the parent class was
designed for!? ... it boggles the mind, really. I cannot fathom what's
so confusing about Envelope that it could lead to this kind of thinking.
finally I followed the suggestion of Adrian and Martin which seems to me the most correct.
I was not confused by the Envelope meaning I just wasn’t sure about the GeneralEnvelope meaning and kind of use.
I fully agree with Martin approach, the GeneralEnvelope should reamin as much general as possible.
On Thu, 2008-07-03 at 02:42 +0200, Jody Garnett wrote:
Alessio Fabiani wrote:
I thought about two possible ways:
Modify/using/improving the GeneralEnvelope
Create a new EnvelopeWithTime object which extends the GeneralEnvelope
Right now we have BoundingBox as a subclass of GeneralEnveloper; you
could make EnvelopeWithTime as a subclass of that…
Why? What does that buy you apart from breaking the generality of
Envelope?
Envelopes are neither bounding nor boxes so the subclass is broken by
semantics. Then you want to extend that broken concept to handle a new
axis of a totally different kind, exactly what the parent class was
designed for!? … it boggles the mind, really. I cannot fathom what’s
so confusing about Envelope that it could lead to this kind of thinking.
On Thu, Jul 3, 2008 at 10:33 AM, Martin Desruisseaux
<martin.desruisseaux@anonymised.com> wrote:
Alessio Fabiani a écrit :
I noticed that the default implementation of both TemporalCRS and
TemporalDatum on GeoTools rely on java.util.Date to store the axis
origin and perform the different conversions along with
javax.measure.Unit stuff.
I'm wondering if wouldn't be better to use the temporal schema
implementation instead in order to have better aligned code, more
coherent conversions and temporal frames and also avoid to convert a
posteriori util Dates into opengis Positions, Instants or Periods.
Yes this is something worth considering. The above-cited implementation methods
were wrote before the temporal package has been added to GeoTools. Closer
alignment between existing TemporalCRS and temporal package is on my todo list.
Can you elaborate a bit on this? What are you planning to do, but more
important when?
Alessio and daniele have some time available to spend on these tasks,
hence we would not mind doing some work in order to achieve a closer
integration between referencing and the temporal package.
Simone.
Martin
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
Can you elaborate a bit on this? What are you planning to do, but more
important when?
I don't know yet, because I have not yet looked closely enough to the new temporal package. I'm assuming that when I will do so, I may find redundancy with current TemporalCRS implementation which will need to be resolved.
However I don't think there is any action needed right now. The conversion performed in current TemporalCRS implementation is quite simple (just a very few lines) and so straightforward that disprencies with an other package seems unlikely to me. If we were leveraging the new temporal package right now, it would means promoting it to the referencing module (or making the referencing module dependant on the temporal package), which seems a little bit premature to me.
Ciao Martin,
thanks for the insight. Tomorrow, I will be spending some time with
daniele and alessio to discuss about where we are and where we are
going.
I'll try to report some thoughts afterwards, porbably using gt wiki.
Simone.
On Thu, Jul 3, 2008 at 12:37 PM, Martin Desruisseaux
<martin.desruisseaux@anonymised.com> wrote:
Hello Simone
Simone Giannecchini a écrit :
Can you elaborate a bit on this? What are you planning to do, but more
important when?
I don't know yet, because I have not yet looked closely enough to the new
temporal package. I'm assuming that when I will do so, I may find redundancy
with current TemporalCRS implementation which will need to be resolved.
However I don't think there is any action needed right now. The conversion
performed in current TemporalCRS implementation is quite simple (just a very
few lines) and so straightforward that disprencies with an other package
seems unlikely to me. If we were leveraging the new temporal package right
now, it would means promoting it to the referencing module (or making the
referencing module dependant on the temporal package), which seems a little
bit premature to me.
Martin
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
I am trying to add a shape file using the Feature Type Editor, the map is geocode using the Brtitish National Grid, srs id 27700.
An attempt to use the Lookup SRS button fails with an
"Invalid path was requested /config/data/srsHelp
Clicking on the link SRS Help brings up a page en titled crshelp uri http://geoserver.org/display/GEOS/crshelp that makes refference to an attached zip file, I could not find it
Accessing the thrid and final link 'SRS List' beings up a 404 error, a page not found error, the link it attempts to access is http:127.0.0.1:8080/geoserver/config/data/srcHelp.do, I think it should actual refer to the file 127.0.0.1:8080/geoservers/srsHelp.do
I have attempt to do a little more digging, I eventual discovered called epsg.properties file kept in configration_directory user_projections, it seems to include a list of known projections in a proj4/WKT format. I evnetual added the 27700 listing defined in 127.0.0.1:8080/geoservers/srsHelp.do. After remvoing the settings for AXIS, which thrown up as an error when the file was parsed.
My attempt to set SRS setting to 27700 stil returns an error in the Feature Type Editor page of UNKNOWN, I tried one of the "offical" values, just incase I had screwed up, SRS 900913, this also failed with an UNKOWN value.
This release geoserver-1.6.4b
So questions
1. I think that I have discovered some bugs, ie just some broken links.
2. How do you include a new projection?
