Re: [Geotools-devel] GeoAPI feature model review

[Adrian C. <ac...@gm...>]

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