Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

md-iso.c.6 Dataset geographic bounding box fails unexpectedly #244

Open
PeterParslow opened this issue Apr 12, 2019 · 9 comments
Open

md-iso.c.6 Dataset geographic bounding box fails unexpectedly #244

PeterParslow opened this issue Apr 12, 2019 · 9 comments

Comments

@PeterParslow
Copy link

My record has a bounding box of "west-bound longitude = '-8.655', east-bound longitude = '1.79', south-bound latitude = '49.9', north-bound latitude = '60.85'."

The validator fails it
"The metadata record set has 1 record(s) with errors for this assertion.
XML document 'OSOpenNames.xml', record 'd442b64c-c8c8-11e4-8731-1681e6b88ec1': A dataset (series) metadata record must have a valid bounding box that defines the extent of the resource in geographic space. The bounding box is valid if: 1) it has four coordinates (given in decimal degree with a precision of at least 2 decimals), 2) both west- and east-bound longitude are greater than or equal to -180.00, and smaller than or equal to 180.00, 3) both south- and north-bound latitude are greater than or equal to -90.00, and smaller than or equal to 90.00, 4) south-bound latitude is smaller than or equal to north-bound latitude. At least one of these criteria is not fulfilled for one of the geographic bounding boxes of this metadata record. The provided values of this bounding box are: west-bound longitude = '-8.655', east-bound longitude = '1.79', south-bound latitude = '49.9', north-bound latitude = '60.85'."

Don't forget to include:

  • [ http://inspire-sandbox.jrc.ec.europa.eu/etf-webapp/v2/TestRuns/EIDa7ee9f56-5ff6-4c0d-94f6-c7bbdeb77198.html] a link to the Test Report
  • [http://inspire-sandbox.jrc.ec.europa.eu/etf-webapp//v2/TestRuns/EIDa7ee9f56-5ff6-4c0d-94f6-c7bbdeb77198.html?lang=en#EID38e03270-2c5c-4e15-af35-8eb9c25ecc43 ] the name of the Test that failed or better: change the Level of Detail
    in the Report by clicking on All Details, then scroll down to the failed test
    and copy the Link on the right-hand side of the Assertion URI
  • [https://www.ordnancesurvey.co.uk/xml/products/OSOpenNames.xml ] the URL of your service / the file you have uploaded or referenced.
@fabiovin
Copy link
Member

Dear Peter,
I had a look at your metadata file and I detected that the content of the attribute "xsi:schemalocation" are not correct, indeed the schema validation fails. I substituted the content with the following value: "http://www.isotc211.org/2005/gmd http://schemas.opengis.net/iso/19139/20070417/gmd/gmd.xsd http://www.isotc211.org/2005/gmx http://schemas.opengis.net/iso/19139/20070417/gmx/gmx.xsd", and the schema validation is ok.

Regarding the bounding box error, the test fails because it checks that at least two decimals are present. So, if you use the value "49.90" instead of "49.0" the test passes.

Ciao,
Fabio

@PeterParslow
Copy link
Author

PeterParslow commented Apr 15, 2019

Given that gmx.xsd (indirectly) imports gmd.xsd, I did not expect to have to mention both in the schemaLocation. (This is true in both the opengis.net and standards.iso.org cases). It validates as is in Oxygen (and I have checked, that does include validating the gmd namespace). That's long been a problem with XML validation: different results from different validating parsers.

I had wondered about the schema validation failing - I knew it used to have problems with https redirects - so I ignored it & moved on to the INSPIRE specific tests.

Thanks for pointing out my boundingBox error - I'll fix that.

@fabiovin
Copy link
Member

You're right, XMLSpy also validates the metadata with only the gmx schema declared in the "schemalocation" attribute. But, as you wrote: "different results from different validating parsers".

The https redirect issue doesn't affect the schemas available in the opengis.net repository, so they can be successfully used.

@PeterParslow
Copy link
Author

I've just checked, by changing the schemaLocation to "http://www.isotc211.org/2005/gmx http://schemas.opengis.net/iso/19139/20070417/gmx/gmx.xsd" - it still fails:

XML document 'OSOpenNames.xml': The file has 3 schema validation error(s).
XML document 'OSOpenNames.xml': 1:435: cvc-elt.1.a: Cannot find the declaration of element 'gmd:MD_Metadata'.

So then I tried with both XSDs mentioned, from 'my preferred place': "http://www.isotc211.org/2005/gmx https://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmx/gmx.xsd http://www.isotc211.org/2005/gmd https://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd" - that passes

So it isn't the ISO vs OGC records, or an HTTPS issue; it does seem to be a problem parsing the imports.

I'm confident that my file is schema valid, and follows one of the options in TG Requirement C.1

It validates at http://inspire-geoportal.ec.europa.eu/validator2/

@fabiovin
Copy link
Member

It seems that it is not able to parse the gmd schema from the gmx one.

Trying with the ISO https schemas (http://www.isotc211.org/2005/gmx https://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmx/gmx.xsd http://www.isotc211.org/2005/gmd https://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd) I obtain a different result, the metadata validation fails with both XMLSpy and INSPIRE Validator.

In the end, it seems that there is the issue with the https redirects and also an issue with the parsing of the imported schemas (even though it appears only with the gmx schema).

@fabiovin
Copy link
Member

FYI
Related open issue: etf-validator/etf-webapp#197

@PeterParslow
Copy link
Author

That's very strange: "Trying with the ISO https schemas" succeeded for me in both Oxygen & the INSPIRE Validator a couple of days ago, but then fails for you in the INSPIRE Validator!

Today, it still validates in Oxygen, but INSPIRE validation fails for me too: "premature end of file"

@nmtoken
Copy link

nmtoken commented May 23, 2019

Schema location though is only a hint, the validator should use it's own version of the appropriate schema to do validation. It shouldn't be a validation error for an XML instance to reference a schema that is not accessible to the INSPIRE validator.

@fabiovin
Copy link
Member

The validator uses:

  • schemas declared in xsi:schemaLocation for the version 1.3
  • fixed schemas for the version 2.0

To overcome http to https redirect issue, we created a modified version of the apiso-inspire.xsd schema that now refers to ISO/TC 211 XML Schemas available on the OGC schema repository instead of the ISO repository (where resources have been moved to HTTPS). This version is now used by the Metadata 2.0 test suite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants