There comes a time for every geo-ict professional to have his first encounter with GML. Most of the time, this is not a pretty sight. Until now, I have managed to steer clear from GML when it comes to actually incorporating it into my own software. But today, this day dawned.
So here’s what I’m going to do. I’m going to generate .NET classes for the GML 3.2.1 schema. When that’s done, I’ll try and actually read a GML 3.2.1 document and do something remotely useful and relevant with it. The second bit will be for a followup post, most probably.
To get started, we’re going to get the combined schemas in one zip file from http://schemas.opengis.net/SCHEMAS_OPENGIS_NET.zip
Then, we unzip those into a directory, say c:\ogc\
We then navigate to C:\ogc\gml\3.2.1 and open a VS2008 command prompt there.
Now we are all set to startto generate .NET classes using xsd.exe
First try is
xsd.exe gml.xsd /classes
This generates a whole bunch of error messages
Some research into the limitations of xsd.exe reveals that the schemaLocation attribute in an import element is ignored by xsd.exe.
For the <import> element, the Xsd.exe tool ignores the schemaLocation attribute, expecting imported files instead as additional command-line arguments.
Q: Why doesn’t XSD.exe support the schemaLocation attribute on imports and includes?
A: The W3C XML Schema recommendation describes this attribute as a hint, which can be ignored by processors that can use alternate means to locate schemas. XSD.exe only uses schemas that are specified through the command line to convert schema A.xsd, which imports schema B.xsd.
xsd.exe /c A.xsd B.xsd
So it turns out we need to specify all schemas referenced using import elements need to be supplied as command line arguments to xsd.exe. That means we need to find all schema files referenced to using import elements in gml.xsd and – cascadingly – in all schema files referenced using include elements. This is one hell of a job which took me about an hour of concentrated gazing at XML schemas to complete.
The reward was an xsd.exe command line that actually worked:
C:\ogc\gml\3.2.1>xsd.exe gml.xsd ..\..\xlink/1.0.0\xlinks.xsd ..\..\iso\19139\20 070417\gmd\gmd.xsd ..\..\iso\19139\20070417\gco\gco.xsd ..\..\iso\19139\20070417 \gss\gss.xsd ..\..\iso\19139\20070417\gts\gts.xsd ..\..\iso\19139\20070417\gsr\g sr.xsd /classes Microsoft (R) Xml Schemas/DataTypes support utility [Microsoft (R) .NET Framework, Version 2.0.50727.1432] Copyright (C) Microsoft Corporation. All rights reserved. Writing file 'C:\ogc\gml\3.2.1\gsr.cs'. C:\ogc\gml\3.2.1>
The proof of the pudding is in the screenshot:
The result is a gml.cs C#.NET class file that we shoul be able to use in an XmlSerializer. More in a future post.