GML file nested data structure

[marcingrudzien]

Error report http://inspire-sandbox.jrc.ec.europa.eu/etf-webapp/v2/TestRuns/EIDe3d14a66-685a-4323-8bae-c6189991912d.html
Data sample
cadastrtalParcels_020103_v3.txt
Reported error cp=gml.a.1: "The XML documents representing the spatial data set do not contain a feature of CadastralParcel. If you have expected to find CadastralParcel spatial objects in the data set, please consult the statistics information to see the spatial object types that have been found."

The problem is the structure of tested file. It looks like this
<wfs:FeatureCollection >
<wfs:member >
<wfs:FeatureCollection >
<wfs:member >
<cp:CadastralParcel >…</cp:CadastralParcel>
</wfs:member>
</wfs:FeatureCollection>
</wfs:member>
</wfs:FeatureCollection>
It seems that validator expects something like this
<wfs:FeatureCollection >
<wfs:member >
<cp:CadastralParcel >…</cp:CadastralParcel>
</wfs:member>
</wfs:FeatureCollection>

However, we think that data structure that we are using is correct. It is by default returned by GeoServer (when GeoServer returns more than one feature type) and validates against schema. Could you take an look on it?

Best regards,
Marcin Grudzień

[michellutz]

@inakidiazdecerio Could you pls look into this?

[inakidiazdecerio]

Dear @marty1357 and @michellutz,

We have found the solution for this issue.

The ETS checks if the wfs:FeatureCollection element contains the cp:CadastralParcel element, it doesn't check if contains other wfs:FeatureCollection element like in the example of @marty1357. This is why it fails.

The solution we propose is check the childs of wfs:FeatureCollection element. In case that cp:CadastralParcel element exists the test doesn't fail, if not exists the test fails.

If you agree, we will implement the proposed solution in the ETS.

[marcingrudzien]

@inakidiazdecerio the proposed solution looks fine to me. Of course the solution should be generic, meaning it should apply to all feature types (not only cp:CadastralParcel). We encountered similar issues with AD, TN INSPIRE data sets.

[inakidiazdecerio]

@marty1357 we can apply this solution to all feature types in:

• Addresses
• Administrative Units
• Cadastral Parcels
• Geographical Names
• Hydrography
• Protected Sites
• Transport Networks

[ilkkarinne]

A note: this nested wfs:featureCollection behaviour is actually not only a Geoserver feature, but specified in OGC & ISO WFS 2.0. standard, chapter "11.3.3.5 Multiple query response".

[michellutz]

See http://docs.opengeospatial.org/is/09-025r2/09-025r2.html#189 for the relevant section in WFS 2.0,2.

[MarieLambois]

There seems to be many options of nesting wfs:member. Would it be possible to search for //cp:CadatralParcel (wherever it is) ?

[thijsbrentjens]

Supporting the idea of @MarieLambois

[inakidiazdecerio]

Dear @marty1357,

We are happy to announce that the solution for this issue has been implemented in the INSPIRE Validator. We have prepared a testing environment with the solution. The solution passed our quality controls, but we will appreciate if you could test it before deploying it in production.

You will find the solution deployed in following link:

http://staging-inspire-validator.eu-west-1.elasticbeanstalk.com/etf-webapp/

Thanks in advance for your help.