epicureanism / inspire-foss

Automatically exported from code.google.com/p/inspire-foss
GNU General Public License v3.0
0 stars 0 forks source link

Insert of inlined Address feature fails #3

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. build deegree latest from SVN (I used rev 26769 on 15.sep.2010)
2. start the deegree3 client and go to OGC web client 
3. execute Addresses choose Transaction | Insert_One_Address_Inlined request

What is the expected output? What do you see instead?
Expected is a successful insert of 4 features (1 Address + 3 components)

Inserting the inlined feature above worked for me on 14.sep.2010 with an 
earlier SVN rev. XLinked feature insert works ok.

Observed is an ows:ExceptionReport with exceptionCode="InvalidParameterValue" 
The stack trace gives

class org.deegree.commons.xml.XMLParsingException: Error in XML document (line: 
64, column: 51, character offset: 3413): Expected feature of type 
"{urn:x-inspire:specification:gmlas:Addresses:3.0}AddressComponent" in property 
"{urn:x-inspire:specification:gmlas:Addresses:3.0}component", but found element 
with name "{urn:x-inspire:specification:gmlas:Addresses:3.0}AddressAreaName".
<< is empty >>
    at org.deegree.gml.feature.GMLFeatureReader.parseFeatureProperty(GMLFeatureReader.java:514)
    at org.deegree.gml.feature.GMLFeatureReader.parseProperty(GMLFeatureReader.java:447)
    at org.deegree.gml.feature.GMLFeatureReader.parseFeature(GMLFeatureReader.java:319)
    at org.deegree.gml.GMLStreamReader.readFeature(GMLStreamReader.java:218)
    at org.deegree.services.wfs.TransactionHandler.parseWFSFeatureCollection(TransactionHandler.java:437)
    at org.deegree.services.wfs.TransactionHandler.parseFeaturesOrCollection(TransactionHandler.java:386)
    at org.deegree.services.wfs.TransactionHandler.doInsert(TransactionHandler.java:340)
    at org.deegree.services.wfs.TransactionHandler.doTransaction(TransactionHandler.java:199)
Please use labels and text to provide additional information.

Original issue reported on code.google.com by jus...@gmail.com on 15 Sep 2010 at 11:35

GoogleCodeExporter commented 9 years ago
First, thanks for spotting this regression. It should be fixed now.

However, there's more to this. According to the INSPIRE schema, the inlining of 
subfeatures is actually *not* permitted -- e.g. for the 
urn:x-inspire:specification:gmlas:Addresses:3.0}component property, only the 
xlink-attributes are allowed, but no child elements.

Of course, this brings up the question why the WFS produces nested features 
when using traverseXlinkDepth > 0!? The answer is that the WFS is currently a 
bit relaxed about this. It's just very convenient to have the ability to 
request a feature and get the subfeatures in the same document as well...

However, I will add a switch to the WFS configuration in the future to enforce 
strict behavior with respect to inlining of features and the requirements of 
the schema. If this switch is set, subfeatures could be added to the top level 
of the feature collection (and xlinks used in the super features). Then again, 
this is a bit strange considering the numHits attribute and the fact that the 
result feature collection will actually contain features that were not 
requested using the typeName attribute.

On the bright side, the WFS 2.0 FeatureCollection introduces a special section 
for such features that have to be included, but that have not been actually 
requested...

Original comment by mar...@beefcafe.de on 15 Sep 2010 at 10:49