Hi all,
On Mon, Jul 28, 2008 at 11:23 AM, Martin Desruisseaux <
[EMAIL PROTECTED]> wrote:
> Hello Alessio
>
> I was away for the weekend, sorry for being late.
>
>
> Alessio Fabiani a écrit :
> > First of all, correct me if I'm wrong, but I don't see ways to handle
> > the time yet.
>
> We do handle time... We just don't need to make a special metadata for
> them.
> Time is a dimension like any other. We need to make sure that the CRS is a
> compound CRS containing a TemporalCRS, and the Envelope min and max values
> for
> that time dimension are the start time and end time.
I have a question in such a context.
I see the attribute "type" for the CRS node having an element of the
CRS_TYPES list as a value.
The CRS_TYPES list defined in GeographicMetadataFormat only contains
"Geographic" and "Projected" elements. How CompoundCRS (containing also
vertical/temporal CRS) does interact with the CRS_TYPES list in metadata
accessing?
Cheers,
Daniele
>
>
> Actually there is one metadata which is specific to time: this is the
> "origin"
> (or epoch - I don't remember the exact name) in Datum. They are the epoch
> used
> as time 0. This origin is formatted in ISO date format, but this is the
> only
> thing that need to be formatted that way.
>
> Once the origin is defined, and given the time units (units are part of any
> axis
> definition), the start time and end time are completly determined by the
> Envelope.
>
> It would be possible to add explicit "startTime" and "endTime" node to be
> formatted in the ISO way. It would probably be more obvious for human
> reading.
> I'm not sure however that it would be helpful for processing purpose. There
> is
> advantage to make sure that time is handled as an ordinary dimension, in
> that we
> can leverage many of the code that we write for other dimensions, and it
> also
> leads to code where time is not necessarly the last dimension. I don't
> remember
> if "GML in JPEG 2000" has a recommanded practice for that...
>
>
> > Second thing let me do an example ... supposing that I would like to
> > represent a Compund CRS composed by a Geographic CRS EPSG:4326 plus a
> > Temporal CRS, how can I represent this information with this metadata
> > structure? I know that is possible to specify the axis, but where I
> > put the srs information? At least I will lost the information about
> > the EPSG code ... is there a way to retrieve this information
> > somewhere?
>
> The EPSG code is not stored anywhere in the current data structure. If we
> need
> to store it, we can add a slot for that (we would need to look if there is
> something for that in GML in JPEG 2000).
>
> Regards,
>
> Martin
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
