Hey Andrea,
I'm glad to see you're taking this on. We all need to digest Feature
someday and it would be good to have a solid analysis of the whole
thing. I hope you can grow your analysis into a full featured doc.
Being, as I am, a non-cognecenti I have little to offer you by way of
analysis except on the CRS issue where perhaps my words below will be
helpful rather than confusing.
On Tue, 2007-09-04 at 21:23 +0200, Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>
> > * CRS
> >
> > Agreed. And my opinion is that too many things have CRS's on them.
> > Currently you have the following methods.
> >
> > - FeatureType.getCRS()
> > - Feature.getCRS()
> > - GeometryAttributeType.getCRS()
> > - GeometryAttribute.getCRS()
> >
> > Its confusing... and undocumented how each relates to each other. I have
> > seen the results of this in starting to write code... and trying to
> > figure out the crs is a 4 level deep nested if-else statement.
>
> Agreed. One place would be sufficient.
Well it would be if the world were nice and simple and no one ever did
anything crazy, err. "interesting". In a well structured data set
everything uses the same CRS and indeed we could have 'one place' only.
However, we hopefully will grow to a point where things get interesting.
You, of course, realize that a Feature can have several geometries. You
must then quickly realize that it must be logically possible to have two
geometries in different CRS's: think for instance of the Chernobyl plume
which may have a high density footprint in some projected CRS and have
its trans-polar footprint in some 3D system only. Okay, maybe that's a
bad example since they are slightly different 'features' but there are
lots of examples one could construe of a feature being represented by
two geometries with different CRS's.
Geom.getCRS()
-------------
This relationship is necessary to know what the data means so a piece of
code with a geometry *must* be able to get at the CRS. So the geom
either has a pointer to a CRS or a pointer to an AttributeType with the
CRS. Either way it's probably going to have a convenience method
called .getCRS() because that's an obvious need for working with the
object.
GeomAttribType.getCRS()
-----------------------
Okay, so the geometry logically needs a CRS so we can work with its
coordinates and know what they mean. However, the GeometryAttributeType
probably needs a CRS as well so that the GAT can fully describe the
Geometry it is attempting to describe. It would be an incomplete holder
of metadata if it did not have a pointer to the same CRS, right? The
attribute type of a measure would have to have the same unit as the
measure data object, no? So I don't see a way around this redundancy.
Feature.getCRS()
---------------
Logically, only the geometry has to have a CRS. So why would the feature
itself have a CRS at all? That's an interesting issue. If it has a CRS,
then we are forced into some convention about what the Feature's CRS
means such as:
if (null != Feature.getCRS() )
=> all internal geometries share the same CRS
or it could mean "this is the preferred CRS to use to represent this
feature: for some meaning of 'preferred'. We would have to decide but I
imagine the OGC standards have already decided this for us, no?
FeatureType.getCRS()
--------------------
Again, if the object has one, then the descriptor of the object needs to
have one.
Hope that's not simply muddling up the issues.
--adrian
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
