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?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel