Jody Garnett ha scritto: > Justin Deoliveira wrote: >> 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. >> > How do you guys want to handle this? As I understand it an srsname can > appear in any of those locations in GML. > You could remove it from FetureType and GeoetryAttributeType and express > it as a constraint on the valid > values (but that would kill usability). > > I think the place we *want* it for readable code is in in > GeometryAttribute - so we can quickly figure out the crs for a geometry > without guess work. And also in GeometryAttributeType - so we can > quickly figure out what projection any content we are creating needs to > be in. > > For Feature and FeatureType perhaps we can leave that information up to > the GML parser (to be context sensitive) and it can use > putClientProperties if it really cares to store the context on the > FeatureType.
See my answer to Adrian. The only place where getCRS() is necessary is on the geometry and its type, but not on feature and featuretype, where it's at best derived data (but not really that either, what do you derive when crs is not uniform? If null, then no code can really work against it and have to revert to a scan of geometry attribute type inside the feature type). >> * InternationlizedString >> >> Can we kill this? I don't see the point of modeling i18n directly in the >> api since every application does i18n differently. It would be one thing >> if this was a subclass of String, but its not. I know it extends >> CharSequence but still... I dont really see any other java api's that do >> this. >> > Where is this being used in the feature model? I find that > InternationalString is great, and really lets us > have a smooth mapping from ISO standards to Java. The break down of > human readable vs machine readable > text is explicit and leaves no guess work. > > If you can give me specific things to look at I will check the ISO19107 > and see if it actually supposed to > be human readable. Hum, imho i18n is a topic for UI and reporting that should not touch the classes. But I understand this reason is much like saying that classes should not be concerned with hashmaps (Object.hashCode()) and i/o (serialization). I don't like it, but if people want it, I won't do anything to stop you. Oh, btw, in the document I was wrong, only getDescription() uses InternationalString, so my observations aren't standing completely. >> * FeatureCollection >> >> I think we should kill this all together from geoapi. It adds a ton of >> complexity (associations and stuff) with very little gain. Especially >> since we recently decided how to model feature collection in geotools >> and it involves not making FeatureCollection a feature. >> > I would like some feedback on this, I don't mind stripping it out but it > does seem to be a break with GML and the OGC reference model. There is > nothing special about FeatureCollection; the same result can be had by > making a Feature that has an association called "members" (I just find > it useful to have this common case captured explicitly so we can provide > an iterator / visitor to navigate the contents. That's what I said in my document as well I think? FeatureCollection and Association are redundant, and I would love much more to have a FeatureCollection that has no modelling semantic in it, but plays exclusively the datastore intermediator for feature access (well, what I'd really like is to kill it completely since most of what it offers is already provided by FeatureSource, but I have to compromise in order to find an agreement). > GeoAPI is not complete with out a representation of FeatureCollection, > if we want to make it not implement Feature then we should do that. > > If you guys want to remove the geoapi FeatureStore class then you can > remove FeatureCollection as a concern for later; but until then we need > something. FeatureStore is an interesting cross between datastore and feature store. Now I see why you replicated much of the FeatureSource behaviour in FeatureCollection, the idea was to scrap FeatureSource too? >> * Choice/Sequence >> >> These appear to be unused. Hopefully Gabriel can better comment on the >> usage of these. >> > I am not sure if they are needed? Creating your ComplexType with a > List<AttributeDescriptor> is good enough to indicate sequence. Choice > is represented with a rather stupid filter constraint; but there is > nothing special about the interface. > > They do service as a good documentation on "how to do it"; but perhaps > that is where they should be kept? I guess so. 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
