Skip to main content

Hi,

I have a workspace transforming data to write it in INSPIRE GML format (theme Hydrography). Earlier this year, some of the INSPIRE application schemas (XSDs) where upgraded to a new version Include changes from 2024.1 schema release · Issue #1027 · INSPIRE-MIF/helpdesk-validator, including the hy-p one that I’m using here (v4.0 to v5.0).

Therefore I changed my INSPIRE GML writer to point to the new XSD URI and adapted the xsi:schemaLocation parameter consequently. However, when indicating the v5.0 the output GML is not written correctly: there are remnants of the v4.0 in it.

First in the imports, see xmlns:hy-p4 and xmlns:hy4:

<gml:FeatureCollection xmlns:omor="http://inspire.ec.europa.eu/schemas/omor/3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sr="http://inspire.ec.europa.eu/schemas/sr/4.0" xmlns:base="http://inspire.ec.europa.eu/schemas/base/4.0" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:hy-n="http://inspire.ec.europa.eu/schemas/hy-n/4.0" xmlns:omop="http://inspire.ec.europa.eu/schemas/omop/3.0" xmlns:hy="http://inspire.ec.europa.eu/schemas/hy/5.0" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:base-3_3="http://inspire.ec.europa.eu/schemas/base/3.3" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:om="http://www.opengis.net/om/2.0" xmlns:hy4="http://inspire.ec.europa.eu/schemas/hy/4.0" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gn="http://inspire.ec.europa.eu/schemas/gn/4.0" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:sc="http://www.interactive-instruments.de/ShapeChange/AppInfo" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:hy-p4="http://inspire.ec.europa.eu/schemas/hy-p/4.0" xmlns:net="http://inspire.ec.europa.eu/schemas/net/4.0" xmlns:hy-p="http://inspire.ec.europa.eu/schemas/hy-p/5.0" gml:id="idafb2e1b9-af4e-4d00-b1a2-07ed3a6513ee" xsi:schemaLocation="http://inspire.ec.europa.eu/schemas/hy-p/5.0 http://inspire.ec.europa.eu/schemas/hy-p/5.0/HydroPhysicalWaters.xsd http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd http://inspire.ec.europa.eu/schemas/base/4.0 http://inspire.ec.europa.eu/schemas/base/4.0/BaseTypes.xsd http://inspire.ec.europa.eu/schemas/gn/4.0 http://inspire.ec.europa.eu/schemas/gn/4.0/GeographicalNames.xsd http://www.isotc211.org/2005/gmd http://schemas.opengis.net/iso/19139/20070417/gmd/gmd.xsd">
...

Then also in the FeatureMembers where some of the elements are encoded in the v4.0, example (I included the GML in the associated zip file):

<hy-p4:inspireId>
<base-3_3:Identifier>
<base-3_3:localId>A39682C09219AA32F73D7803C22169A0</base-3_3:localId>
<base-3_3:namespace>http://geodata.wallonie.be/id/ge/watercourse/</base-3_3:namespace>
</base-3_3:Identifier>
</hy-p4:inspireId>
<hy-p4:delineationKnown>FALSE</hy-p4:delineationKnown>
<hy-p4:length uom="m">1281.21</hy-p4:length>
<hy-p4:level>underground</hy-p4:level>

That’s even the case for base-3_3 which is supposed to be replaced with new version 4.0 of BaseTypes.

I’m currently using FME2020.1.2, I first thought that this issue was linked to the online XSD not being read properly by FME. But in the latest FME2024.1 you implemented the new application schemas v5.0, I tested it and still got the same issue.

When getting into the logs, I noticed that the XSD was successfully downloaded:

INFORM|URI 'https://inspire.ec.europa.eu/schemas/hy-p/5.0/HydroPhysicalWaters.xsd' mapped to 'https://inspire.ec.europa.eu/schemas/hy-p/5.0/HydroPhysicalWaters.xsd'
INFORM|'https://inspire.ec.europa.eu/schemas/hy-p/5.0/HydroPhysicalWaters.xsd' mapped to 'C:\Users\ajacques\AppData\Local\Temp\FME_XSD_CACHE\fmexsd_1730896429864_15544.xml'

But right after this, some XSD Semantics configuration file is used and it imports the wrong hy-p4 XSD:

2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using XSD semantics configuration file 'C:\Program Files\FME2020\xml\gml_v3.2\inspire_config.xml'.
2024-11-06 14:02:46|   0.3|  0.0|INFORM|XSD semantics configuration file: 'file:///C:/Program Files/FME2020/xml/gml_v3.2/inspire_config.xml' including 'gml_config.xml'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'hy-p' for uri 'http://inspire.ec.europa.eu/schemas/hy-p/5.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'hy-p4' for uri 'http://inspire.ec.europa.eu/schemas/hy-p/4.0'

2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'sc' for uri 'http://www.interactive-instruments.de/ShapeChange/AppInfo'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'gmd' for uri 'http://www.isotc211.org/2005/gmd'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'gn' for uri 'http://inspire.ec.europa.eu/schemas/gn/4.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'om' for uri 'http://www.opengis.net/om/2.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'net' for uri 'http://inspire.ec.europa.eu/schemas/net/4.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'gss' for uri 'http://www.isotc211.org/2005/gss'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'gsr' for uri 'http://www.isotc211.org/2005/gsr'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'base-3_3' for uri 'http://inspire.ec.europa.eu/schemas/base/3.3'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'gml' for uri 'http://www.opengis.net/gml/3.2'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'hy4' for uri 'http://inspire.ec.europa.eu/schemas/hy/4.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'hy' for uri 'http://inspire.ec.europa.eu/schemas/hy/5.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'xlink' for uri 'http://www.w3.org/1999/xlink'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'omop' for uri 'http://inspire.ec.europa.eu/schemas/omop/3.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'hy-n' for uri 'http://inspire.ec.europa.eu/schemas/hy-n/4.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'gts' for uri 'http://www.isotc211.org/2005/gts'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'base' for uri 'http://inspire.ec.europa.eu/schemas/base/4.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'gco' for uri 'http://www.isotc211.org/2005/gco'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'sr' for uri 'http://inspire.ec.europa.eu/schemas/sr/4.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'xsi' for uri 'http://www.w3.org/2001/XMLSchema-instance'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|Using prefix 'omor' for uri 'http://inspire.ec.europa.eu/schemas/omor/3.0'
2024-11-06 14:02:46|   0.3|  0.0|INFORM|<INSPIRE_1 Writer> - Writing the GML document 'HY.watercourse.KARST__ECOULEMENTS_SOUTERRAINS.gml'

Thus, I went to open that inspire_config.xml and there I replaced the v4.0 XSD by the new one and hy-p4 by hy-p5 (see attached file).

In that way, the GML is written correctly without mention of hy-p4 (GML in the zipped file).

Now, what I’d like to understand/know is:

  • Did I find the real source of the issue? Or am I missing something?
  • What’s the purpose of that XML?
  • Do I have to fix it myself for the time being or can Safe provide a fix in an upcoming version release?
  • Do all the new application schemas have to be updated in that file in order to be written properly? The old ones have to be “removed” and the new ones added?

EDIT: bonus question: how to fix this in FME Flow as well?

Thanks for your time and consideration, I can provide the entire logs and screenshots of the writer configuration if needed.

Best regards,

Antoine

Hello @antja, thanks for posting! I’ve tried my best to answer your questions below: 

  • Did I find the real source of the issue? Or am I missing something?
    • Yes, I believe you’ve successfully diagnosed the issue. We tried to make it a priority to update all inspire schemas to v5 if applicable, but it looks like we might’ve missed a few (FMEENGINE-82532). Thank you for catching this!
  • What’s the purpose of that XML?
    • The purpose of this xml config file is to ensure FME is mapping too and using the most correct schema available for the inspire theme being used. 
  • Do I have to fix it myself for the time being or can Safe provide a fix in an upcoming version release?
    • I have filed an issue explicitly for this theme. Moving forward, we can refer to this issue as FMEENGINE-84617. Unfortunately, I am unable to provide timeline details at this time, but it is on our radar now - thank you again!
  • Do all the new application schemas have to be updated in that file in order to be written properly? The old ones have to be “removed” and the new ones added?
    • I believe we keep older schema references in the event some people need to update from an older schema to the newer schema, or vice versa. 
  • EDIT: bonus question: how to fix this in FME Flow as well?
    • We can use a similar workaround on FME Flow, where we will need to update the inspire_config.xml used by FME Flow. I did some testing to see where the inspire_config.xml is pulled from by Flow:
      2024-11-7 12:53:08 | Using XSD semantics configuration file 'C:\Program Files\FMEFlow\Server\fme\xml\gml_v3.2\inspire_config.xml'.
      We would need to add the reference to hy-p5. Let me know if you run into any issues here!

Hello @kailinatsafe ! Thanks for your answer. We’ll try to implement the temporary fix ourselves until it is permanently solved on Safe side then :)

Just so you know: just adding hy-p5 didn’t solve it for me. If hy-p4 was still in the XML then the output GML would still have the error, but I guess you guys will test this thoroughly.

 

I also came around another issue with the application schemas of LC theme. In there as well, when trying to create a GML with new lcv/5.0 schema, the output GML would present some remnants of v4.0 → I documented this in an INSPIRE ticket where you can fetch the concerned data: https://github.com/INSPIRE-MIF/helpdesk-validator/issues/1132#issuecomment-2462154313

The GML elements lcv:extent and lcv:nomenclatureDocumentation are enclosed in an extra node mentioning lcv/4.0 while it is not needed since I adapted the writer + xsi:schemaLocation parameter to v5.0. I changed the inspire_config.xml file the same way I did for hy-p5 but there was no change in the output.

Any thoughts?

Best regards


Hello @antja, thanks for getting back to me! I’ll ensure to pass these notes along. Yes, please try the FME Flow solution and let me know if the issue is resolved!

Terribly sorry you’re encountering this with another theme. Can I confirm we’re speaking about the Land Cover Vector v5.0 INSPIRE theme? Happy to look into this further, Kailin.


Hi @kailinatsafe ! 

Yes that’s the theme I’m talking about, it’s importing elements from land cover vector 4.0 and land cover nomenclature 4.0 while it should’nt.

https://inspire.ec.europa.eu/schemas/lcv/index.html

Thanks for your time!


Hello ​@kailinatsafe, do you have any news concerning LandCover issue?

Regarding my first post about inspire_config.xml, I have some extra information to provide. We managed to upgrade the application schemas of several other themes (HumanHealth, ProtectedSites, AdministrativeUnits, NaturalRiskZonesCore, RailwayTransportNetwork, RoadTransportNetwork) without any complication with the XSD nor the INSPIRE GML Writer used. Besides, if we apply the fix we agreed on, it means that we would replace schema Base3.3 by new version Base4.0 but that would impact all our others datasets if 3.3 is not available anymore.

To sum up:

  • Majority of the upgrade to new application schemas that we made went fine
  • Issue with hy-p solved in inspire_config.xml
  • Issue with lcv not solved in inspire_config.xml

Isn’t that an hint that the source of the problem is somewhere else?

Best regards

 


Hello ​@antja, thanks for reaching out again! I appreciate you summarizing the findings. Unfortunately, I do not have any additional information at this time, but it is on developments radar. I will update this thread when possible! Terribly sorry if this causes any inconvenience, Kailin.


Hello ​@antja, thank you for your patience! We were able to diagnose and resolve the issue in the provided workspace. The workspace has been annotated to explain what is happening! Turns out, hy-p v4 and v5 were clashing or overriding eachother based on the value of xml_ns_uri. Adding a prefix to the uri will resolve the issue. 

Uploading workspace in Form 24.1 b24612 & sample output. 


Hello ​@kailinatsafe, thanks for your time and advices!
I managed to produce a conflictless hydrography GML by adding the namespace as a prefix in the featuretype written out. If I understand correctly the problem might be linked to the INSPIRE XSD itself.

I tried to implement this solution for my LandCover issue but it didn’t change anything. I suspect that something else is at work there. Will you have the opportunity to investigate this as well? I can provide extra info if needed.

 


Hello ​@antja, no worries at all! I am glad the solution worked well for you. Happy to look into the LandCover v5 issue. Are you able to share a similar reproduction package, like you have on the original post? (eg. workspace, sample data, expected output, current output). Best, Kailin. 


Hi ​@kailinatsafe, it is documented in the github ticket here INSPIRE LC - validator test driver returns error · Issue #1132 · INSPIRE-MIF/helpdesk-validator

I enclose the current (wrong) output in this answer. The expected output shouldn’t mention the v4.0 namespaces of lcv and lcn in the nodes lcv:extent and lcv:nomenclatureDocumentation. Those elements are linked to the LandCoverDataset featuretype.

I also join a workspace where I only kept the FeatureWriter so you can see how it’s configured. I’m using FME Form build 24627.


Hello ​@antja, I will take a look today, thank you so much! Best, Kailin.


Hello ​@antja, thank you again for troubleshooting with us! I have filed a separate issue to investigate the land cover issue (FMEENGINE-85036). I will update this thread as I can. 

On an aside, another issue was filed to add a third option to the 'XML Namespace Prefix to’ parameter. Ideally we’d like to have an option to prefix Feature types if multiple namespaces are detected (FMEENGINE-85027). Best, Kailin


Reply