Response to Call For Comments

Search:
Go

Login
Register

Discussion Forum

Notify me of new comments

Author

Thread: Response to Call For Comments - 20050124

Jeff Thorn

Response to Call For Comments - 20050124
Posted: Monday, January 24, 2005 1:39 PM (EST)

The response to questions sent in the e-mail title “Call for Comment - Use of GML for TransXML“are noted in bold.

a. Can GML be successfully used for the non geo-spatial elements of transportation data?
Yes, and ideally a data model developed for use would highlight the source for all data. What could be considered the short comings of previous system modeling and deployment work is lack of comprehensive models showing where all the data comes from. What is being considered geographic data modeling is really just more comprehensive data modeling and for the initiative to be useful it needs to be comprehensive...

b. Would using GML make it less likely for TransXML to be widely adopted?
Opinion - Inconsistancies with commercial products, existing system implmentation or lack of implementation procedures with test tools would make it less likely for any technology not to be implemented.

c. Would using GML make it more difficult for developers writing applications to produce or consume TransXML?
Watching the evolution of XML / web services / etc. it seems that although the new techologies have benefits they also require implementations of “additional services” or resources that are different from existing technologies and solutions. Standards documents on occasions do not include documentation of key points needed for system and technology implementations and more frequently don't include system resources or test tools needed for system implementation and testing.

d. Would using GML make it more difficult for TransXML schemas to integrate with other related schemas?

Although, there are tools and programming methods to manage those schemas “readily“ it seems the key issue is how readily the innovations can be used with the existing technology infra-strucutre....

If the following issues are being represented as benefits for the GML technology then there is a need for more explicite documentation of the representations, especially for the items:

2. GML would provide a consistent structure for TransXML schemas.

5. GML is gaining rapid international acceptance.

The following issues need to be considered from more of an operations / current technology implementation perspective instead of a pure “standards acceptance“ persepective:

6. GML can be processed by emerging software such as the Open Geospatial Consortium WebFeature Server.
7. GML is currently undergoing the rigorous ISO certification process to become an international standard.

Innumerable spatial referencing methods and data models exist. It would be best if any further modeling work would, first address how any new approaches, are really improvements from previous methods and how the new approaches will integrate legacy data or other methods...

As a general comment on the TransXML initiative, more emphasis on preserving data for operations purposes, from the current TransXML/GML initiative is needed.

Comments:

Author Thread:

Lynne Randolph

Response to Call For Comments - 20050124
Posted: Monday, January 24, 2005 2:55 PM (EST)

Using GML to define those parts of transXML which would be appropriate (e.g. geolocation) does not appear to offer significant benefits. Geolocation data, while mandatory for a number of items in transportation schema, should not dictate how the schemas are developed. The report shows that GML could be used to provide this data, but I feel that the TransXML initiative would be better served to develop this locational data as a schema within TransXML. This allows elements and attributes of the schema to be modified to suit the transportation industry. Attempting to force the TransXML schema to conform to the GML dictates creates cumbersome XML schemas. Having a set of schemas that are TransXML specific also allows the transportation industry to dictate that various vendors implement those schemas in order to win contracts.

Al Butler

Response to Call For Comments - 20050124
Posted: Tuesday, January 25, 2005 9:57 AM (EST)

I agree that the field-recoverable location descriptions must be defined outside the geometry itself for non-geometry spatial analyses to be accomplished. Geometric representations are not needed for, say, linear LRS coincidence studies, where route identifiers and measures are sufficient to define coincidence and overlap without the overhead of geoemtric operators. Since there are many variations on linear LRS structure, the data set should contain the mandate for LRS descriptive information sufficient to understand the approach used, particularly if there are multiple methods within a single data set. (Of course, the profiles must also include a way to describe the facility attributes being covneyed, such as the meaning of values in a coded domain.)

As I suggested in a separate posting, it is possible to isolate the use of GML to geometric data objects, thereby limiting the impact of that technology to those cases where geometry is truly useful. The relationship of geometry to transportation facilities must also be defined within the context of the linear LRS given that these relationships may not be one to one; e.g., when a facility is represented by carriageways or completely decomposed into a set of geometric objects in a CAD file.

One method to convey and reconcile multiple linear LRS methods is to support equivalencies, such as to say that a project centerline stationing measure corresponds to a particluar milelog measure, or to say, for instance, that this roadway link is equivalent to a range of measures (defined as a pair of start & end measures, with direction implied by ordering). The role of geometry in the standards should be minimal and not determinant.

Topology should be separated from the geometry in order to allow easier manipulation and application of these data. Link-node databases, for example, are easily conveyed without reliance on geometry and are familiar to traffic modelers and maintenance staff, who have often relied on schematic drawings for abstract representation of network facilities; e.g., straight-line diagrams. Indeed, many traffic models do not have a one-to-one relationship between facilities in the real world and those within the model, and may frequently include facilities that do not yet exist. A geometric topology data model actually hinders the efficiency of these analyses.

Conveyance of facilities, attributes and their metadata, linear LRS metadata, and topology in XML appears to offer the benefits of faster implementation and simpler application development without restricting the ability of others to deploy GML for those instances when geometric representations are useful.