|
|
|
Innovative Technologies
|
An XML- Drivern Data Translation Engine for GML 2.0
The above feature mapping-rule deactivates when the element’s end
tag is read. The geographic feature that is constructed is vacuous: it has no feature-type,
attributes nor geometry. The following is a textual representation of the vacuous feature (it is an
actual log of the geographic feature from the data translation hub):
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Feature Type: `'
Attribute(string): `xml_type' has value `xml_no_geom'
Geometry Type: Unknown (0)
=====================================================
The feature-type and attributes of a geographic feature may be constructed by adding a
The xfMap’s element allows extraction of information from the input
data document. Because the input data document is read in a streaming manner, the
element can only locate and extract information from a sub-tree of the data document whose root
element start tag caused the activation of the mapping-rule. In the case above, the two
elements can only extract information from Fragment1’s and child elements.
The xfMap’s element sets the feature-type for the geographic
feature. In Fragment3, the element under the element pulls in the
content of Fragment1’s element and sets this content as the feature-type of the
geographic feature. The feature-type for the geographic feature is set to “City”.
The attributes of the geographic feature are set by the xfMap’s
element. An element can contain one or more . Each has a
and a . The feature mapping-rule in Fragment3 specifies one attribute for the
geographic feature. The name of this attribute, “featureCode”, is set by the element; it is
the string value specified by its “expr” attribute. The value of the “featureCode” attribute is set to
be the content of Fragment1’s element, “1234”. The textual representation of the
geographic feature constructed by the feature mapping-rule in Fragment3 is:
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Feature Type: `City'
Attribute(string): `featureCode' has value `1234'
Attribute(string): `xml_type' has value `xml_no_geom'
Geometry Type: Unknown (0)
=====================================================
The geographic feature still lacks geometry. The geometry for a feature can be constructed by
adding an xfMap’s element to a feature mapping-rule:
The following is a textual representation of the geographic feature constructed by
Fragment4’s feature mapping-rule on Fragment1’s element. Notice that a twodimensional
point geometry feature with coordinates (10,0) is constructed:
+++++++++++++++++++++++++++++++++++++++++++++
Feature Type: `City'
Attribute(string): `featureCode' has value `1234'
Attribute(string): `fme_geometry' has value `fme_point'
Attribute(string): `xml_type' has value `xml_point'
Geometry Type: Point (1)
Number of Coordinates: 1
Coordinate Dimension: 2
Coordinate System: `'
(10,0)
============================================
In Fragment4, the element in the feature mapping-rule directs the
XML translation engine to construct a point-geometry for the geographic feature by using the
“xml-point” geometry builder. The XML translation engine contains several predefined
geometry builders that are format neutral. These geometry builders are capable of constructing
point, line, area, and aggregate geometries. In addition, the XML translation engine can be easily
extended with new format-specific geometry builders as need arises. Every geometry builder
receives the information that it needs from the xfMap’s element’s elements.
The “xml-point” geometry builder requires a element whose “name” attribute must be
“data-string”, and its value must be the coordinate string sequence to parse. The “xml-point”
geometry builder also accepts other optional elements, which can be used to specify the
coordinate string sequence’s dimension, the character(s) that separate each coordinate, the
character(s) that separate each axis of the coordinate, the order of the axis of the coordinates (for
example, x, y, z, or y, x, z, etc…), and the decimal character for each coordinate (for example,
“.”, or “,”). The names and values for the elements are geometry builder-dependent.
The and elements are called “expression elements”. Several of
the elements in the above feature mapping-rules had expression elements as their children; these
included the xfMap’s , , and elements. An xfMap element
that accepts an expression element actually accepts a sequence of them. The element in
Fragment4 has a sequence of expression elements that consists of an , a and
an element; the “xml-point” geometry builder will receive the string “10.0,0.0” as the
value of its “data-string” data parameter. There are several expression elements that were not
illustrated in the above mapping-rule fragments: , , and
.
The XML translation engine uses the xfMap’s feature mapping-rules to map the
XML elements into format-neutral geographic features. This allows for flexibility since the XML
translation engine is not hard-coded for any particular XML format. The engine allows the
processing for different type of XML based documents into geographical features without the
need to write a new software module in a traditional programming language. Any GML dataset
based on an arbitrary GML user application schema can be processed once an appropriate xfMap
is written.
The XML Translation Engine
The XML translation engine facilitates the reading of arbitrary GML user
application schema datasets as it can interpret arbitrary XML elements with an appropriate
xfMap. The xfMap can either be written manually or generated automatically through the
examination of the GML user application schema documents. The GML 2.0 Recommendation
xfMap
provides rules and guidelines for users to define their own application schemas with the W3C
XML Schema. These rules and guidelines make it possible for a software module to perform
type discovery on a GML user application schema. A user may know if an XML element
represents a feature, a feature’s properties, or a feature’s geometric properties by following the
type hierarchy for that element in the GML user application schema. When an author creates a
GML user application schema, each of its new feature types, feature collection types, geometry
types, and geometry property types must ultimately derive from some of the base types provided
by GML. By walking through the type hierarchy, application software can discover what each
element in the GML document is supposed to mean.
One can envision a software module that is capable of reading any arbitrary GML
user application schema dataset by examining the type hierarchy of a schema to automatically
generate an xfMap that maps GML features into the XML translation data engine geographic
features.
The GML user application constrains the interpretation of the XML elements
from a GML document into a well-defined geographic context. This well-defined GML
geographic context can be transformed with an xfMap by the XML translation engine into the
engine’s neutral geographic features.
The GML Translation Engine
Implementing the XML and GML translation engine
The XML translation engine leverages the free parsing utilities that are available
in the industry. It uses both common XML parsing APIs, namely the DOM and SAX APIs. The
DOM API is use to read in the xfMap mapping-rules, while the SAX API is used to read the
actual input XML data document in a streaming manner. The consequence of this is that the
XML translation engine can handle arbitrarily large XML documents.
The GML translation engine allows the processing of GML datasets that are based
on arbitrary user application schemas. We’ve implemented an API that provides access to a W3C
XML Schema document because most of the free cross-platform XML parsers available do not
provide such an API. This API allowed us to perform type discovery on the W3C XML Schema
document to discover what each of the elements in a GML document represents. Type discovery
allows the GML translation engine to automatically generate an xfMap document that is used in
conjunction with the XML translation engine behind the scenes.
The XML translation engine is coupled to a general-purpose data translation hub;
this hub can take the format-neutral geographic features output by the XML translation engine
and translate them into a large array of GIS formats. The hub is capable of performing a large
variety of sophisticated transformations on geographic features. These include topology,
geometry, attribute, and coordinate system transformations. The hub also provides an API for all
of the transformations that the XML translation engine exposes through the xfMap’s “group
mapping-rules”. Briefly, the group mapping-rules allow further processing of the topology,
attributes, and geometry for the geographic features constructed by the feature mapping-rules.
For example, the feature-mapping-rules may be used to map the XML elements into geographic
primitives, while the group-mapping rules may specify geometric operations to construct the
topology of the dataset from the geographic primitives.
The data translation hub to which the XML translation engine is coupled is Safe
Software’s Feature Manipulation Engine (FME). The XML translation engine utilizes two of
Safe Software’s APIs: the Plug-in Builder API and the FME Objects API. The Plug-in Builder
API is used to enable XML to be translated into any of the FME-supported formats. The FME
Objects API is used extensively in the implementation of the group-objects that group mappingrules
create. The FME Objects API allows the group-objects to access all of the FME feature
factories and feature functions. The GML translation engine also uses the FME Objects API to
embed the XML translation engine to read GML documents. Additional benefits of using the
FME APIs are that the FME Universal Viewer can readily view the XML-based formats; and
other software applications can also embed the functionality of the XML and GML translation
engines into their systems.
Conclusion
The XML translation engine replaces complex programming code with xfMap
mapping-rules for the interpretation of XML elements. The XML translation engine can be used
to read datasets from any arbitrary GML user application schema. This process can be automated
when a type discovery module is used to analyze the schema for the automatic generation of
xfMap documents. The XML translation engine enables new XML-based formats to be
supported in time that can be measured in hours rather than in weeks. The GML translation
engine enables GML datasets to be supported instantaneously.
References
Bray, T., Paoli, J., Maler, E., and Sperberg-McQueen, C.M., 2000,
Extensible Markup Language (XML) 1.0, Second Edition, W3C
Recommendation, http://www.w3.org/TR/REC-xml.
Cox, S., Cuthbert, A., Lake, R., and Martell, R., Geography
Markup Language (GML) 2.0: Open GIS Consortium Inc.,
http://www.opengis.net/gml/01-029/GML2.html.
Safe Software Inc., XML Reader: xfMap, Feature Manipulation
Engine (FME) Readers and Writers,
http://ftp.spatialdirect.com/fme/2002sr1/docs/ReadersWriters2002SR
Thompson, H.S., Beech, D., Maloney, M., and Mendelsohn, N., 2001,
XML Schema Part 1: Structures, W3C Recommendation,
http://www.w3.org/TR/xmlschema-1/.
|
|
|
|
