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
<[EMAIL PROT
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 curre
Ciao Martin,
please read below,
On Thu, Jul 3, 2008 at 10:33 AM, Martin Desruisseaux
<[EMAIL PROTECTED]> 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 perfo
Hi all,
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
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
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 o
Hi guys,
I just want to throw in a small observation.
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 b
Jody Garnett a écrit :
> 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 at the same time.
It is possible but I would not recommand that. BoundingBox is really a
convenience class
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,
Okz,
thanks guys.
Cheers,
Alessio.
On Wed, Jul 2, 2008 at 3:58 PM, Martin Desruisseaux <
[EMAIL PROTECTED]> wrote:
> 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 y
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.
Martin
-
Sponsored by: SourceForge.net Commu
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 perio
12 matches
Mail list logo
