TransXML Home
Project Information
Links
Contacts
Sources and Resources
GML Experiment
Construction/Materials Schema
Bridge Structures Schema
Survey/Design Schema
Safety Schema

Search:
Go 

Login
Register
NCHRP 20-64 XML Schemas for the Exchange of Transportation Data     
TransXML Home > GML Experiment > GML Experiment Discussion
Discussion Forum

Author Thread: Scope of GML Experiment
Frances Harrison
Scope of GML Experiment
Posted: Tuesday, November 09, 2004 5:29 PM (EST)

Purpose and Scope

GML is short for Geography Mark-up Language.  This is unfortunate in that it provides an equally valid approach to XML encoding for applications that have no geographic content.  It claims to be an “XML-based mark-up language used to encode information about real-world objects [features].”  These features can be concrete (tangible) like roads and bridges or abstract like property or jurisdictional boundaries.  Features have properties.  Geometry can be a property of a feature.  In fact, a feature may have multiple geometrical representations of different types or levels of precision.  Though developed at the Open Geospatial Consortium, GML has been submitted to ISO for acceptance as one of the TC211 191xx family of GIS related standards.  GML is the format for request and response messages for OGC Web Feature Services (WFS).

We have done a preliminary evaluation of GML to determine whether we should use it as the foundation for TransXML.   The advantages we discovered include:

·         XML Schema compliance: a GML schema follows the XML schema standard so GML is XML;

·         Emerging presence in the Geospatial market;

·         Object/property orientation makes it applicable to enterprise wide application, transcends conflicting and limiting CAD/GIS graphic representations, and provides a consistent approach for non-graphic as well as graphic entities;

·         Designed to be a foundation on which specific industries, like transportation, are invited to develop domain specific application schemas, with the resultant schemas more likely to insure interoperability within a single application area as well as between multiple areas;

·         Providing a common foundation across all TransXML schemas would provide the desired consistency and would allow this initial project to achieve more than would otherwise be possible.  For example, many base types are already defined for us, including features and feature relationships, linking, geometry, coordinate reference systems, topology, temporal, metadata, and presentation style;

·         A GML encoding of LandXML has been accomplished and has already resolved many of issues of supporting a design based approach with GML; and

·         GML provides a mechanism for helping to smooth the transition between CAD and GIS. 

On the opposite side, we acknowledge the following disadvantages:

·         The false perception that GML is “geospatial” only – its object approach with geometry as an optional property of objects make it appropriate for non-spatial applications as well;

·         GML is not well known (yet) in the design market;

·         GML files can be larger than straight XML files – the LandGML experiment has already made progress in reducing the difference and more can be done.  There will be some overhead associated with the object requirement and the fact that GML prescribes elements whereas some XML encoders use attributes;

·         Though GML covers a very broad scope of geometries, we need to be sure it can handle the spiral and vertical (parabolic) curve profiles common to roadway design alignments.  OGC as well as the TC211 standards group who developed the geometry standards on which GML is based are interested in working with us to cover our engineering-specific requirements;

·         GML has a longer learning curve than “plain” XML schema;

·         GML therefore presents additional risk for the project which would need to be mitigated to insure successful, on-time completion.

Based on our evaluation, there are four possible options:

1.      Ignore GML for this project, allowing for future exploration later on

2.      Decide now to adopt GML for all new schemas that are developed

3.      Use GML for some new schemas (e.g. Safety Highway Information)

4.      Begin Phase II with a GML experiment to gain a greater understanding of the impact of using GML

It has been decided that we should move forward with option 4.   The proposed experiment will include the development of parallel XML and GML schema, instance documents, and extraction programs for a candidate application area which includes spatial as well as non-spatial information, such as terrain surface modeling.   From this experiment we should be able to evaluate:

·         the difference in effort required to use GML vs. straight XML – is there added effort for using objects with GML and is this offset by savings in using standard, predefined GML types?

·         the difference in resultant file size of the instance documents to see if this is significant and if so, to see if this can be remedied

·         the difference in clarity of the schemas and instance documents to see if any added complexity makes them easier or harder to understand

·         the difference in effort required to parse the two documents

·         whether the use of a more structured GML approach reduces ambiguity

·         can what GML provides be used across all of our proposed schemas?

Based on these factors, we will be able to draw conclusions as to how the use of GML would help or hinder TransXML’s goal of providing data interoperability, and how it would help or hinder the ability to gain broad acceptance of TransXML schema.

From the results of the experiment, the team will report our findings to the panel, including comments received from stakeholders and make a recommendation on whether or not to proceed with GML. 

Base Schema/ Standards

Existing schema and/or standards that this will be based on include:

·         LandXML 1.0

·         LandGML

·         ISO TC211 19136 Geographic Information – Geography Markup Language (GML)

Resource Documents

·         Crews, N., E. Hall, and D. Rebolj, LandXML Schema Version 1.0 Reference, 2002.

·         Crews, N., LandXML-1.0.xsd

·         Burggraf, D., LandGML0.6.xsd

·         ISO, ISO/TC 211/WG 4/PT 19136 Geographic information – Geography Markup Language (GML), ISO CD 19136, February 7, 2004.

·         Ron Lake, David S. Burggraf, Milan Trninic, and Laurie Rae, Geography Mark-Up Language, John Wiley & Sons, Inc., San Francisco, CA, 2004.

Sample Applications

Proposed application to be developed to demonstrate the use of this schema:

·         Develop an XSLT report of coordinate data from a surface model for use by machine control in human readable format.   This would basically consist of x, y, z coordinates along an edge of pavement, for example.


Comments:

Author Thread:
Steve Brown
Scope of GML Experiment
Posted: Wednesday, December 01, 2004 5:34 PM (EST)
Do we have some thing to look at yet, schema, or application code

     

Frances Harrison
Soon...
Posted: Wednesday, December 01, 2004 5:48 PM (EST)

Schema coming soon -still shooting for 12/3...

     

Jeff Thorn
Scope of GML Experiment
Posted: Monday, January 10, 2005 11:47 AM (EST)

 

Since facility operations and maintenance is a significant cost for transportation systems it would be good to assure that data to support ongoing operations analyses is included in the data compiled as part of the design and construction initiatives.

So, to address freeway and signal operations,  data such as highway facility configurations (alignment, # of lanes, “link desingations”, etc.) needed  for signal optimization and route allocations would be good to preserve from the initial design data. Currently, there seems to be proprietary network models that are used in applications such as Sychro / TransCAD /  TSIS / AIMSUN/  TRANSYT / etc... A standard network model , for use in the design stag , that can be used in all tranportation optimization and planning applications would be  a great....

Similarly, assuring design data  is preserved for the following would also be good:

- Multimodal facilities (train/bus  stations, ferry locations, air ports) operations.

- Transit route data.

- Hydrology networks.

- Communications networks. 

- Land use data and preliminary design data.

 

     

Todd Bergland
Scope of GML Experiment
Posted: Tuesday, January 11, 2005 7:20 AM (EST)
I was unable to get the executable to work in the zip that I downloaded for the GML experiment. Any thoughts on what may be causing the error?

     

Paul Scarponcini
Scope of GML Experiment
Posted: Thursday, January 13, 2005 7:17 PM (EST)
Jeff, As we reviewed existing XML schemas in Transportation, the only one we found that had any topology was LandXML. Unfortunately, it is limited to feature-based topology (pipes and manholes). We documented its lack of a generic topo model like link-node for linear topology which I believe is what you are asking for. However, because of our limitiations on budget, we were not able to include this in our project scope. However, part of the project is to establish a process for developing additional schemas once this particular project ends. Hopefully support for topology can be accommodated at that time. By the way, an ISO standards group is just now trying to standardize how topology can be represented in a relational database using SQL. I can include you on that mailing list of you are interested.

     

Jens Winslow
Scope of GML Experiment
Posted: Monday, January 24, 2005 1:54 PM (EST)

Our (Sensors & Software’s) interest in TransXML is in it’s possible use as a standard for dissemination of asset condition information (we build Ground Penetrating Radar (GPR) units which can be used to measure sub-surface conditions like asphalt thickness, cracking, substrate, bridge inspection, etc).

 

It was therefore disappointing to us that according to Mr. Harrison “Asset condition information is not in the Phase II scope for TransXML”. We hope future development of TransXML will cover this area, and it seems GML is already supplying a framework for this kind of information (but not a standard for dissemination).

 

Since it seems that infrastructure condition information can be described within GML, we would prefer if TransXML “fits” within GML as a “valid” subset, probably as schemas using some of the GML schemas.

 

It seems that too many standards will lead all to fail by fracturing the industry, so every effort should (IMO) be made to keep GML and TransXML compatible, if not “merged”. The success and problems solved by LandXML when using GML indicates the potential benefits of TransXML using GML where possible.

 

The only drawbacks I see are:

1)

Established TransXML code / projects that may not fit GML schemas.
I believe that this problem is unavoidable; as TransXML evolves and matures existing projects will become “dated”. This should not be a reason to avoid future improvements, be they GML or not. Indeed the sooner we implement improvements, the fewer legacy problems we will have and the longer standard will “hold“.

 

2)

Complicating standard.
This is probably more important than 1). A complicated standard stands little chance of acceptance and use. However, if theTransXML “experts” who are developing standard makes it GML “compliant” / supportive, it seems to me that users of TransXML who do not want / need GML will not have to learn it. They just follow the TransXML schemas.

 

I therefore think TransXML should endeavor to be as GML compatible as possible, probably by becoming schemas that use the GML schemas where possible.

 

Jens Winslow, P.Eng.

     

Al Butler
Scope of GML Experiment
Posted: Tuesday, January 25, 2005 9:35 AM (EST)
Have you examined the possible limited use of GML for only those applications and/or data sets where geometry may be useful?  My thought is to make the normal attributes XML compliant, and then to support geometry extensions that are GML compliant.  Real-world feature identifiers would establish the foreign key relationship.  This approach should allow lighter weight classes for non-geometry attribute exchanges.  I am not aware of any restriction as to the mixing of XML and GML object classes.  Thus, there may be no reason to make an all or nothing decision about GML use.  What are your thoughts on this mixed approach?

     

Paul Scarponcini
Scope of GML Experiment
Posted: Tuesday, January 25, 2005 2:32 PM (EST)
All classes in the GML Experiment were modeled as GML "features", allowing them to have geometry. However, there is a "lighter weight" alternative, GML Object, for classes which will never have a location attribute. They still get ID's and optional name and description attributes. This would allow us to remain consistent with the other GML rules for application schemas.

     

Al Butler
Scope of GML Experiment
Posted: Tuesday, January 25, 2005 3:01 PM (EST)

Many data sets have location descriptions without geometric representations.  When you say “never have a location attribute,” are you referring to geometry or to any kind of location description, including a linear LRS location (e.g., route and milelog measure)?

Incidentally, my suggestion about using XML for much of the standard was in reference to the general discussion of implementation difficulty, not simply to deal with geometry or the lack thereof.

     

George Cassles
Scope of GML Experiment
Posted: Friday, January 28, 2005 11:08 AM (EST)
Would it not be better to copy all of the GML geometry definitions, which are needed, out of the Geometry core schemas and situate them in TransXML. That way they would assume the same level of importance as all of the other elements of TransXML and could be used by all of the TransXML schema. Thus the only part of GML which would be used is the core schemas which establish object oriented operation. this would seem to be a better solution than subordinating every type of transportation data to geographical schema simply because they happen to need location information as a minor and subsidiary part of their definition.

     

Paul Scarponcini
Scope of GML Experiment
Posted: Saturday, January 29, 2005 3:49 PM (EST)
What you are suggesting in your first two sentences is achieved by a single import statement (see GML Experiment Summary Report for an example). I am a bit confused about what it is that you are suggesting is good or bad in the last sentence. Object oriented structure can be achieved in XML with or without GML (JusticeXML for example uses it). And transportation entities can be supported in GML without any geometry at all (object vs. feature). Unlike traditional GIS, in GML you do not create a geometry and then add attributes to it. You create a feature and add attributes, one of which is geometry - if appropriate. If you choose to use a linear location as Al suggests, you can do this instead of geometry. If geometry is not applicable, use an object instead of a feature. So I am not sure what you mean by "subordinating to a geographical schema." Perhaps you can help clarify this?