Andrea Aime wrote: > 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.
The OGC Simple Features spec permits multiple namespaces, even for compliance level 0 (SF0). See the example on pages 22-23 of OGC 06-049r1, in which the feature type contains both gml:boundedBy and myns:geomProperty. The limited implementation in GeoTools is already causing problems. User complaints about not being able to have a NAME column in view may be related; GeoTools cannot handle both gml:name and myns:name, and relies on the encoder to hack together a presentable document. As another example, GML3EncodingTest http://svn.osgeo.org/geotools/trunk/modules/extension/xsd/xsd-gml3/src/test/java/org/geotools/gml3/GML3EncodingTest.java parses this document which has namespace-qualified properties: http://svn.osgeo.org/geotools/trunk/modules/extension/xsd/xsd-gml3/src/test/resources/org/geotools/gml3/bindings/test.xml The namespace is discarded from the properties. At encoding time, GML2EncodingUtils responds to requests for namespace-scoped properties by stripping the namespace off the property name and querying the feature for the local name. These complementary kludges allow GeoTools to maintain the pretence of supporting namespaces, but it doesn't. It would be really good if GeoTools and GeoServer could support OGC Simple Features. Even SF0 would be great. At the moment, it is a very limited subset. (Don't get me started on CodeType and MeasureType, which are mandatory for SF0.) >> 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? They are huge and mutable, making them hard to maintain and test, because of the importance of order in method calls. What is the cyclomatic complexity of using one of these builders with N stateful method calls before you build the type? Got to be something like factorial(N). They are also concrete, so their behaviour cannot be changed (only a FeatureTypeFactory can be injected). SimpleFeatureTypeBuilder: almost 1000 lines, 13 mutable members, 49 public methods. AttributeTypeBuilder: over 600 lines, 20 mutable members, 37 public methods. I understand their purpose: to facilitate building types. To do this, they act as a facade over the complexity of building contained types, descriptors, and CRSs. The consequence of this approach is that all the business logic is concealed in these concrete classes. It is not any simpler, just hidden. It is easier to test, because it is localised, and at least it is reused, but is still rather nasty. > Yup. Name usage has been introduced api wise but nothing in the codebase > uses it. Nothing at all afaik. Thanks for confirming that. I have been approaching this conclusion the hard way. >> (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). OK, I will keep this in mind and keep changes as small a possible, to preserve stability. Kind regards, -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia ------------------------------------------------------------------------------ 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
