Aha, yes, of course! Sorry Andrea, I missed this one. You are completely right.
You know this, but for the benefit of the wider audience: Page 22 of the GML 3.1.1 specification (OGC 03-105r1), section 7.4.3 (it took me ages to find this), states: "An element is a GML property if and only if it is a child element of a GML object. No GML object may appear as the immediate child of a GML object. Consequently, no element may be both a GML object and a GML property." A schema that does not follow this rule is not a GML application schema, and is not supported by app-schema. Simon Cox calls this the GML "striping rule". The effect is that instance documents are encoded with TypeName/propertyName/TypeName/propertyName/..., the effect of which is that: (1) type information is encoded at every second level, fixing one of the huge gaps in modelling polymorphic objects in XML (type uncertainty) (2) there is a place to encode references (xlink:href) of objects that are absent (on the property). This rule makes XML follow the same pattern as a UML diagram: GML properties are the associations between entities, the only way entities can be connected, and only exist in this role. Although the impact of the striping rule was not immediately obvious when I first read it, in my view it is an inspired piece of design. Regards, Ben. On 08/10/10 03:35, Andrea Aime wrote: > Ah hey, > I found the reason today after long head banging. > It seems the encoder works fine with chained features only if the "gml > sharding rule" > is respected, or whatever that thing is called. > > Basically if you have a property that refers to another element you need an > xxxPropertyType that contains an element of type xxxType. > > Feature chaining can only produce subfeatures targetting an element, and there > needs to be consistency in that. My setup had a fake element just to make > app-schema happy but the schema was not using the intermediate top > level element at all. > > The result was that the encoder was looking for the complex element attributes > but in fact it was getting another attribute just containing the target > element > (as it happens in the GML standard way of doing things). > > Looks like a app-schema bug to me, at the very least it should be able > to do feature chaining targetting a type, not an element. > > Ok, it's late and I've made a messy explanation. People very much into this > might understand it anyways. > If it's just clear as mud instead tomorrow I'll try harder showing the schemas > before/after the change > > Cheers > Andrea > > On Thu, Oct 7, 2010 at 8:35 PM, Justin Deoliveira<[email protected]> > wrote: >> Hmmm... nothing jumps out at me right way, Ben probably has a better idea. >> The problem seems quite in depth, i think i would need to debug to figure >> out what is going on. Which i would be happy to do. Any chance you have a >> runnable test case? >> >> On Wed, Oct 6, 2010 at 2:54 AM, Andrea Aime<[email protected]> >> wrote: >>> >>> Hi, >>> I'm pulling my hairs quite a bit with an odd situation: I have setup >>> one feature chaining in the app-schema mappings, >>> I see that the store actually builds the collection of sub-features, >>> but then the gml3 encoder won't emit them in output. >>> I'm quite baffled as to why, though. >>> >>> A bit of context. Here is the relevant schema declarations: >>> >>> <xs:complexType name="OilSpillType"> >>> <xs:complexContent> >>> <xs:extension base="gml:AbstractFeatureType"> >>> <xs:sequence> >>> <xs:element name="eventid" >>> type="xs:string"> >>> </xs:element> >>> <xs:element name="origin" >>> type="csn:OriginType"> >>> </xs:element> >>> <xs:element name="geometry" >>> type="gml:MultiPolygonPropertyType"/> >>> <xs:element name="polygons" >>> type="csn:SpillPolygonArrayType"/> >>> ... >>> </xs:complexType> >>> >>> <xs:complexType name="SpillPolygonArrayType"> >>> <xs:annotation> >>> <xs:documentation>Array spill polygons along with >>> their >>> extension</xs:documentation> >>> </xs:annotation> >>> <xs:sequence> >>> <xs:element ref="csn:SpillPolygon" minOccurs="0" >>> maxOccurs="unbounded"/> >>> </xs:sequence> >>> </xs:complexType> >>> <xs:element name="SpillPolygon" type="csn:SpillPolygonType"> >>> <xs:annotation> >>> <xs:documentation>Oil Spill root element for a >>> generic Oil Spill >>> observation or prediction</xs:documentation> >>> </xs:annotation> >>> </xs:element> >>> <xs:complexType name="SpillPolygonType"> >>> <xs:annotation> >>> <xs:documentation>A single spill polygons along >>> with its >>> extension</xs:documentation> >>> </xs:annotation> >>> <xs:sequence> >>> <xs:element name="polygon" >>> type="gml:PolygonPropertyType" minOccurs="0"/> >>> <xs:element name="extension" >>> type="csn:OilSpillExtensionType" minOccurs="0"/> >>> </xs:sequence> >>> </xs:complexType> >>> >>> (A note there, at first I did not have the SpillPolygon element but >>> noted that the app-schema store >>> would not work without an element as the target). >>> >>> And here is the relevant mapping parts: >>> >>> <AttributeMapping> >>> >>> <targetAttribute>csndc:polygons/csndc:SpillPolygon</targetAttribute> >>> <sourceExpression> >>> <OCQL>strSubstringStart(getID(), strLastIndexOf(getID(), >>> '.') + 1)</OCQL> >>> <linkElement>csndc:SpillPolygon</linkElement> >>> <linkField>FEATURE_LINK</linkField> >>> </sourceExpression> >>> <isMultiple>true</isMultiple> >>> </AttributeMapping> >>> >>> (ok, not too good looking, but that's how I managed to extract the >>> actual primary key value >>> to be used for feature joining) >>> >>> <FeatureTypeMapping> >>> <sourceDataStore>egeos-emsa-pg</sourceDataStore> >>> <sourceType>oilspillpolygon</sourceType> >>> <targetElement>csndc:SpillPolygon</targetElement> >>> <attributeMappings> >>> <AttributeMapping> >>> >>> <targetAttribute>FEATURE_LINK</targetAttribute> >>> <sourceExpression> >>> <OCQL>oilspillid</OCQL> >>> </sourceExpression> >>> </AttributeMapping> >>> <AttributeMapping> >>> >>> <targetAttribute>csndc:polygon</targetAttribute> >>> <sourceExpression> >>> <OCQL>spillpolygon</OCQL> >>> </sourceExpression> >>> </AttributeMapping> >>> <AttributeMapping> >>> >>> <targetAttribute>csndc:extension/csndc:area</targetAttribute> >>> <sourceExpression> >>> <OCQL>extension_area</OCQL> >>> </sourceExpression> >>> </AttributeMapping> >>> <AttributeMapping> >>> >>> <targetAttribute>csndc:extension/csndc:length</targetAttribute> >>> <sourceExpression> >>> >>> <OCQL>extension_length</OCQL> >>> </sourceExpression> >>> </AttributeMapping> >>> <AttributeMapping> >>> >>> <targetAttribute>csndc:extension/csndc:width</targetAttribute> >>> <sourceExpression> >>> >>> <OCQL>extension_width</OCQL> >>> </sourceExpression> >>> </AttributeMapping> >>> </attributeMappings> >>> </FeatureTypeMapping> >>> >>> Now, as I said, I debugged the code and I see that the app-schema >>> store is actually >>> producing the polygons attribute, whose tostring looks like: >>> >>> >>> ComplexAttributeImpl:polygons<SpillPolygonArrayType>=[ComplexAttributeImpl:SpillPolygon<SpillPolygonType>=[FeatureImpl:SpillPolygon<SpillPolygonType >>> id=oilspillpolygon.10>=[AttributeImpl:FEATURE_LINK<string>=1, >>> GeometryAttributeImpl:polygon<PolygonPropertyType>=POLYGON ((8.927616 >>> 43.863998, ... >>> >>> but then the encoder fails to encode it, in particular it seems for >>> some reason it's not being >>> able to extract the properties inside the spill polygon. >>> In fact, in those cases in which I have two polygons inside the array >>> I get this as the output: >>> >>> ... >>> <csndc:polygons> >>> <csndc:SpillPolygon/> >>> <csndc:SpillPolygon/> >>> </csndc:polygons> >>> ... >>> >>> I'm quite baffled as to why this is happening. Ah, I also tried to >>> make SpillPolygon a feature at the >>> schema level and at the mapping level, but when I do I get this exception: >>> >>> Caused by: java.lang.NullPointerException: >>> http://www.emsa.europa.eu/csndc:SpillPolygonType is identified, null >>> id not accepted >>> at org.geotools.feature.type.Types.validate(Types.java:118) >>> at org.geotools.feature.type.Types.validate(Types.java:80) >>> at org.geotools.feature.AttributeImpl.<init>(AttributeImpl.java:51) >>> at >>> org.geotools.feature.ComplexAttributeImpl.<init>(ComplexAttributeImpl.java:35) >>> at org.geotools.feature.FeatureImpl.<init>(FeatureImpl.java:57) >>> at >>> org.geotools.feature.AppSchemaFeatureFactoryImpl.createFeature(AppSchemaFeatureFactoryImpl.java:128) >>> at >>> org.geotools.feature.AttributeBuilder.create(AttributeBuilder.java:574) >>> at >>> org.geotools.feature.AttributeBuilder.add(AttributeBuilder.java:495) >>> at org.geotools.data.complex.filter.XPath.setValue(XPath.java:769) >>> at org.geotools.data.complex.filter.XPath.set(XPath.java:700) >>> at org.geotools.data.complex.filter.XPath.set(XPath.java:553) >>> at >>> org.geotools.data.complex.DataAccessMappingFeatureIterator.setAttributeValue(DataAccessMappingFeatureIterator.java:394) >>> at >>> org.geotools.data.complex.DataAccessMappingFeatureIterator.computeNext(DataAccessMappingFeatureIterator.java:712) >>> ... 73 more >>> >>> With a mapping looking like: >>> >>> <FeatureTypeMapping> >>> <sourceDataStore>egeos-emsa-pg</sourceDataStore> >>> <sourceType>oilspillpolygon</sourceType> >>> <targetElement>csndc:SpillPolygon</targetElement> >>> <attributeMappings> >>> <AttributeMapping> >>> >>> <targetAttribute>csndc:SpillPolygon</targetAttribute> >>> <idExpression> >>> <OCQL>getID()</OCQL> >>> </idExpression> >>> </AttributeMapping> >>> <AttributeMapping> >>> >>> <targetAttribute>FEATURE_LINK</targetAttribute> >>> <sourceExpression> >>> <OCQL>oilspillid</OCQL> >>> </sourceExpression> >>> </AttributeMapping> >>> ... >>> >>> and of course the necessary modifications in the schema to make >>> csndc:SpillPolygon >>> a feature. >>> >>> Not that I want it to be a feature, was just guessing that maybe the >>> property extractors >>> in the encoder work only against features, but as you see I did not >>> manage to confirm >>> or deny this hypothesis. >>> >>> Anyways, does the above ring any bell? >>> >>> Cheers >>> Andrea >>> >>> ----------------------------------------------------- >>> Ing. Andrea Aime >>> Senior Software Engineer >>> >>> GeoSolutions S.A.S. >>> Via Poggio alle Viti 1187 >>> 55054 Massarosa (LU) >>> Italy >>> >>> phone: +39 0584962313 >>> fax: +39 0584962313 >>> >>> http://www.geo-solutions.it >>> http://geo-solutions.blogspot.com/ >>> http://www.linkedin.com/in/andreaaime >>> http://twitter.com/geowolf >>> >>> ----------------------------------------------------- >>> >>> >>> ------------------------------------------------------------------------------ >>> Beautiful is writing same markup. Internet Explorer 9 supports >>> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. >>> Spend less time writing and rewriting code and more time creating great >>> experiences on the web. Be a part of the beta today. >>> http://p.sf.net/sfu/beautyoftheweb >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> > > > > -- > ----------------------------------------------------- > Ing. Andrea Aime > Senior Software Engineer > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584962313 > fax: +39 0584962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ----------------------------------------------------- > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ben Caradoc-Davies <[email protected]> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
