OGC GML Reader Parameters

A GML instance document specifies the namespace and the location of its application schema through its root element xsi:schemaLocation attribute. This field allows the GML (or GML-based) reader to use a different GML schema document from the one specified in the xsi:schemaLocation attribute.

The XML Schema specification states that the xsi:schemaLocation attribute value consists of a set of pairs: The first member of each pair is the namespace for which the second member is the hint describing where to find an appropriate schema document. The presence of this hint does not require the processor to obtain or use the cited schema document, however, the processor is free to use other schemas obtained by other suitable means.

This optional parameter instructs the reader to map FeatureCollection as an FME feature.

Values:  gml:FeatureCollection | wfs:FeatureCollection

Usually, only one value is used within a dataset. Selecting both gml:FeatureCollection and wfs:FeatureCollection may cause a clash in feature type names when both GML and WFS schemas are loaded, since FME needs the feature type to be unique in a reader or writer.

If both values are required, you may need to set the Add XML Namespace Prefix to parameter to a value of Feature Types – this parameter adds the namespace prefix to the feature types to make them unique.

Overrides the axis order when reading a coordinate tuple in a GML element.

Valid values for this parameter:

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

There is no default value for most GML formats; however, for IndoorGML, there is a default blank value (which is the same as 1,2,3).

For WFS 1.0, the value is assumed to be 1,2. For WFS 1.1.0 and 2.0.0, the SRS order is determined by the SRS specified. For example, the default axis order for EPSG:4326 is 2,1.

If the srsName in the GML document is set to urn:ogc:def:crs:EPSG:6.6.4326, and you know that the coordinate order in the GML document is lon-lat and not lat-lon order, set this parameter to 1,2 so that the reader reads the data in lon-lat order.

This parameter affects the interpretation of the start and end angles for gml:ArcByCenterPoint.

The parameter overrides the default interpretation for the 0 axis location and angle direction regardless of the dataset SRS.

By default, if the SRS axis order is 1,2 or 1,2,3, then the angle direction is assumed to run counterclockwise starting from the horizontal axis. Otherwise, when the x and y axes are flipped, the angles run clockwise starting from the vertical axis.

This parameter controls how segments in a path are joined together when the segments' end points are not connected:

• Inserting New Segment connects the path by inserting a new connecting segment between the original segments.
• Snapping End Points forces the first point of each segment to equal the last point of the previous segment.

Setting this parameter to Yes instructs the GML reader to resolve the GML xlink geometry references to their actual target geometries.

The resolved geometries will include an xlink_href trait. In addition, if the xlink:href geometry reference is from a base surface of a GML OrientableSurface, or a base curve of a GML OrientableCurve, then the resolved geometry will also include a gml_orientation trait.  The legal values for gml_orientation are "+" and "-".

Unable to resolve xlink href xml_geom_error

If this parameter is set to Yes, and FME is unable to resolve the xlink, the feature is tagged with an xml_geom_error.

Any geometries that cannot be read via the xlink:href have an xml_geom_error = Yes, accompanied by a xml_geom_error.unresolved_xlink_href = geoborder gml_parent_id URN. For example, when reading AIXM5 data, this is more likely to occur when the airspace has a boundary that is supposed to coincide with a polyline from geoborder_timeslice, but that link cannot be resolved because it is a link to another GML object and not directly to a GML geometry.

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.

This parameter specifies whether the GML geometric properties should be represented as attributes in the FME feature type definitions.

In FME data features, the GML geometric properties are represented as a single named geometry – or, if multiple geometries are present, as an aggregate geometry with multiple named geometry components. The name and the position for these geometric elements can also be controlled through the OGC GML User Attributes

• If this parameter is checked (which is the default), then the feature type definitions will contain the geometry names as attributes, and their type is set to xml_geometry. If an attribute X has its type set to xml_geometry, this attribute X becomes a placeholder in the feature type definition. It is a placeholder because actual data features for the feature type definitions will not have this attribute; instead, the data features will have a geometry named “X”.
• If this parameter is unchecked, then the feature type definition will not contain geometry names.

The GML reader 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 reader to also generate FME attributes for member elements belonging to the substitution group headed by these non-abstract GML properties.

The FME feature type and/or attribute names may include the XML Namespace prefixes used in the GML application schema. The prefix will be separated from the names with an underscore.

By default, the prefixes are not added to the names. To include the prefixes in the feature types, select Feature Types. To include the prefixes in both the feature types and attributes select Feature Types and Attributes.

Setting this parameter to Feature Types is necessary when a GML dataset contains feature types with the same name in different namespaces.

The list of whitespace-separated QNames specified in this parameter defines properties that the reader should ignore while processing the GML application schemas.

To ignore property regardless of namespace, simply specify the local-part of the name. For example:

boundedBy name

will ignore all properties whose local name are boundedBy or name, regardless of their namespace.

A prefix in a QName should be present in the parsed XML schemas. If no corresponding URI namespace can be found for a prefix, then the prefix will be discarded. The QName will (as in the unprefixed case) apply to all properties with the same local-part, regardless of namespace.

For example:

gml:boundedBy identifier wrong-prefix:description

If a binding for the gml prefix can be found in the parsed schema, then only boundedBy properties with the same namespace URI as gml will be ignored; otherwise, every boundedBy property regardless of namespace will be ignored.

Every identifier property, regardless of namespace, will be ignored. Every description property regardless of namespace will also be ignored, since the parsed schema will not have a binding for the "wrong-prefix" prefix.

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 children elements) should be mapped as nested list attributes within FME features.

If the value is set to XML Fragments, then the complex properties with complex content are mapped as XML fragments.

Some complex properties, such as those that are recursively defined, cannot be mapped as nested lists. These complex properties will always be mapped as XML fragments, regardless of the setting for this parameter.

This optional parameter can control the depth of nested list attributes.

When this parameter is selected, the reader, in addition to mapping the GML geometry XML elements into FME geometries, will include these elements in FME attributes as XML fragments in the feature.

The FME geometry attributes are typed as xml_geometry in the feature type definition. In the group Version and XML Namespace Processing below, see the parameter Use Old Reader for GML v3.1.1 and v2.1.2 Documents.

This parameter is useful in the case of a GML geometry reading error, since the XML fragment representing the GML geometry will also be carried along in the same feature as an attribute.

Specifies whether GML properties that are mapped as XML fragments should be converted into XML documents.

The conversion will add missing namespace declarations to the fragments, it will maintain CDATA sections, and it will also prefix an XML header declaration to the fragment. Converting the XML fragments into XML documents allows XML-based parsers, e.g., XSLT and XQuery based processors, to further process the fragments.

This parameter specifies whether GML properties that are mapped as XML fragments should be flattened into nested attributes.

The flattening will only be applied to the data features carrying the XML fragments, hence the new flattened nested attributes will not be reflected in the FME feature type schema definitions.

These options are available for the flattened list attributes:

• Substitute Open List Brace: This directive specifies the character to use as the open brace for the flattened list attributes. The open brace defaults to a curly brace { but any single character is accepted.
• Substitute Close List Brace: This directive specifies the character to use as the close brace for the flattened list attributes. The close brace defaults to a curly brace } but any single character is accepted.
• Substitute Element List Separator: This directive specifies the string to use as the separator for components within the nested attributes. The nested attribute component separator defaults to a period (.) but any single character is accepted.

When selected, this parameter instructs the GML reader to use the older GML v3.1.1 code base to read GML v3.1.1 and v2.1.2 documents.

When selected, this parameter disables automatic reader selection/switching.

When the GML reader is reading OS MasterMap or CityGML data, FME analyzes the namespace header for URIs that indicate format, and then passes the data on to that reader. The reader then automatically switches to the OS(GB) MasterMap or CityGML reader.

When selected, this parameter disables XML Namespace processing for the underlying XML parser.

Note that this may cause reading errors if the GML schema and the GML data use different prefixes for the same namespace URI. This parameter may be useful for datasets that are not XML-Namespace-valid.

Allows the GML reader to extract values from the XML Schemas. A dataset is not required in this mode since the values for the data features are determined from the xsds. The xsd value attribute names will be suffixed with .xsd.XXX, where XXX are various xsd components. A single data feature is constructed for each Explore XSD Values feature type definition.

For example, the "Bygning" SOSI feature type has a "medium" attribute whose type is xml_buffer. The "medium" is an enumeration in the XML Schema, but this is not representable in the FME feature type definitions, therefore xml_buffer was used. Enabling this Explore XSD Values option instructs the GML reader to construct the following attributes for "medium":

"medium.xsd.enum{}.value" "xml_buffer"

"medium.xsd.enum_values_csv" "xml_buffer"

"medium.xsd.enum{}.annotation.appinfo{}.source" "xml_buffer"

"medium.xsd.enum{}.annotation.appinfo{}.xml_fragment" "xml_xml"

"medium.xsd.enum{}.annotation.documentation{}.source" "xml_buffer"

"medium.xsd.enum{}.annotation.documentation{}.text" "xml_buffer"

"medium.xsd.enum{}.annotation.documentation{}.xml_fragment" "xml_xml"

"medium.xsd.enum{}.annotation.documentation{}.xml_lang" "xml_buffer"

The xsd.enum{} is a list attribute whose component lists a single enumeration value, while xsdl.enum_values_csv is a single attribute listing all enumeration values as a comma-separated string:

"medium.xsd.enum{0}.value" has value "V"

"medium.xsd.enum{1}.value" has value "B"

"medium.xsd.enum{2}.value" has value "L"

"medium.xsd.enum{3}.value" has value "I"

"medium.xsd.enum{4}.value" has value "S"

"medium.xsd.enum{5}.value" has value "T"

"medium.xsd.enum{6}.value" has value "O"

"medium.xsd.enum{7}.value" has value "D"

"medium.xsd.enum{8}.value" has value "J"

"medium.xsd.enum{9}.value" has value "W"

"medium.xsd.enum{10}.value" has value "U"

"medium.xsd.enum{11}.value" has value "X"

"medium.xsd.enum_values_csv" has value "V,B,L,I,S,T,O,D,J,W,U,X"

An enumeration may contain up to a single annotation, while each annotation may contain any number of documentation and appinfo tags. In the same example, the medium.xsd.enum{}.annotation.appinfo{} list attribute component lists the source xml attribute and appinfo content, where appinfo content is an xml fragment. Similarily, the medium.xsd.enum{}.annotation.documentation{} list attribute component lists the source xml attribute, the xml:lang xml attribute, and documentation content as both raw xml (xml_fragment) and text:

"medium.xsd.enum{0}.annotation.documentation{0}.source' has value `'

"medium.xsd.enum{0}.annotation.documentation{0}.text' has value `Alltid i vann '

"medium.xsd.enum{0}.annotation.documentation{0}.xml_fragment' has value `<documentation xmlns="http://www.w3.org/2001/XMLSchema">Alltid i vann</documentation>'

"medium.xsd.enum{0}.annotation.documentation{0}.xml_lang' has value `'

For documentation content, the xml_fragment attribute contains exactly the xml fragment as in the .xsd, while the text attribute contains only existing raw text and no other xml.

Currently, only enumeration values and annotations contained within enumerations are supported.

Use this parameter to expose Format Attributes in FME Workbench when you create a workspace:

• In a dynamic scenario, it means these attributes can be passed to the output dataset at runtime.
• In a non-dynamic scenario, this parameter allows you to expose additional attributes on multiple feature types. Click the browse button to view the available format attributes (which are different for each format) for the reader.

A search envelope (also known as a bounding box) is a rectangular area that defines a geographic area. In FME, the easiest way to define a search envelope is to use search envelope parameters.

Defining a search envelope is the most efficient method of selecting an area of interest because FME will read only the data that is necessary – it does not have to read an entire dataset. Search Envelope parameters apply to both vector and raster datasets and can be particularly efficient if the source format has a spatial index.

Most FME readers have parameters to define the search envelope of data that is being read:

The parameters include the x and y coordinates of the bounding box as well as a parameter that defines the coordinate system.

How to Define the Bounding Box

Using the minimum and maximum x and y parameters, define a bounding box that will be used to filter the input features. Only features that intersect with the bounding box are returned. Note that the bounding box intersection is not a full geometry intersection (based on spatial relationships) that would be returned by a transformer like the SpatialFilter.

Search Envelope Coordinate System

Specifies the coordinate system of the search envelope if it is different than the coordinate system of the data. The coordinate system associated with the data to be read must always be set if this parameter is set.

If this parameter is set, the minimum and maximum points of the search envelope are reprojected from the Search Envelope Coordinate System to the reader’s coordinate system prior to applying the envelope.

The underlying function for Use Search Envelope is an intersection; however, when Clip to Search Envelope is checked, a clipping operation is also performed.

• When checked (set to Yes), this option instructs FME to clip features to the exact envelope boundary. FME removes any portions of imported features being read that are outside the search envelope.
• When left unchecked (set to No), features that overlap the boundary will be included in their full (unclipped) form.

Rather than halting the reader, by default, this parameter allows the reader to continue reading and extracting features from the input GML document stream even after encountering a geometrical error.

A feature is assigned a coordinate system according to the first geometry that is read. If Yes, multiple geometries with different coordinate systems that belong to the same feature are reprojected to the feature's coordinate system.

This parameter allows the XML Schema documents that are fetched from the internet to be cached locally.

This reduces the number of network fetches when traversing the GML schema documents.

Determines the length of time that data should be stored in the cache.

This parameter is valid only if Cache XSD Documents is set to Yes.

The valid values are positive numbers that indicate the number of seconds. The default value is 300.

Read simple, multiple elements and values as a single fme attribute, instead of as list attributes. The values will be separated by commas.

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.

Using Web Connections

FME Options: Web Connections