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
