OGC GML Writer Parameters

The GML writer can write a dataset according to an existing GML Application Schema, or create the GML Application Schema along with the written dataset.

The GML Application Schema option is used in conjunction with the Application Schema parameter. The resulting GML Application Schema mode allows the writer to write GML datasets according to existing GML-based standard formats such as AIXM v5.1 or INSPIRE.

The Application Schema parameter is used to specify the appropriate XML Schema document.

Setting the parameter to either 3.1.1 or 3.2.1 instructs the writer to create an XSD that is based on the writer feature type definitions. A new XSD document will be created every time.

Specifies the location of the GML Application Schema .xsd document.

The directive specifies the GML application schema target namespace prefix. The default value for this directive is fme.

This parameter specifies the GML application schema target namespace URI. The default value for this parameter is http://www.safe.com/gml/fme.

Note that a URI is a label only (usually an ownership identifier), and the XML Namespace specification does not require that the URI be used for information retrieval. Using a URI (rather than a simple string) to identify a namespace reduces the probability of different namespaces having duplicate identifiers.

Setting this parameter to Yes ensures the output is neatly formatted. This promotes easier reading on screen and in print output.

• Indent Size – Select a value from 0 to 9.
• Replace Tabs with Spaces  – By default, the Tab character is used to for indentations. Select Yes to substitute the Tab character with a Space.
• Text Indent  – By default, the text in a tag is left untouched. Select Yes to include pretty printing in the text.

The root collection element is influenced by this parameter.

• FeatureCollection – In GML 3.1.1 mode, the default collection element is <gml:FeatureCollection>; the Feature Collection NS URI parameter may be used in conjunction with this parameter to change the collection element to <wfs:FeatureCollection>.

• target-namespace – Changes the root element to <[target-ns-prefix]:FeatureCollection>, where [target-ns-prefix] is the prefix that is bound to the output document target namespace, e.g., <fme:FeatureCollection>. The output xsd document will also include a custom FeatureCollection declaration and FeatureCollectionType definition.

This parameter allows you to supply a custom gml:id value to replace UUID that is automatically assigned for the feature collection under GML v3.2.1.

This parameter is used to specify the XML Namespace URI for the element name that is specified as the feature collection in the Feature Collection parameter.

For example, to specify the WFS 2.0 "FeatureCollection", set this parameter to http://www.opengis.net/wfs/2.0 and Feature Collection to FeatureCollection (as specified above, in Feature Collection when GML Version is Application Schema).

This parameter specifies how embedded GML objects (those containing a gml:id), that are not geometries should be mapped.

By default, these embedded objects are mapped into FME Attributes.

If the parameter is set to Geometries, the embedded objects are mapped into FME Geometries, and the embedded object properties are loaded into geometric traits. In turn, nested embedded objects are mapped into nested aggregate geometries.

If the parameter is set to Feature Types, the embedded objects will be mapped into separate FME feature types, and these feature types will have an additional gml_parent_id attribute whose value refers back to its parent feature.

Specifies whether the default and optional GML feature properties, name and description, should be read.

The GML writer will automatically substitute concrete elements that are substitutable for abstract GML properties. Some GML formats declare properties that are not abstract but are nevertheless head of substitution groups.

Selecting this parameter instructs the GML writer to also generate FME attributes for member elements belonging to the substitution group headed by these non-abstract GML properties.

This parameter controls whether XML Namespace prefixes are applied to feature types, attributes, or both. The prefix will be separated from the names by an underscore.

• Feature Types – Includes the prefixes in the feature types. Setting this parameter to Feature Types is necessary if the XSD Schemas contains feature types with the same name in different namespaces.
• Feature Types (On Conflict) – Includes the prefixes in feature types only when the XSD Schemas contain feature types with the same name in different namespaces.
• Feature Types and Attributes – Includes the prefixes in both the feature types and attributes.

There are many different feature types with many possible geometries per feature type.

Nameless geometries are ignored by writers in Application Schema mode because they do not correspond to any properties in the .xsd documents.

When this option is checked, the writer will attempt to write out nameless geometries to geometrically compatible properties.

This parameter specifies whether GML Coverages should be mapped into FME features.

Specifies whether GML properties that are defined as a complex type with complex content (that is, those that have embedded child elements) should be expanded into Nested Attributes within FME features, or stored as XML Fragments.

• If set to XML Fragments, complex properties are not expanded. Instead, their entire content is stored as XML text within a single attribute. This produces smaller, simpler feature structures and is suitable when detailed access to individual child elements is not needed.
• If set to Nested Attributes, complex properties are expanded into nested list attributes wherever possible, exposing their child elements directly as FME attributes. This option is useful when detailed access to individual elements or values is required for mapping or transformation, although it can produce large or deeply nested attribute structures.

When using Nested Attributes, some complex properties that contain embedded objects or geometry elements may still be stored as XML fragments, depending on schema structure or other mapping limits.

Certain complex properties, such as those that are recursively defined or that would otherwise cause circular references, are always mapped as XML fragments regardless of this setting.

This optional parameter applies only when Map Complex Properties As is set to Nested Attributes. It limits how many consecutive levels of multivalued nested list attributes (for example, lists within lists) are preserved before deeper levels are converted into XML fragments.

When the nesting of list elements exceeds this number, expansion automatically stops at that level and deeper content is stored as XML fragments. This helps prevent extremely deep or repetitive data hierarchies from consuming excessive memory or producing unwieldy nested attribute structures.

If this parameter is not specified, all levels of nested lists are expanded up to the general safety limits. Setting a lower value restricts expansion to shallower lists, while a higher value allows deeper nesting at the cost of larger, more complex features.

This parameter may be used to optionally specify the XML document that is to be written out as output. Any XML element created from a rooted feature by the writer will be inserted into this document. By default, the XML elements are inserted right before the end tag of the XML document’s root element.

XML Document Append Path

This parameter specifies a single element via a QName, or a path to a single element via a path of QNames, in the XML Document.

This parameter specifies a single insertion point in the XML Document. To append into multiple sections, use the xml_document_append_path format attribute – this format attribute overrides this parameter if present.

XML Document Append As

This parameter controls how the features that are mapped into XML are inserted into the XML Document in relation to the XML Document Append Path.

The possible values for the parameter are:

• Succeeding Children (default)
• Preceding Children
• Preceding Siblings
• Succeeding Siblings

The values are to be understood in relation to the selected or matched element.

Each individual root feature may override this parameter by using the xml_document_append_as format attribute. The possible values for xml_document_append_as are preceding_children, succeeding_children, preceding_siblings, and succeeding_siblings.

This parameter may be used to optionally specify a wrapper XML fragment for the XML elements that are created from the XSD Schema.

Each individual feature may override this parameter by using the xml_wrapper format attribute.

XML Wrapper Append Path

This parameter specifies a single element via a QName, or a path to a single element via a path of QNames, in the XML Fragment.

Each individual feature may override this parameter by using the xml_wrapper_append_path format attribute.

XML Wrapper Append As

This parameter controls how the features that are mapped into XML are inserted into the XML Wrapper in relation to the XML Wrapper Append Path.

The possible values for the parameter are:

• Succeeding Children (default)
• Preceding Children
• Preceding Siblings
• Succeeding Siblings

The values are to be understood in relation to the selected or matched element.

Example – consider the following XML Document:

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd">
   <gmd:hierarchyLevel>
      <gmd:MD_ScopeCode codeList="" codeListValue="">dataset</gmd:MD_ScopeCode>
   </gmd:hierarchyLevel>
     … By default XML elements are inserted here …
</gmd:MD_Metadata>   

If the Feature Paths parameter is set to map gmd:DQ_DataQuality, then the writer will generate a <gmd:DQ_DataQuality> fragment from a feature and insert before the end of the <gmd:MD_Metadata> tag.

It is also possible to wrap the generated <gmd:DQ_DataQuality> in another xml wrapper fragment by using the XML Wrapper parameter. If XML Wrapper has the <gmd:dataQualityInfo/> fragment, the generated <gmd:DQ_DataQuality> will be appended before the end tag of <gmd:dataQualityInfo>, the <gmd:dataQualityInfo> will be appended before the end tag of <gmd:MD_Metadata>:

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd">
   <gmd:hierarchyLevel>
      <gmd:MD_ScopeCode codeList="" codeListValue="">dataset</gmd:MD_ScopeCode>
   </gmd:hierarchyLevel>
   <gmd:dataQualityInfo>
      <gmd:DQ_DataQuality>
            … contents generated by the XSD Driven XML writer …
      </gmd:DQ_DataQuality>
   </gmd:dataQualityInfo>
</gmd:MD_Metadata>

Each individual root feature may override this parameter by using the xml_document_append_as format attribute. The possible values for xml_document_append_as are preceding_children, succeeding_children, preceding_siblings, and succeeding_siblings.

Coordinate systems may be extracted from input feature data sources, may come predefined with FME, or may be user-defined. FME allows different output and input coordinate systems, and performs the required coordinate conversions when necessary.

For systems that know their coordinate system, the Coordinate System field will display Read from Source and FME will read the coordinate system from the source dataset. For most other input sources, the field will display Unknown (which simply means that FME will use default values). In most cases, the default value is all you'll need to perform the translation.

You can always choose to override the defaults and choose a new coordinate system. Select More Coordinate Systems from the drop-down menu to open the Coordinate System Gallery.

Changing a Reprojection

To perform a reprojection, FME typically uses the CS-MAP reprojection engine, which includes definitions for thousands of coordinate systems, with a large variety of projections, datums, ellipsoids, and units. However, GIS applications have slightly different algorithms for reprojecting data between different coordinate systems. To ensure that the data FME writes matches exactly to your existing data, you can use the reprojection engine from a different application.

To change the reprojection engine, Select Workspace Parameters > Spatial > Reprojection Engine. In the example shown, you can select Esri (but the selection here depends on your installed applications):

This parameter can overwrite the CRS value that is written in the GML instance’s srsName attributes.

By default, the FME coordinate system name in a feature is transferred directly onto the srsName attribute. Using this parameter allows you to provide your own URN CRS string for the srsName attributes.

This parameter specifies the axis order for a coordinate tuple in a GML <pos> or <posList> element.

The valid values are

• 1,2
• 2,1
• 1,2,3
• 2,1,3

There is no default value.

Setting this parameter to Yes allows GML geometry xlink references to be written. The corresponding FME geometry must have a non empty xlink_href trait.

For example, if a surface component, such as a Face in a Composite Surface, has an xlink_href trait with value #GML_d3981803-d4b0-4b5b-969c-53f657594757, then the writer will produce the following geometry reference:

<gml:surfaceMember xlink:href="#GML_d3981803-d4b0-4b5b-969c-53f657594757"/>

Including the gml_orientation boolean trait with a "-" or "+" value along with the xlink_href trait causes the writer to output an OrientableSurface with a base surface geometry reference. For example:

<gml:surfaceMember>

<gml:OrientableSurface orientation="-">

<gml:baseSurface xlink:href="#GML_d3981803-d4b0-4b5b-969c-53f657594757"/>

</gml:OrientableSurface>

</gml:surfaceMember>

This parameter specifies options for writing an FME path in a gml:Ring. The available options are:

• Segment-Only Output for Unidentified Paths (default) – If a path lacks a gml:id, only the segments of the path will be written as separate direct curve members of the GML ring; otherwise, if the path has a gml:id, then the entire path is written as a gml:Curve in a single GML ring curve member.
• Full Path as GML Curve – Always represent the entire path using the gml:Curve format in a single GML ring curve member, irrespective of the presence of a gml:id.

• Yes – Every GML writer feature type is translated to the output GML application schema document as an XML Schema element declaration and a corresponding complex type definition.
• No (default) – Directs the writer to ignore those feature types that have no corresponding feature instances.

Specify the maximum number of decimal places to write to the GML file when writing coordinates.

To specify an exact number of decimal places to write, use this parameter in conjunction with the Minimum Decimal Places parameter.

Value

An integer greater than or equal to 0.

Default value: 15

Specify the minimum number of decimal place write to the GML file when writing coordinates.

To specify an exact number of decimal places to write, use this parameter in conjunction with the Maximum Decimal Places parameter.

Value

An integer greater than or equal to 0.

Default value: 0

Instructs the writer to write out only the .xsd document, only the .gml document, or both documents.

This parameter suppresses the output of the xsi:schemaLocation attribute in the GML instance’s root element. The xsi:schemaLocation in an XML document instance is not a mandatory attribute – it is merely a hint that an XML processor may choose to ignore.

Setting this parameter to Yes suppresses the output of the xsi:schemaLocation attribute in the output GML instance. The default setting is No.

Specify an XSLT stylesheet to be applied to the final output document.

The Stylesheet Result parameter may be used in conjunction with this parameter to specify the location and filename of the resulting transformation.

This parameter is valid only in conjunction with the XSLT Stylesheet to Apply parameter.

When this parameter is not defined, the resulting XSLT transformation will have the same location and filename as the output dataset, with the exception that the filename will be prefixed with transformed_.

This parameter is valid only if XSLT Stylesheet to Apply is specified, and it takes precedence over Stylesheet Result.

When set to Yes, a temporary file is written in the same folder at the location specified in the writer, the stylesheet is applied to the to temporary file, and the result of the transformation is stored in the output dataset file.

The legal values for this parameter are whitespace-separated XML namespace declarations as they would appear in an XML element.

When an Application Schema mode is not selected, this parameter allows elements in different namespaces, other than the GML and the document target namespace, to be included in the output file. A schema file is not written when this parameter is used – that is, the output XSD file is suppressed. To control the namespace of a particular element, the FME feature type and/or attribute name must carry the corresponding namespace prefixes declared by this parameter.

When an Application Schema mode is selected, this parameter allows different namespace declarations other the ones extracted from the parsed XSD documents be used in the output document. The parameter may be used to control prefixes (for example, to use the default namespace), and also to trim the number of namespace declarations written to the top level element.

One use of this namespace declaration parameter is to set the default namespace in order to remove the namespace prefix from the element names.

For example, consider <gn:NamedPlace>. To remove the gn namespace prefix, you will have to make the namespace associated with gn the default namespace. Looking at the namespace header of the default output, you will see that:

xmlns:gn="urn:x-inspire:specification:gmlas:GeographicalNames:3.0"

To remove this namespace, you will have to set Override XSD and Use Namespace Declarations to: xmlns="urn:x-inspire:specification:gmlas:GeographicalNames:3.0"

Thereafter, the output will contain <NamedPlace>, not <gn:NamedPlace>.

Determines if FME writes the Geometries as a gml:Polygon or a gml:PolygonPatch.

• No (default value): Prints out gml:Surface geometries.
• Yes – FME creates the geometry as a gml:Polygon in the output.

A gml_id geometry trait, if present, is used to populate the gml:id attribute of a GML geometry element. For example, an FME Point with the gml_id trait will be written as <gml:Point gml:id="…">.

• Yes – A gml:id will be automatically generated for GML geometries without a corresponding gml_id geometry trait.
• No – This is the default value.

This optional parameter performs validation of the output file against the schemas referenced in that file:

Yes:

• If GML Version is set to 3.1.1 or 3.2.1, the schema used for validating the output file is determined by the version specified.
• If GML Version is set to GML Application Schema, the specified Application Schema is used for validation.

No (default):

• Validation is not performed.

A gml_id geometry trait, if present, is used to populate the gml:id attribute of a GML geometry element. For example, an FME Point with the gml_id trait will be written as <gml:Point gml:id="…">.

• Yes – A gml:id will be automatically generated for GML geometries without a corresponding gml_id geometry trait.
• No – This is the default value.

By default, the URL for the target namespace URI-URL location pair in the instance document’s xsi:schemaLocation attribute is the GML application schema’s relative filename. This parameter allows you to overwrite the .xsd filename by supplying a custom URL.

The parameter only affects the value of the URL for the target namespace in the xsi:schemaLocation. It does not affect where the application schema will be written (for this, see the Application Schema parameter). The parameter should have exactly one URL value indicating the XSD location for the target namespace URI.

If the parameter has multiple values, then they must be whitespace-separated URI–URL pairs. This option allows the user to provide a complete custom xsi:schemaLocation for the output document.

Example:

http://www.conurl/ns.xsd

Specifies the encoding to use for the output XML documents, which include both the GML instance and the GML application schema.

If this parameter is left blank, the value UTF-8 will be used.

Authentication Method

Specify the authentication method to use when accessing a password-protected server.

• Basic (default) – Basic access authentication is designed to allow a client to provide credentials to a server on the assumption that the connection between them is trusted and secure. Note that any credentials passed from client to server can be easily intercepted through an insecure connection.
• Digest – Digest authentication is one of the agreed-upon methods a web server can use to negotiate credentials, such as username or password, with a user's web browser.
• NTLM – A challenge-response protocol that is used to provide compatibility with versions of Windows earlier than the Windows 2000 operating systems.
• Web Connection – Web connections provide a convenient and secure way to store and reuse previously established connection parameters. See Web Connection below.
• Single Sign-on – FME will use the credentials of the current user to authenticate the HTTP request. This authentication method currently works only on the Windows operating system.

Web Connection

Using Web Connections

FME Options: Web Connections