Hey Andrea,
My apologies to you if I seemed to be telling you the obvious. I am well
aware that you understand many and perhaps all of the complexity of
CRS() stuff; my comments are *not* for your education but rather as
nuances and phrasings for your review hopefully to help you write or
benefit someone evaluating our understanding from the outside.
Ultimately I suggest, if you are going to Victoria, that you all make a
decision on these matters out there.
We are in agreement that the Feature's .getCRS() method is problematic
and needs some resolution, probably being dropped. However, there may be
reasons to allow a user to set a CRS on a Feature, as explained below.
The main argument against the method is that the CRS is a property of
the geometry not of the Feature and, since Features can have none or
many geometries, the Feature's CRS would need associated semantics to
explain to what it refers.
A further argument against the presence of the method is that there are
whole classes of Features that have no CRSs, although they might even
have geometries. A Feature can be referenced without a CRS by using a
naming scheme rather than being tied directly to a coordinate
representation, e.g. "The Paris Urban Zone" feature, that would only get
a CRS when linked through both a particular name mapping scheme and a
particular instance of a rooting Feature set---e.g. the same Paris Urban
Zone feature might be internally defined as 'buffer by 100km the
geometry of a 'Paris' feature' and then, in one study, be mapped to a
point 'Paris' feature from a European data set but, in another study, be
mapped to a polygon 'Paris' feature from a regional data set.
Alternatively, Features may have internal CAD geometries but not have
those geometries referenced to any datum---such geometries would not be
'referenced' or 'direct'.
However, there may be reasons to retain the method. Some are presented
below and other people may have more. First some consequences of any
decision to retain Feature.getCRS().
1) Keeping Feature.getCRS() requires us to define what it means.
Note however that if a decision is made to keep Feature.getCRS(), this
will require the development of some convention for how implementations
and Geotools handle features which don't have a CRS and for Features
with multiple CRSs. Do we return 'null'? Does a non-null value guarantee
something about the state of the Feature?
2) Does keeping Feature.getCRS() force us to keep FeatureType.getCRS()?
Also, if we retain and define Feature.getCRS() because we decide this is
indeed a characteristic of the Feature, wouldn't it be necessary for the
FeatureType also to have this information? I don't see how we can avoid
this piece of description or metadata, if we decide there is meaningful
information about the feature in that .getCRS() method call.
The only agrument that I can see to keep Feature.getCRS() would be if it
simplified life for a big class of users. This reasoning may however
apply only to users of SimpleFeatures and so the method might only be
retained there.
Users may wish to have some feature attributes that are dependent on a
geometric and geodetic construction; for these, it may be simpler to
allow the feature itself to have a 'default CRS' rather than requiring
each attribute to hold it. Attributes such as population density only
make sense when related to a geometrical space on which area can be
defined. The full and formal treatment of such attributes would define
them as 'geometry-dependent' or at least 'spatially-dependent'
attributes but it may perhaps be easier, for the common case, to let
users be lazy by having a 'default CRS' in the feature. I would be
against such a move but would understand it.
As background, let me share my current understanding of the semantics of
a Feature. Note this is completely outside of any OGC work, merely what
my understanding is of the scientific objects that I might need to
manipulate. Features are semantically some subset of:
Feature
--id
--attributes which are independent of time and place
--temporal definitions.
--attributes which are time dependent but independent of place
--geometric definitions.
--attributes which are time and place dependent.
The nice thing about this is that I think semantics lets us avoid the
mess that a pure combinatorial approach would force on us. For example,
it makes sense to think of a temporally dependent geometry (the 'Roman
Empire' that expands and collapses over the centuries) but I cannot find
an example where we need to think of the geometrically dependent
temporality of a feature.
If my understanding of the semantics is right, then this structure how I
would like to force myself to model features.
However, I can well understand if this is too formally scientific for
the 'real world' in which Geotools users operate so that we may decide
to allow users to take shortcuts. For example, the Simple Feature Model
happily allows you to add a geometric definition directly to a Feature.
I don't think this invalidates my semantic analysis above that
geometries are *necessarily* time-dependent but rather the approach
hides the semantics as an implicit working assumption by the user. Users
of simple features simply need to remain, at all times, aware of the
temporal domain of their work and deal mentally with the errors which
may accrue from ignoring the time domain in their modeling.
So back to Feature.getCRS(). Formally, a CRS has no business being
associated directly with a Feature. However, informally it may provide a
useful shortcut for users, one which Geotools decides to allow. However,
in that case, we need to specify exactly what we want that CRS to mean
and how we expect users or implementors to interpret it. Also we may
choose to rename this method to indicate more clearly that it's not 'the
one and only' CRS but an extra one: getAttributeCRS() or some such.
Finally, we could allow this only for SimpleFeatures, expecially if we
decide that SimpleFeatures are restricted to having only a
SingleGeometry. In that case a non-null CRS might be a useful tool to
tell us (1) that the Feature has a coordinate geometry and (2) that all
attributes are to be interpreted in terms of that CRS.
Ah, the world is a wonderous place which we can model in so many
ways...I hope this helps frame the issue clearly.
all the best,
adrian
On Thu, 2007-09-06 at 08:41 +0200, Andrea Aime wrote:
> Adrian Custer ha scritto:
> > 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.
> ...
>
> > 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.
>
> I'm certainly aware of this, in fact, I reported this situation in the
> document Justin was commenting, q
>
> "Does it make sense to declare the CRS of a FeatureType? What if inner
> geometries have different
> CRS? Wouldn't it be more general to have a GeometryAttributeDescriptor
> that sports the CRS
> instead?"
>
> > 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.
>
> Well, this is the single place where you cannot absolutely
> remove getCRS(). Everything else can be derived from this one.
>
> >
> > 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?
>
> I have no idea, but I keep on thinking this is redundant and unnecessary.
> Since we already have a preferred geometry
> (Feature.getDefaultGeometry()) by extension we already have a preferred
> CRS. If the meaning of getCRS() was to check whether the CRS of all
> geometries are identical, then the method should really be
> isCRSUniform(): boolean.
>
> > FeatureType.getCRS()
> > --------------------
> > Again, if the object has one, then the descriptor of the object needs to
> > have one.
>
> I disagree, both are derived data that cannot be derived in a sensible
> way in the general case.
> Keeping into consideration all cases, I would
> very much love to see Feature.getCRS() and FeatureType.getCRS() removed.
>
> Having Geom.getCRS() may be redundant as well in simple cases, but I'm
> ok leaving it there because of two reasons:
> * what if the attribute contains geometries in different CRS? Justin,
> is my memory failing me, or the WFS test suite considers this case
> too? In this situation the sensible thing on GeomAttribType.getCRS()
> would be to return null or some
> * as you say, it would allow to have algorithms working on a Geometry
> with full information on it. If we had it today, we would call it
> "ReferencedGeometry" :) (think of ReferencedEnvelope).
>
> Cheers
> Andrea
>
-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
