Description

Writing GML or XML

You can write to GML or XML in FME using one of five approaches: predefined GML profiles for standards such as national formats, FME's default GML for simple schemas, templates with XMLTemplater for more complex XML to comply with an application schema, XQuery / XMLUpdater, or  XSLT style sheets. However, since most XML does need to comply with an application schema, unless you are writing to an XML or GML profile we already support, you will most likely need to use XMLTemplater to write your XML.

In some cases, there are sets of application schemas that are grouped together and called a gml profile. This essentially constitutes another GML format, since it would be rather complex to read and write data to one of these GML profiles without some custom development. Thus Top10 GML, German NAS, OS MasterMap and CityGML are all examples of GML profiles that we have implemented as separate formats.

For simple GML you may be able to just set up a default translation and then make modifications to the destination schema as needed. This can work for flat data structures where each feature is composed of a geometry and a set of attributes but doesnt have nested child elements or abstract types. In these cases the GML writer has an option to generate an xsd when writing GML to facilitate reading it later on. You can also import the destination GML schema from an XSD, although there are limits to the extent that we will support nested structures. These are usually modeled as lists.

You can also do GML to GML translations and use XQuery or XMLUpdater to modify existing xml structures without mapping them to relational ones. This may be the best approach when your source data is already in XML or GML, and you just want to update or modify some component of the data but not create a new dataset. See articles on XQuery or XMLUpdater for more information.

In other cases the type of GML schema may be complex and involve nesting, abstract types, multiple namespaces etc. Writing to complex application schemas usually requires the use of XMLTemplater or XSLT stylesheets.

Are there GML datasets which are believed to comply with GML specs that we cannot write to? This is possible but I have yet to encounter a gml structure we cannot write to. However, some schemas are so complex that transforming the data to populate them can take a lot of work. The best thing to do in such cases is to send some sample data to support@safe.com and we can take a look.

Writing to Specific GML Schemas

As our GML developer puts it, "writing to arbitrary GML application schemas is not a trivial problem"! The reason is that an application schema essentially represents a unique format. So when you want to write to a specific application schema you are really asking for a new GML profile writer.

One way to get data into a user defined schema is to create a stylesheet and use that to transform the data via XSLT . An easier way to do this is to define an XML template based on the schema and use the new XMLTemplater to merge your data into that schema. For more information on each of these approaches see the fmepedia documentation on:

• Writing XML/GML using XMLTemplater
• Writing XML/GML using XSLT Style Sheets

GML Version Support

FME supports reading and writing GML 2.1.2, 3.1.1 and 3.2.1.

Basically, the GML reader will scan the data, detect version, and call the correct reader version accordingly. For writing you need to add the writer associated with what GML version you want.

Now, just because we say we read and write a particular version of GML, it doesn't mean we can read from or write to a particular GML schema out of the box. It also does not mean we have implemented the entire schema of what is theoretically possible. Practically no one has done this. This is because the specification for what can be defined in GML is hundreds of pages long (500+), and so every software developer needs to decide what subset of this they want to implement and support. For example, ESRI only implemented simple feature profile level 0, which covers points, lines, polygons, but not arcs or ellipses, etc.

Even with the range of GML that FME supports (see the GML Quick Facts section for an overview), often people can forget that there are supporting files required to read a specific GML structure. As with any xml document, GML can be interpreted in different ways. This is why application schemas - .xsd files are critical to reading a gml file. Usually it is not enough to have access to the GML 3.2.1 schemas. Most user or custom defined GML data structures require the presence of an xsd or xml schema definition file in order to read the .gml file. In fact, you can import the GML schema from an .xsd file without even having any .gml data.

Coordinate System Support

When writing GML, FME attempts to find the EPSG number corresponding to the coordinate system of the data. This match is done by examining the exceptions/epsg.db file. If we can find a match then we write this information to the GML dataset in the form:

srsName="EPSG:####"

We chose this method as being the most sensible, but happily it also seems to be emerging as the de facto standard for such information.

Where we cannot match the user's coordinate system to an EPSG equivalent - and when the user has a custom coordinate system definition there is very little chance of a match - we simply write out the name of the coordinate system from FME. This is not much use to whomever gets the file - unless, of course, they also happen to be using FME and also possess any custom definitions - but is better than nothing.

XML Writer