On Mon, Jul 28, 2008 at 5:35 PM, Martin Desruisseaux <
[EMAIL PROTECTED]> wrote:
> Daniele Romagnoli a écrit :
>
>> 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?
>>
>
> The CRS_TYPES list is incomplete. It should probably contains the full list
> of ISO 19111 types. However we have not expanded the list yet because I
> still unsure that it is the proper way to do. The alternative would have
> been to do the "GML in JPEG 2000" way and include a nested XML element just
> in order to give the type. In other words, we could have either:
>
> <crs type="Projected">
> <datum type="Geodesic">
> <ellipsoid>
> etc...
> </ellipsoid>
> </datum>
> <cs type="Cartesian">
> etc...
> </cs>
> </crs>
>
>
> or
>
>
> <crs>
> <ProjectedCRS>
> <datum>
> <GeodesicDatum>
> <ellipsoid>
> <Ellipsoid> <!-- Note this apparent repetition -->
> etc...
> </Ellipsoid>
> </ellipsoid>
> </GeodesicDatum>
> </datum>
> <cs>
> <ProjectedCS>
> ... etc ...
> </ProjectedCS>
> </cs>
> </crs>
>
>
> The later is the GML way (and generally speaking the OGC way - note that
> XML elements that are for "types" always begin with an uppercase letter). It
> may leads to very deep hierarchy given that if we choose this way, then in
> order to be consistent we need to apply it for every objects, even the ones
> where there is currently only one possible type (CoordinateSystemAxis,
> Ellipsoid already flagged in above example, PrimeMeridian, etc.) - and they
> are the majority, thus leading to the huge XML tree that we see in GML.
>
> The former is the proposed simplification for Image I/O metadata, replacing
> nested XML elements by a "type" attribute. However I tend to depart from
> standards only with hesitations, and have not completed the list because I'm
> not totally sure that it is the right thing to do. I was hoping for more
> experience.
>
> Any opinion?
Indeed the GML way seems generating a big hierarchy tree.
Could make sense adopting the simplification by introducing something like a
CompoundCRS in CRS_TYPES as well as a metadata attribute containing a comma
separated list of "primitive" CRSs (geographic, projected, temporal,
vertical, ...) composing the CompoundCRS? (Just to ease the work of the user
to know in advance the composing CRSs before checking datums and CSs).
Daniele
>
>
> Martin
>
--
-------------------------------------------------------
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
