Ben Caradoc-Davies wrote: > It appears that SimpleFeatureTypeBuilder > accepts only String property names,
Aren't features using multiple namespaces in the same feature type already falling in the complex feature case? What's simple is actually not very clear in my mind. For example, in OGR simple means no namespace, no associations, no multi valued attributes, and one single geometry. In GeoTools right now it means no namespaces, no associatinos, no multi valued attributes, but we support multiple geometries. > SimpleFeatureTypeBuilder and its best friend AttributeTypeBuilder are > most kindly described as bloated and crufty. Please clarify where the bloat and the cruft are. Too many methods? > Even after hacking SimpleFeatureTypeBuilder to be Name-based with > backwards-compatible support for String names, I still run into > problems. For example, the Query API forces all property names to be > Strings, losing namespace support, and breaking unit tests. I do not > think that this can be fixed without breaking backwards compatibility of > the Query API. > > It is a big mess. Yup. Name usage has been introduced api wise but nothing in the codebase uses it. Nothing at all afaik. > It seems to me that GeoTools requires wide-ranging > backwards-incompatible changes to better support namespaces. This may > cause inconvenience to those who have code based on GeoTools. > > (1) Does the community want to see such a change? Well, if that's what we need to support community schema and complex features fully, I don't see many alternatives. The main issue I see is that this change is going to turn the codebased inside-out like a glove. At GeoServer we are re-starting to work on trunk so a GeoServer 2.0 release is probably on the radar within 6 months or less. If this change is going to happen, it's better to have it happen fast, so that we have some time to recover from the consequences (no chance it's going to be painless bug-wise). > (2) How should it be done? (I am looking for suggestions of where to > start, and other areas that will need work.) I don't have a perception of specific areas that need more work than others. A change like this is going to affect the whole codebase... > (3) Who is able to help? Still working on the filter cleanup, something I would like to get done by Geotools 2.6. That basically absorbs all of my spare time already. Work wise I think we made it clear that OpenGeo would have provided support for this work in terms or review, but no actual coding? Here you're asking us to expand our commitment to this work. Cheers Andrea ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
