A Framework of Feature-Level Transportation Geospatial Data Sharing Systems, ZR Peng

Tags: CD-ROM Paper, feature level, data extraction, geospatial data, data sources, transportation applications, Model Feature, Geo-spatial Web, uniform data access, data integration, common data format, private Web portals, ESRI, Web portal, Web portals, data sharing system, data source, data exchanges, OGC, Web Server, OpenGIS Consortium, spatial data set, feature type, WFS, NSDI Clearinghouse, data exchange, Web Feature Server, OGC Web Feature Server, data sharing, street segment, transportation application, spatial data model, Department of Geography, feature elements, bus route, Feature Members, feature member, street segments, applications, GML data server, Stanford Digital Library Metadata Architecture, feature collection, Geography Network, Washington Sate Department of Transportation, Portland State University, References Baldonado, transportation framework, Chuanrong Zhang
Content: A Framework of Feature-Level Transportation Geospatial Data Sharing Systems Zhong-Ren Peng, Ph.D. Department of Urban Planning University of Wisconsin-Milwaukee PO Box 413 Milwaukee, WI 53201-0413 [email protected] Revised November 8, 2002 Submitted for the 82nd Transportation Research Board Annual Meeting
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
A Framework of Feature-Level Transportation Geospatial Data Sharing Systems Zhong-Ren Peng, Ph.D. Department of Urban Planning University of Wisconsin-Milwaukee PO Box 413 Milwaukee, WI 53201-0413 Abstract Current data sharing in the Internet environment is mainly in the form of data clearinghouse approach, which has two fundamental shortcomings. First it provides information about the availability of data regardless of data model used and data formats, therefore, users still have to face the challenge of integrating data from different sources and in different formats. Second, the data clearinghouse approach provides data sharing at the file level; it does not provide spontaneous data access and data exchange at the feature level. Thus, data update at one source cannot be instantly made available to the data users. This paper provides a framework and a prototype to develop a transportation geospatial data sharing system at the feature level. This framework is based on the Geography Markup Language (GML) to code and transport geospatial data, the Web Feature Server (WFS) to extract and manipulate data at the feature level, and the Scalable Vector Graphics (SVG) standard to display GML data on the Web browser as maps. The transportation geospatial data sharing system would allow the data providers to provide their data according to a standard data model and framework, so that attribute data about a particular feature can be exchanged. It also allows the user to access and extract data from distributed sources based on a spatial feature. Key Words: XML, Geography Markup Language (GML), data sharing, Web Feature Server (WFS), Scalable Vector Graphics (SVG), Geospatial One-Stop
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
Assume you are doing an emergency response operation that deals with truck accident with hazardous materials on a road segment. You need information about road conditions, land uses, parcel occupancy data, environmental data, transit services data that are managed by different departments. This is currently very difficult or even impossible to do, particularly at the spatial feature level. Traditionally, you would have to request data from different data sources and wait for data administrators to copy and send the data to you. Data coming from different departments may have different representation of the same road segment, in different geo-reference systems, and in different formats. So the road feature may not match with each other at all from different data sets. In addition, you may be given full data sets, rather than the specific road segment and its surrounding areas that you are interested in. This is okay for non-time-critical analysis, but it would be useless for real time emergency response operations. Now imagine that you need only go to one Web site that make one request about what attribute data elements you need for the specific road segment, the Web site would go to different data sources and automatically extract the exact data elements that you need for the specific road segment in real time. You can then either access to the data directly and display the data on your Web site for visualization or download the data to your desktop for emergency operations. Can you do that? Not yet. But we are close to it. In fact, this is a vision of the Geospatial One-Stop, an E-Gov initiative (http://www.bts.gov/gis/geospatial_onestop/index.html). This paper discusses a framework of how this vision can be accomplished. It will focus on a development of an open system that relies on national and international standards. Introduction Data sharing has been a hot topic being widely discussed over the last few years (Dueker, 1995; Onsrud and Rushton, 1995). There are three major issues in data sharing: data access, data representations (or data models), and data formats. Data access refers to means of accessing transporting geospatial data. Data representations refer to data models used to represent real world phenomenon. Data formats refer to data coding and data structures. Many researches have been reported in the literature on ways to improve data access, data models and data coding to facilitate data sharing (Dueker and Bender, 2002). For example, the Geospatial Data Clearinghouse Activity (http://www.fgdc.gov/ clearinghouse/) under the management of the U.S. Federal Geographic Data Committee (FGDC), the Alexandria Digital Library, and the Geography Network (now the g.net) managed by a private company ESRI Inc. are prime examples of trying to improve data access and make geospatial data available online. The primary purpose of this data clearinghouse approach is to facilitate data access. But they did not address issues of data representation, data model and data quality. They simply provide the data or tell you the availability of data and give you the contact information.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
The data clearinghouse approach makes searching and accessing data easier. But there are a number of problems with this approach. First, the data in different department may use different ways to represent the same geographic feature, use different data models, different geo-reference systems and different coordinate systems. For example, the highway asset management system may use the linear reference systems like a milepost system, while the emergency response data may use the spatial reference system like latitude and longitude. It becomes a challenge to integrate data that come with different data models or linear reference systems. Second, the data exchange is not spontaneous or in real time. That is, the user has to obtain data from different departments, and in most cases, convert them into a uniform format. The update of data at one source cannot be instantly available to users in other departments or other organizations. For example, the emergency response data (e.g., incident data) may be updated on the daily basis. But that update may not be available instantly to the asset management department who has already downloaded the data weeks or even months ago. There are a couple of efforts in the United States going on to address these issues. One is the National Spatial Data Infrastructure's (NSDI) Framework Transportation Identification Standard effort; the other is the Geo-Spatial One-stop initiative. The NSDI Framework Transportation Identification Standard (http://www.bts.gov/gis/fgdc/web_intr.html) is a conceptual data model standard that is being developed by the FGDC Ground Transportation Subcommittee. The proposed framework transportation identification standard uses road segment (called Framework Transportation segment or FTSeg) to unambiguously identify a road segment feature in the real transportation network. The FTSeg is a unique geo-spatial feature that is independent of any cartographic or analytic network representation. Each FTSeg begins and ends at a Framework Transportation reference point (FTRP) and has a unique identification code (FTSeg ID). These road segments will form the basis for data exchanges among different data sets that may have been collected in different scale and stored in different formats. So attribute data such as incidents for the same road segment (FTSeg) can be exchanged with another attribute data (like traffic volume and speed) that are stored in another data set but for the same road segment (FTSeg). But the proposed NSDI Framework Transportation Identification Standard does not address the issue of data access, data extraction and the mechanisms of data exchange, which are left for individual implementation of the GIS software. The Geospatial One-Stop initiative, an E-Gov initiative from the Office of Management and Budget (OMB), goes a step further. It not only addresses the data interoperability issue, but also the data access, sharing and distribution issues. The goal of the Geospatial OneStop is to establish a comprehensive web portal, with "one-stop" Internet access, to the National Spatial Data Infrastructure (NSDI) seven-framework of geographic data. This one-stop Web portal will allow data providers to advertise or make available their data, and allow users to extract data from different data providers at their sources (http://www.bts.gov/gis/geospatial_onestop/index.html). The Bureau of Transportation Statistics (BTS) is responsible for developing standards to integrating the transportation framework theme within the NSDI seven themes into the Geospatial One-Stop. BTS has assembled a team of transportation professionals (Modeling
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
Advisory Team, or MAT) to develop a core data content standard for each mode (highways, railways, air, and transit) of the transportation framework theme. The first MAT meeting for the highway mode was held in Washington DC in July 16 ­ 18, 2002 to draft a core data content standard for highways and roads (The author is a member of the team). It is expected that the core data content standard, once approved, will become a national standard for the exchange of transportation geospatial data. Besides the development of a core data content standard, the other task is to develop tools to provide for easier data sharing on the Web. Once the core data content standard, or at least a draft, is established, BTS will work with the Open GIS Consortium (OGC) to create an open, interoperable prototype portal for transportation data. This Web portal will provide an one-stop Internet access point to transportation geospatial data. This paper intends to provide a framework of developing an one-stop Web portal for data sharing and data exchange, based on the core data content standard proposed by the Geospatial One-Stop MAT, OGC's interoperability standards and specifications, particularly, the Geography Markup Language (GML) and Web Feature Services (WFS). A prototype will also be provided to implement the framework. Why We Need a Feature-level Transportation Geospatial Data Sharing System Transportation geospatial data have been created and maintained by all levels of government in many locations and in a lot of proprietary formats. "Exchanging data between, and sometimes within, the same organization is recognized as a labor-intensive and problematic endeavor (http://www.bts.gov/gis/geospatial_onestop/index.html)." A standard Web portal will allow data users and providers in different levels of government and private sectors to share and exchange data. It provides a potential mechanism for all data users and providers to form data acquisition and exchange partnership. But we already have several geospatial data portals, particularly the Federal Geospatial Data Committee's (FGDC) Clearinghouse Activity on the government side and the Geography Network by ESRI on the private side. Why do we need another geospatial data Web portal? The FGDC's Geospatial Data Clearinghouse Activity The Clearinghouse Activity provides a framework for individual governmental agencies, consortia, private sector and academic institutes to advertise, share and access each other's available data. The Clearinghouse framework is a distributed system, meaning that the data are located in the servers of the data providers, but the users can search and access all the data servers from a single user interface on the Web. The different data servers are called nodes. They have many clearinghouse nodes established nationwide since 1995, helped by the National Spatial Data Infrastructure (NSDI) Competitive Cooperative Agreements Program.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
The FGDC's Clearinghouse was designed for sharing and accessing geospatial data. It assumes that the users are GIS professionals and would be able to take care of the data format, data quality, and data usage issues. So the Clearinghouse makes no attempt to integrate and transform the original data. But the issues of data consistency and data integration do not go away, even for GIS professionals. These issues are becoming more serious as casual users that have no experience or training with the data or the software are beginning to use the geospatial data on the Web. The Geography Network and G.Net The Geography Network is a collaborative and multi-participant web-based GIS portal for publishing, sharing and accessing digital geospatial information. The Web site, GeographyNetwork.com, was introduced by ESRI in June 2000. The development of the Geography Network is originally derived from the ESRI's ArcData Online program and the development of ArcIMS software for on-line mapping functions (ESRI, 2001). The role of the Geography Network is very similar to the FGDC's NSDI Clearinghouse, but the Geography Network focuses more on the proprietary technology implementation, and is owned by a private company ESRI Inc. Through the Geography Network, GIS users can search and access geospatial data, publish their own data, or provide Internet mapping services by using ArcIMS software or OGC's WMS protocols (http://www.geographynetwork.com/). G.net is a new architecture proposed by ESRI in 2001 for sharing and accessing geographic information in distributed network environments. It is based on Microsoft's .NET framework to provide users to access multiple geospatial web services from one access point. Notice both the NSDI clearinghouse activities and the private Web portals, including ESRI's Geographic Networks and g.net, do not address the issues of data consistency and data exchange. That is, it simply provides searches for existing data files based on the metadata regardless of data quality, contents and formats. The data users have to deal with these issues themselves. Furthermore, both NSDI clearinghouse activities and private Web portals simply offer you the whole dataset; it usually does not offer data extraction at the feature level. For example, they do not offer the possibility of extracting the attribute data for a specific road segment from different data sets. This is fine for non-time essential applications, but offering spontaneous data exchange at the feature level is crucial for timecritical applications such as Homeland Security and emergency responses. Both the NSDI clearinghouse activities and the private Web portals stress the importance of metadata. A good metadata could help the data users to better understand and use the data. Current metadata is at the file level, not at the feature level. Therefore, it is not enough for instant data exchange at real time. For example, if one street segment is represented by dynamic segmentation in one database, but is represented by node-segment model in
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
another database, even though there are specified in the metadata, how would the application know there the same street segment? Therefore, we need to develop a new kind of data sharing services that provides consistent data, i.e., data that are consistent from different data sources, and offers data extraction at the feature level. This paper describes a framework of this new kind of data sharing services to support many web-based applications that need spontaneous data exchange over the Web. Required Components of a Transportation Geospatial Data Sharing System A geospatial data sharing system is a distributed service. There will be one uniform data access point (hence the name Web portal) but the data will be located at different places on the data sources. Therefore, we need a consistent data framework for spatial feature identification and description. Since there is only one uniform data access, we need a uniform way of coding, transporting and presenting the data elements that may come from different sources. Furthermore, we need a mechanism to serve data on the data source, and a data extracting function to extract data at the feature level. Common Feature Identification and Descriptions In order to extract data from different sources for the same spatial feature, there have to be a common feature identification and description. This is addressed by the NSDI's Framework Transportation Identification Standard (FTSeg and FTSP), and the Geosptial One-Stop Initiative's feature identification model, TranSeg (the same as FTSeg) and TransPoint (the same as FTSP). If there is a common feature identification, data from different sources can then be consistent and integrated easily. This is essential for data extraction at the feature level. Common Data Coding and Transporting over the Internet Most data are currently stored in different formats. This is actually the most important factor that causes difficulties of data exchanges. To facilitate data integration from different sources and with different formats, we need a common data format.Extensible Markup Language (XML) or more specifically, Geography Markup Language (GML) is a good choice to code data from different sources into one common data format. With GML, for the same spatial feature, there will be the same feature elements, which can make data extraction easy. For example, if the same road segment ID for the same feature in different data sets, the GML can code them as the same feature ID. The data extraction program can then easily extract the same feature from different data sources based on the same feature ID. Furthermore, the Xlink and Xpoint in the GML can link one feature with another feature within a database or with different database. This offers the flexibility of coding the
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
same feature with different IDs, or creating an equivalent table as in the NSDI's Framework Transportation Identification Standard. But almost all transportation geospatial data are not in the GML format. Without a substantial financial support, no data provider would have the incentive to convert the data from its current format into GML. What can we do? Fortunately, there is GML data conversion software that can be used to convert data from other formats to GML format. We could either convert all the data set into GML before data extraction or just convert the requested data elements into GML after the data extraction. Data Extracting and Serving To make the data available on the Web, we need a data server to serve data and spatial features. The data server must have two basic functions: making the data available for remote data users, and being able to respond to user requests to extract data at the feature level. There are many data servers, such as Oracle, Microsoft SQL Server, and OGC's Web Map Server and Web Feature Server. Data Presentation on the Web Browser On the client side, user interfaces are needed for the user to input queries and to view data query results. Since we are talking about Web portal, it is natural to expect the user interface as being Web-based. However, the problem of Web-based interface is that the traditional geospatial data cannot be interpreted as maps on the Web browser without a proper plug-in. To address this issue, we need an intelligent "agent" or a parser to interpret the data transmitted from data servers. For GML coded data, a map styling programs are needed that use certain graphic symbols, line styles and area patterns to display point, line and polygon features (Lake, 2000). The styling program is called a map styler or style engine. The XML Transformation Language (XSLT) is an example of a styler. It can be used to style GML data into an XML graphical display format such as W3C Scalable Vector Graphics (SVG), Vector Markup Language (VML), or the Web 3D Consortium's X3D. To view an SVG, VML or X3D graphic files, the user needs to have a graphic data viewer or renderer installed at the Web browser, such as an SVG viewer in Internet Explorer 5.0 or above, Adobe SVG Viewer, Java Applet SVG viewer, or SVG and X3D libraries. An Architecture Model of a Transportation Geospatial Data Sharing System An architecture model here refers to the framework of the data sharing system construct, including system components, functions of each component, the relationship between the components and the information flow among the components. An architecture model provides the framework of what kind of system is to be built and the functions the system
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
could have. An architecture model of a transportation geospatial data sharing system can be illustrated as in Figure 1. Each component in the model is discussed as below.
Web Server
Web Feature Server
Data Sources
GIS Users (Web Browser)
Catalog Server
Web Server
Web Feature Server
Data Sources
Web Server
Web Feature Server
Data Sources
Figure 1 An Architecture Model of a transportation geospatial data sharing system
User Interface
The basic user interface is the HTML-based Web browser. Users would use the Web browser to make data requests and receive the query results. But in order to view the results in the form of maps, the results have to be styled into a style file for display, and a SVG viewer must be installed to view GML coded documents. With the SVG viewer, the users can interact with the SVG map for further requests. For example, when the user wants to zoom or pan to a different area of the map, that request is then sent back to the data store, where the Web Feature Server will extract new features and send them to the Style Engine for styling. The styled SVG will be sent to the Web browser for display.
Catalog Service (Metadata Service)
Catalog Service is a registry to list the available data and their locations. It is also called metadata service. This is where a registry authority will store all metadata. The functions of the Catalog Service are to allow clients to locate data and spatial features of interest from different data servers over the Internet. Data providers have to first register with the catalog service in order for their data to be searchable by the users on the Internet.
Web Server
The major function of a Web server is communicating with the Web client via HTTP. It constantly runs on the server waiting for client requests. Once it receives a request from the clients for a spatial data set, a spatial feature, or a map, the Web server will pass the request to the Web Feature Server.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
Web Feature Server Web Feature Server is a specification by the OpenGIS Consortium for describing data manipulation operations on OpenGIS Simple Features (e.g., points, lines, and polygons) at the feature level. The operations include querying, extracting, creating, deleting and updating features that are stored in the GML documents or other data formats. The OGC Web Feature Server Specification defines interfaces required to support query and transaction operations on geographic features stored in web accessible OGC Simple Feature datastores. The basic architecture of OGC Web Feature Server Specification is shown in Figure 2. A client application such as a Web browser makes a feature request to the Web Server (HTTP server), which forwards the request to the Web Feature Server. A Web Feature Server has two major roles. First it translates client requests into the language of the target datastore, and then passes the requests to the datastore engine for executing. Second, it sends any results back to the client. The Web Feature Server reads and processes the requests by getting the feature data from the OGC Simple Feature datastore, and returns the result to the client in a feature set as GML. The datastore can be any type of system - SQL database, flat file system, GML documents, etc.
Client Application
HTTP Server
Web Feature Server
OGC Simple Feature Datastore
Figure 2 Architecture of OGC Web Feature Server Here is a very simple example of a client application requesting to retrieve feature instances from a datastore. In this example, all the properties of feature type "RoadType" are fetched for an enumerated list of feature instances. The element is used to reference each feature to be fetched. Besides , the OGC Web Feature Server Specification also specifies other query and transaction functions, such as to describe the structure of any feature type upon request; to process a lock request on one or more
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
instances of a feature type for the duration of a transaction; and to service transaction requests like create, update, and delete operations on features; to describe the capabilities of the Web Feature Server, such as which feature types it can service and what operations are supported on each. (For a detailed discussion, please see OGC Web Feature Server Specification at http://www.opengis.org/ogcSpecs.htm. The WFS's capability of accessing feature data and associated attributes over the Web is a great improvement over the OGC Web Map Server implementation, which only delivers a picture. It is this feature level data manipulation that makes WFS possible to query and extract data at the feature level. Furthermore, the WFS also supports transactions to create a feature, delete a feature, and update a feature. This capability provides a potential to conduct spatial analysis, modeling and other operations on the Web based on the spontaneous access to distributed geospatial data. Data Sources The OGC Simple Feature Datastore includes other data types besides GML document, so data providers don't have to recode every existing geodatabase into GML. But in order to serve the existing data as a valid GML document on the Web, middleware software like a WFS is needed to retrieve data from a geospatial database. Here there are two options. The first one is to use the WFS to make queries against the database and extract specific features, and to format the extracted features into GML format before transporting it to the client. The other option is to convert the entire geodatabase into GML and store GML document in a database. The WFS then extracts spatial features from the GML database. The first option is a preferred one since it does not involve the transformation of the whole original dataset. Implementation of a Transportation Geospatial Data Sharing System ­ A Prototype Based on the above discussed architecture model, a prototype geospatial data sharing system has been created. Two separately resided data sets, the street network and the transit network of the City of Waukesha, Wisconsin, have been used for the experiment. The Data The street network is consisted of two basic components, road segments (TranSeg in MAT's term or FTSeg in NSDI's transportation framework standard's term) and nodes (or TranPoint in MAT's term or FTPT in NSDI's transportation framework standard's term). In addition, in order to minimize the number of foreign keys, and for better management of segments in a road network, a permanent link ID is specified as a set of segments having a common street name or road number. Thus, individual segments of the link would have a dot-extension ID like 101.3 as shown in Figure 3 and Table 1.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
3 103.1 101.3
1
4
103.2
102.8
2
5
103.3
101.4 102.9
7 104.2 101.5 11 8 104.3 102.10 12 9 104.4
6
10
Figure 3 A street network
Table 1 Street network topology
Road# 101 101 101 102 102 102 103 103 103 104 104 104
TransegID 101.3 101.4 101.5 102.8 102.9 102.10 103.1 103.2 103.3 104.2 104.3 104.4
From_Node 4 8 11 2 5 9 3 4 5 8 9 10
To_Node 1 4 8 5 9 12 4 5 6 7 8 9
The transit network derives its own networks based on the same road segment and nodes. For example, in Figure 4, bus route 68 traverses through road segment 1, 4, 7 and 10, and its corresponding feature table is shown in Table 2, where TransegID is defined in Table 1, and direction indicates the direction of the bus route. If a bus route segment follows the direction of street line segment (determined by the "from node" and "to node"), its direction value is 1, or ­1 otherwise.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
3 103.1
101.3
1
4
103.2
102.8
2
5
103.3
101.4 102.9
7 104.2 101.5 8 104.3 102.10 9 104.4
Figure 4 Bus Route 68 (in red)
Table 2 Bus route segments
Route 68 68 68 68
TransegID 103.1 101.4 104.3 102.10
Directin 1 -1 -1 1
In the situation of a bus route starting or ending at the middle of a street segment, the bus route data can still be maintained using street segments without splitting them by using a start and end segment percentage table (Table 4). Table 4 maintains the percentage of length that the start segment and end segment account for the entire segments. In the case of route 68 in Table 4, the start segment accounts for 60% of length of the segment 4 (starting from the "from node" 8), and the end segment account for 50% of the segment 10 (starting from the "from node" 9).
3 103.1 4 103.2 5 103.3
101.4 102.9
7 104.2
101.5
8
11
104.3
9 104.4
102.10 12
Table 3 Bus route segments
Route 68 68 68
TransegID 101.4 104.3 102.10
Direction -1 -1 1
Table 4 Start-end segments
Figure 5 Bus route starting and ends at the middle of a street segment
Route StartSegPct EndSegPct
68
60
50
...
...
...
In other situations, many transit agencies take a street centerline file and add route features that are not in the original street network. For example, adding segments that run through shopping centers and transit centers as shown in Figure 6. In this case, transit agency inserts a node in segment 102.10 and adds segments in a shopping center for a turnaround. The original segment 102.10 will have two IDs 102.10.1 and 102.10.2. The new link will have a new Link ID 102.15. This new feature extension segment may differ from one representation to another or from one year to another. In order to keep the relationship of the feature extension with the original feature, and to reconcile one set of feature segment extensions to another set of segment extensions for the same feature, linear referencing is needed. Although not shown here, the relationship of one set of feature extensions to another set can be established by means of linear referencing of the various new feature extensions.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
In all these cases, the transit agency does not need to maintain the street network which may be maintained by the highway department, and the transit agency needs only maintain its transit network. The transit agency can access the street data via the Internet to create, update bus routes. Furthermore, as indicated below, any update on the street information would be automatically reflected in the transit network.
3 103.1 4 103.2
101.4
5 103.3
102.9
7 104.2
101.5
8
11
104.3
102.13 9 104.4
102.14 102.15 12
Table 5 New bus route segment
Route 68 68 68 68
TransegID 101.4 104.3 102.13 102.15
Direction -1 -1 1 1
Table 6 New start-end segments
Figure 6 Bus route deviates from a street segment
Route StartSegPct EndSegPct
68
60
100
...
...
...
The GML Coding of the Data
In this prototype, the data was coded in GML and stored in GML at the server to serve to the user. The detailed coding is not necessary to be shown here. The following are some examples showing how GML, specifically the Extensible Linking Language (Xlink) and XML Pointer Language (Xpointer), is used to code spatial feature relationships and temporal data. XLink provides a mechanism for defining relationships between elements and offers multiple ways to represent those relationships. Its companion, Xpointer, provides ways to point to specific elements, character strings, vector graphic elements, or even individual characters of an XML document. XPointer describes how to address a resource, while XLink describes how to associate two or more resources. A resource is any addressable (or a URI referenced) unit of information or service, including files, images, documents, programs, and query results, or a portion of a resource. GML uses XLink to link two or more geographic features.
Using XLink to Model Feature Relationships as Feature Members
The unique segment ID 'TranSegID' in the street network can be used in XLink as an attribute of a feature to unambiguously reference specific features within a GML document or in a remote GML document. For instance, a bus route "route_15" runs on street segments 103.1, 101.4, 104.3 and 102.10 as shown in Figure 4 and it also has many stops along the way. This bus route can be coded in GML as a collection of feature members
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
using XLink. A feature collection is a collection of one or more feature elements called feature members. A feature collection could also be a feature member of another feature collection. A feature collection can use the featureMember property to show the feature members it contains. For example, the route "route_15" can be coded in GML as follows: July 2002 In the above example, the bus route "route_15" is composed of 4 street segments and two stops as . These feature members all point to remote features or features elsewhere using XLink. When the data change in those other documents, the bus route database would automatically change. Furthermore, the encoding of the bus route using element would make it easy to make a query about a specific bus route. Using XLink to Model Feature Temporal Changes XLink offers a means to capture the temporal changes of a feature. For example, a street element 102.10 contains two locator elements that identify the historical data of this street segment, in the years of 1990 and 1995. This can be implemented in GML as follows: Broadway 102.10 xlink:label="archive90_TranSeg102.10" xlink:role="http/www.dgis.org/" xlink:title="street archive data 1990 for TransegID 102.10"/> TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
xlink:href=http://www.highway.gov/archive/1995/street.xml#TranSeg102 .10"/> xlink:label="archive95_TranSeg102.10" xlink:role="http/www.dgis.org/" xlink:title="street archive data 1995 for TransegID 102.10"/>
In this example, the street segment 102.10 (as a GML element) is linked with two remote resources street.xml#TranSeg102.10 that are located at http://www.highway.gov/archive /1990/ and http://www.highway.gov/archive/1995/. The xlink:label attribute indicates a reference point that will be used later to connect one point to the next by using the arc element. Arcs are paths between resources. An arc element is defined by an xlink:type attribute with the value arc. The arc element uses an xlink:from attribute to identify the link's source, and an xlink:to attribute to identify the link's target. The value of the xlink:from and xlink:to attributes is not URIs, rather it is the value of the xlink:role attribute. Based on the definition of the above example, we can make the following connections among the current data, the 1990 and 1995 archive data using the arc element. Where "nextyear" and "prevyear" are connection elements that contain the connection information. Besides the links shown above, other links are also possible. More complex examples can be illustrated, though not shown here, to split TransSeg 102.10 into two or more segments in later years. Using XLink to Encode Feature Associations There are generally two ways to describe feature associations: containment and linking. Containment is used to describe binary relationships only (i.e., it connects pairs of features). Linking is generally used to link multi-directional relationships among multiple features and relationships that cannot be described by containment such as an adjacency relationship among multiple polygon features. The following example shows both containment and linking.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
Assume we want to encode a census block that is composed of four adjacent land parcels and two streets as show in Figure 7. We could use the featuremember to code feature containment and adjacentTo property and Simple Links to encode the land parcel "adjacency" association as follows.
ST3322
P4097 ST3321
P5000
P4098
P4099
Figure 7 An illustration of a block with parcels and streets November 10, 2002 Dave Smith ... Peter Jones ... Sue Davis ...
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
Michael Jackson ...
These are just some simple examples of using XLink to relate features in a distributed data environment. A much more sophisticated feature relationship can be constructed using the combination of XLink, XPointer and XPath. In general, XLink is very appropriate to link feature relationships, spatial or non-spatial, particularly in the following situations: (1) when one element links with multiple resources, like one street segment linking with multiple transit routes, or one street segment linking with many properties in different property (or attribute) files; (2) when the participating resources are read-only, like the transit agencies linking with street centerlines that are maintained by the highway department; and (3) where it is expensive to modify and update documents but inexpensive to modify and update a separate linking element, e.g., to update a bus route running on different street segments. Data Display on the Web Now that we have all spatial features encoded in GML, and we use OGC's Web Feature Server to extract and interpret geospatial features from the data sources, how do we use them and display them on the Web? A GML document is simply a text. Like other text-based documents, it is viewed as text. In order to display GML in graphic presentations, GML must be styled into a graphical form such as a SVG, VML or W3D. The GML document can also be transformed into a WML format or XHTML format to display in wireless phones or PDAs. There are two basic ways to style or display XML documents in the Web, the Extensible Stylesheet Language (XSL) and the Cascading Style Sheets (CSS). Both of them are W3C standards to be used with XML documents for displaying on the Web. CSS also works with HTML documents. CSS is a non-XML syntax and does not need transformation. It is simple and straightforward, requires very little coding and is thus an ideal starting point for formatting an XML or HTML document for Web publishing. But CSS has its limitations. For example, CSS cannot re-order elements, which is important to display only a subset of a large document. The XSL, on the other hand, is an XML application and follows the rules governing any XML documents. Using XSL to display XML documents also requires transforming the XML document to a format that is appropriate for the display media like a Web browser or a wireless device. That is, XSL usually has to work with the XSL Transformations Language (XSLT).
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
XSL can do much more than CSS. It offers rules to format and display the layout of text and graphics on a page. It further offers a scripting language that allows the user to rearrange document content and to conditionally execute instructions based on evaluation of the document's data, structure, or other properties (Hjelm & Start, 2002). This prototype used the XSL as a style engine. Specifically, Saxon (http://users.iclway.co.uk/mhkay/saxon/) is used in this prototype as an XSLT Processor, with which GML data were transformed into SVG files for display. On the client side, a graphic renderer, Adobe SVG Viewer plug-in, is needed to transforming the SVG files into a viewable map on the Web browser. Here are some examples of the query results displayed on the Web browser with a SVG Viewer (Figure 8).
Figure 8 A vector map of a query result of a bus line on the Web with GML data (the left figure is a bus line, the right figure is the bus line associated with street segments. Different line symbols are used to differentiate the bus lines and street segments.) (This example was provided by Chuanrong Zhang at Department of Geography, University of Wisconsin-Milwaukee) Conclusions This paper discussed a framework of designing a feature-level transportation geospatial data sharing system. The simple prototype shows the potential of using GML and WFS to share, access, extract, transport, and display distributed geospatial data at the feature level. This makes it possible for real-time transportation applications to extract and exchange data at the feature level in real time. This is a great step forward comparing with the existing data clearinghouse approach, where data exchange only at the file level and data extracting at the feature level is impossible. In addition, with the experiment of a proposed standard transportation framework, the extracted data from distributed sources would be more consistent.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
The prototype developed is currently a very simple system with only two transportationrelated data sets in different servers. But this framework has the potential to link all geospatial data all over the world. The capability of XLink and Xpointer also allows the spatial relationship to be distributed. That is, data at one location in the earth can be dynamically related to data elements in another. This would essentially allow us to build a Geo-spatial Web with one GML data server connecting with other data server. All geospatial data could be interoperable and interconnected with each other. When users request data about a particular area from the Internet, they can reach all the data that are available on the Web because all data are now interconnected. This interconnected geo-spatial data Web would allow users and individual developers to focus less on data and more on applications. Furthermore, since GML is open and nonproprietary and no single vendor controls it, everyone can build components and software to capture, share, transform and utilize these interconnected GML data Web. It also provides a mechanism for data providers to sell data to the end users in real time. Accessing geo-spatial data by Internet GIS programs anywhere on the Web in real time is made possible by using GML and WFS. This vision of the geo-spatial Web augments the importance of data standard and client side application development. The GML is simply a coding mechanism to code geospatial data based on a spatial data model. It is the standard of the spatial data model that defines the relationship between spatial features. Without standard data models, data interoperability is still impossible. Some GIS vendors are beginning to implement GML and WFS in their Internet GIS programs. It is important for the GIS user community to demand them to comply with the standards without modifications. There is a danger that some GIS vendors may opt to have their own version of XML for the interest of profits and Market share, just as Microsoft modified Java standard. Furthermore, the GML and WFS provide a mechanism to extract and obtain geospatial data in the Internet environment. It is the client applications or server applications that make use of the data that transfer the data into knowledge. Therefore, it is imperative that transportation applications should be developed that support GML and WFS. Only then, would it be possible for the emergency response system operator in the hypothesized example at the start of this paper to extract data from different sources and to conduct real time operations. If there is no strong support from the GIS vendor and transportation application vendors, the framework presented in this paper would only be that, a framework. Acknowledgement I would like to express my appreciation to Professor Kenneth Dueker for his valuable comments and suggestions to this paper.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
References Baldonado, M., Chang, C. K., Gravano, L., & Paepcke, A. (1997). The Stanford Digital Library Metadata Architecture. International Journal on digital libraries, 1, pp.108-121. Dueker, K.J. 1995, "Access to Data: National Spatial Data Infrastructure." Presented at the 74th Annual Meeting of Transportation Research Board, Washington, D.C. Dueker, K.J. and Bender, P. 2002, "White Paper on Issues and Strategies for Building a State Transportation Framework." Paper prepared for Washington Sate Department of Transportation, Center for Urban Studies, Portland State University, Portland, OR. Fegeas, R. G., Cascio, J. L., & Lazar, R. A. (1992). An Overview of FIPS 173, The Spatial Data Transfer Standard. Cartography and Geographic Information Hjelm, Johan & Peter Start, XSLT: The Ultimate Guide to Transforming Web Data, 2002. New York: John Wiley & Sons, Inc. Lake, Ron. (1999). Introduction to Geography Markup Language (GML), URL: http://www.jlocationservices.com/company/galdos/articles/introduction_to_gml.htm Lake, Ron. (2000). Making Maps for the Web with Geography Markup Language (GML), URL: http://www.jlocationservices.com/company/galdos/articles/GMLMapMaking_gml.htm Lake, Ron. (2001). GML 2.0 - Enabling the Geo-spatial Web, URL: http://www.jlocationservices.com/company/galdos/articles/GML3.htm Moellering, H. (1992). Opportunities for Use of the Spatial Data Transfer Standard at the State and Local Levels. Cartography & geographic information systems, Special Issue, 19(5), pp. 332-334. Onsrud, Harlan J. and Gerard Rushton (eds.) (1995) Sharing Geographic Information, Center for Urban Policy Research, Rutgers University. Open GIS Consortium, 2001, OpenGIS® Geography Markup Language (GML) Implementation Specification Version 2.0 Open GIS Consortium, Inc. (OGC) (1998). The OpenGIS Abstract Specification, Version 3. Wayland, Massachusetts: Open GIS Consortium, Inc., URL: http://www.opengis.org/techno/specs.htm (date: 5-11-2000). Smith, Terence R. "The Meta-Information Environment of Digital Libraries." D-Lib Magazine, July/August 1996.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.
Tsou, M. H., & Buttenfield, B. P. (1998). An Agent-based, Global User Interface for Distributed Geographic Information Services. In Proceedings of the 8th International Symposium on Spatial Data Handling, Vancouver, Canada, pp. 603-612. Zaslavsky, I. 2000. "A New Technology for Interactive Online Mapping with Vector Markup and XML". Cartographic Perspectives, Vol. 37 (Fall 2000), pp. 65-77.
TRB 2003 Annual Meeting CD-ROM
Paper revised from original submittal.

ZR Peng

File: a-framework-of-feature-level-transportation-geospatial-data-sharing.pdf
Title: Framework of Feature-Level Transportation Geospatial Data Web Portal Systems
Author: ZR Peng
Author: Peng, Zhong-Ren
Subject: Data & Information Technology
Keywords: 03-3964
Published: Fri Nov 15 11:40:18 2002
Pages: 22
File size: 0.33 Mb


American Family's Experience, 24 pages, 0.84 Mb

ASSUMPTION 21, 164 pages, 1.48 Mb

Are Disciples Born or Made, 24 pages, 0.32 Mb

, pages, 0 Mb
Copyright © 2018 doc.uments.com