A proposed framework for feature-level geospatial data sharing: a case study for transportation network data Z.-R. PENG

Transcription

1 International Journal of Geographical Information Science Vol. 19, No. 4, April 2005, Research Article A proposed framework for feature-level geospatial data sharing: a case study for transportation network data Z.-R. PENG Center for Advanced Spatial Information Research, University of Wisconsin- Milwaukee, PO Box 413, Milwaukee, WI , USA (Received 24 April 2003; accepted 19 April 2004 ) Current data sharing in the Internet environment is supported using metadata at the file level. This approach has three fundamental shortcomings. First, sharing data from different sources with different semantics, data models, and acquisition methods usually requires data conversion and/or integration like data conflation. This can be tedious and error-prone. Second, data updated from one source cannot be automatically propagated to other related data or applications. Finally, data sharing at the file level makes it difficult to provide feature-level data for searching, accessing, and exchanging in real time over the Internet. This paper addresses these three issues by proposing a standards-based framework for sharing geospatial data in the transportation application domain. The proposed framework uses a standard data model geospatial data model proposed by the Geospatial One-Stop initiative to harmonize the semantics and data models without the use of data integration methods. It uses Geography Markup Language (GML) for geospatial data coding and feature relationship, which provides a basis to propagate the data update from one source to related other sources and applications, and to search and extract data at the feature level. The framework uses the Web Feature Service (WFS) to search, access and extract data at the feature level from distributed sources. Finally, the Scalable Vector Graphics (SVG) standard was used for data display on the Web browser. Two transportation network datasets are used in the prototype case study to implement the proposed framework. The prototype allows the user to access and extract data at the feature level on the Web from distributed sources without downloading the full data file. It shows that the proposed standards-based feature-level data-sharing system is capable of sharing data without data conflation, accessing, and exchanging data in real time at the feature level. The prototype also shows that changes in one database can be automatically reflected or propagated in another related database without data downloading. Keywords: XML; Geography Markup Language (GML); Data sharing; Web Feature Service (WFS); Scalable Vector Graphics (SVG); Geospatial one-stop 1. Introduction Data sharing has been an important issue in the field of Geographic Information Systems (GIS), and thus many efforts have been made to address its research and practical issues in the literature (Vonderohe et al. 1997, Devogele et al. 1998, Dueker and Butler 1998, 2000, Adams et al. 2001). There is also active interest from *Corresponding author. zpeng@uwm.edu International Journal of Geographical Information Science ISSN print/issn online # 2005 Taylor & Francis Group Ltd DOI: / 转载

2 460 Z.-R. Peng researchers, practitioners, and vendors to find ways to improve accessibility to spatial data and spatial data-processing services over the Web (David et al. 1998, Su et al. 2000, Kowal 2002). However, data sharing and exchange between, and sometimes within, the same organization are still recognized as a labour-intensive and problematic endeavour. Besides institutional barriers to sharing geospatial data (Dueker 1995, Onsrud and Rushton 1995), data sharing is also hindered by technical difficulties. The institutional issues have been extensively addressed in the literature, which is not to be discussed in this paper. On the technical side, there are also many issues that hinder the sharing of spatial data. Among them, semantics may be the most difficult issue as discussed in the interoperability and ontology literature (Frank 2001, Smith and Mark 2001, Fonseca et al. 2002, Kuhn 2002). Another important issue is that most prior research and professional practice have focused on data sharing at the file level. That is, sharing and exchanging a whole data set or data file, when the data files were created in different data models and in various formats by different organizations. The differences in data semantics, data model and data structure cause difficulty in data sharing. The goal of data sharing at the file level is to improve the reusability of data files and reduce the redundancy of data acquisition (Onsrud and Rushton 1995, Carver et al. 1998). Several efforts have been made to improve data access at the file level (Dueker et al. 2001). For example, the Geospatial Data Clearinghouse Activity (GDCA) ( under the auspices of the US Federal Geographic Data Committee (FGDC) (Peng and Nebert 1997), the Alexandria Digital Library, and the Geography Network (now the g.net) managed by a private company, ESRI Inc. (Peng and Tsou 2003), are prime examples of attempts to improve data sharing and make geospatial data available online. The FGDC s GDCA provides a framework for individual governmental agencies, consortia, the private sector, and academic institutions to advertise, share, and access each other s available data. The clearing-house framework is a federated 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 through metadata from a single user interface on the Web. The different data servers are called nodes. Each node has to register with FGDC to be part of the searchable clearing house. There have been many clearing-house nodes established nationwide since 1995, assisted by the National Spatial Data Infrastructure (NSDI) Competitive Cooperative Agreements Program. The NSDI was established in 1994 by the President s Executive Order to coordinate the sharing of geographic data. The main purpose of NSDI is to facilitate geospatial dat sharing by establishing partnerships with states, counties, cities, tribal nations, academia and the private sector ( On the private side, the Geography Network and g.net are examples of data sharing through the Web. The Geography Network is a collaborative and multiparticipant web-based GIS portal for publishing, sharing, and accessing digital geospatial information. The Web site, GeographyNetwork.com, was introduced by ESRI in June 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 ( 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 access to multiple geospatial web services from one

3 Feature-level geospatial data sharing 461 access point. However, g.net requires that all data providers use the same ArcIMS software. The major function of these and many other data-sharing activities is simply to provide ways to search for and access existing data files. These file-level data-sharing systems are very useful in allowing the user to search and obtain available data. But there are a number of problems with this approach. First, data sharing at the file level usually requires data integration such as data conflation due to differences in semantics, data model and data format (Dueker and Butler 2000, Dueker et al. 2001). For example, a highway asset management system may use linear reference systems like a milepost system, while emergency response data may use the spatial reference system like latitude and longitude or state plane coordinate systems. Another example may include data coming from different sources which do not match. To put these data sets together in one application, data integration methods like data conflation have to be used. Data conflation is a means for rubber-sheeting, selecting, or transferring spatial features from two or more files to form a uniform file. Data conflation is a tedious, subjective, and often error-prone process for consolidating differences between two or more data files (Abdelmoty and Jones 1997, Cobb et al. 1998). Second, data updated from one source at the file level cannot be automatically propagated to other related data or applications. In a true sense of data sharing, when the data are updated at the source, that change should be automatically updated in other closely associated data or applications. For example, a transit network maintained by a transit agency is usually linked with the street network that is managed by the highway department. When a portion of a street network changes, that change should be automatically reflected in the transit network. In other situations, a change in one specific local road segment updated by a local government agency should be immediately reflected in other data (such as state highway department) that relate to this road segment (Dueker et al. 2001, Dueker and Bender 2002). In current practice, once the street network changes, the whole street network file is delivered or downloaded to the transit agency. The transit agency would update the transit network based on the changes in the street network. Usually, the changes in the street network are small, but since the data sharing is at the file level, those changes cannot be easily identified. The data users, like a transit agency, have to manually identify the changes in the street data file and then update the transit network accordingly. Furthermore, data sharing at the file level usually causes latency of data update. Because data-file delivery or downloading is infrequent, data updated in one department usually cannot be made available immediately to other departments. For example, a street network in a rapidly developing area could change frequently, but those changes may not be instantly available to other departments who have previously downloaded the street network data. This causes problems for applications and operations that need real-time data access to the most up-to-date information. Finally, data sharing at the file level makes it difficult to provide feature-level data search, access, and exchange in real time over the Internet. In many applications like emergency response systems and location-based services, users are only interested in spatial information at the feature level. For example, if there is an accident in a segment of the freeway, or a fire in a block, or a traveller at a specific location, the incident response team or the traveler only needs to know the information

4 462 Z.-R. Peng pertaining to a particular freeway segment, a block or a specific location. They cannot wait and do not need to obtain the full data sets from different sources. The critical question is then how to search, access and retrieve the information at or around that location. Currently, data searching is usually done at the file level based on metadata. Good metadata could help the data users to better understand and use the data (Medyckyj-Scott et al. 1996). But metadata at the file level, not at the feature level, makes it difficult to search for a particular feature like a specific road segment or a census block from different data sets. Fortunately, recent metadata implementations such as the International Organization for Standardization (ISO) metadata standard (ISO 2003), allow features such as county roads or census blocks, to be searched for. However, due to implementation difficulties, very few data providers, if any, have incorporated feature-level metadata. In addition, data exchange and access at the file level rather than at the feature level causes difficulty in real-time remote data access. That is, the user usually has to obtain data files from different sources and, in most cases, convert them into a common format before the data can be used. This causes delays for applications accessing data files directly in real time. This is reasonable for non-time-critical applications like planning, but it is less useful for time-critical applications such as homeland security, emergency-response operations and location-based services that require instant access to feature-level data. Therefore, although file-level data sharing and data integration are useful and necessary, they are insufficient to meet the demand of many applications that need real-time access and exchange of the most up-to-date feature-level data. This calls for a feature-level data-sharing system. Data sharing at the feature level refers to accessing and exchanging feature-level data. A feature is a real-world phenomenon represented by a point, a line, a polygon, or a complex geometric feature object. Feature-level data sharing offers the ability to access and exchange information about a particular feature element. This paper addresses the above-mentioned three problems of the file-level datasharing system by proposing a standards-based data-sharing framework at the feature level through the Internet on the Web, that is, the sharing and exchange of a particular data element and a specific spatial object like a point, line, or polygon. Specifically, this paper addresses the feature-level spatial data sharing under the constraint of the transportation-application domain. A prototype has been developed to demonstrate the feasibility of feature-level data sharing. The prototype is based on two transportation network data sets: street-network and transit-network data. Thus, the prototype is particularly pertinent to transportation networks and their applications, and may be of special interest to transportation data providers and users. Although some issues such as data models and semantics are specifically related to transportation networks, the results from this prototype development experiment are expected to be useful and applicable to other data types as well. Hopefully, other prototypes could be developed in the future for different types of data. 2. A Framework of feature-level data sharing A framework of feature-level data sharing is proposed, as shown in figure 1. This framework uses a standard data model to describe feature identification and semantics, so that data from different sources can be sharable without the use of a data integration method like data conflation. The proposed framework uses a

5 Feature-level geospatial data sharing 463 Figure 1. Diagram of a feature-level data-sharing framework. standard data model a geospatial data model proposed by the Geospatial One- Stop initiative to harmonize the semantics and data models. It adopts Geography Markup Language (GML), developed by the Open Geospatia Consortium (OGC), for geospatial data coding and feature relationships, which provides a basis to propagate data updates from one source to related other sources and applications. GML codes metadata at the feature level into the GML data file, which makes it easier for searching at the feature level. Furthermore, the XLink in GML is to be used to link spatial features from different sources so that the changes in one data source can be immediately reflected or propagated in other related data or applications. For remote data access and exchange, the OGC Web Feature Services (WFS) is used to access and manipulate feature-level data through the Web. Finally, this framework adopts the World Wide Web Consortium s (W3C) Scalable Vector Graphics (SVG) standard to display spatial data as vector maps on the Web browser. From the user s point of view, the user can search, access and retrieve spatial data at the feature level through a Web-based search engine. A user s query goes through the Web server and WFS to the respective geodatabase. The retrieved feature data will then be displayed as SVG in the user s Web browser and/or applications. The main purposes of this feature-level data-sharing framework are twofold: to facilitate users to access data at the feature level from distributed sources, and to automatically propagate the updated features to users without sending the full data file. That is, when the data are updated at one data source, that update would be automatically reflected in any data or applications that connect with it. The following describes the general framework for developing a feature-level data sharing system in detail. It begins with a discussion of a standard data model to describe feature identification and semantics. The data model is then employed in two transportation-network data sets a street network and a transit network. The modelled transportation networks are then coded in GML. Examples are shown, demonstrating how feature-level data linking and sharing are possible using GML, XLink and XPointer. The paper then discusses feature-level data search and data access using WFS. Since the sample data are for transportation networks, many discussions are unique to linear features in those networks. But the general approach is applicable to other kinds of data sets as well. 3. Standard data models and feature semantics One of the most difficult factors that hinder data sharing is the semantic issue, i.e. the various ways of representing and naming spatial features in different data sets.

6 464 Z.-R. Peng This has been widely discussed in the interoperability and ontology literature (Harvey et al. 1999, Frank 2001, Smith and Mark 2001, Fonseca et al. 2002, Kuhn 2002). There are no easy solutions to this difficult issue, but there are two general approaches to address it database integration and standardization (Devogele et al. 1998). Data integration is a process of assimilating data from different sources and formats into a uniform format. This is the most common approach for dealing with diverse data formats, to facilitate data exchanges at the file level. However, the differences in semantics hamper data integration. Even with database-conversion software, the semantic difference at the feature level cannot be erased. Furthermore, the conversion process slows down the feature-level data access and exchange in real time on the distributed environment. The other approach to address semantics is through standardization. This includes utilizing standard feature representation, a standard data model/format, or a standard data-exchange method (Fegeas et al. 1992, Moellering 1992, Cruz et al. 2002). A generalized standardization for all geospatial data is extremely difficult, and consensus is hard to achieve. But it is possible to constrain the semantic issue by standardization within a particular application domain. In this proposed framework, I constrain the semantic issue in the transportation application domain. Under this framework, a standard data model and semantics should be used for all data. In other words, the feature-level data access and exchange proposed in the paper require that all data use the same data model and interchangeable or mutually agreeable semantics (Cruz et al. 2002). Further research should expand the system to cover data in different data models and to address more heterogeneous semantics (Cruz et al. 2002, Pundt and Bishr 2002) in a featurelevel data sharing. Efforts have been made, and several unified data models have been developed to address the standard semantics and common data model issues in the representation of transportation features and feature semantics (Vonderohe et al. 1997, Dueker and Butler 1998, Adams et al. 2001). Several standards have been developed to facilitate data exchange, notably, the Geographic Data File (GDF) and the Spatial Data Transfer Standard (SDTS). GDF is in the process of becoming an ISO standard for spatial data formats (ISO/TR GDF, Geographic Data Files, Version 4.0). It is specifically designed for spatial data exchange for applications of Intelligent Transportation Systems (ITS). The Spatial Data Transfer Standard, or SDTS, is a data transfer standard known as ANSI NCITS and was ratified by the American National Standards Institute (ANSI) on June SDTS addresses standard means of transferring geospatial data between dissimilar computer systems ( html) at the file level. Most recently, there have been efforts in the United States to address the issue of inconsistent data representation or data models. One is the NSDI Framework Transportation Identification Standard effort; the other is the Geo-Spatial One- Stop initiative. The NSDI Framework Transportation Identification Standard (FGDC 2000) is a conceptual data model standard that was 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. Each FTSeg begins and ends at a Framework Transportation Reference Point (FTRP) and has a unique identification code

7 (FTSeg ID). These road segments will form the basis for data exchanges among different data sets that may have been collected in different scales and stored in different formats. However, the development of the NSDI Framework Transportation Identification Standard has ended and is being replaced by the Geospatial One-Stop initiative. 4. A standard road network model Feature-level geospatial data sharing 465 The Geospatial One-Stop initiative, an E-Gov initiative from the Office of Management and Budget (OMB), goes a step further. It addresses not only data interoperability but also data access, sharing and distribution. The goal of the Geospatial One-Stop is to establish a comprehensive web portal, with one-stop Internet access, to the NSDI seven-framework of geographic data [e.g. Cadastral, Digital Ortho-Imagery, Elevation (terrestrial and bathymetric), Geodetic Control, Governmental Units, Hydrography, Transportation]. This one-stop Web portal will allow data providers to advertise or post their data and allow users to extract data from different providers at their sources ( index.html). The Bureau of Transportation Statistics (BTS) is responsible for developing standards for integrating the transportation framework theme within the NSDI seven-framework themes into the Geospatial One-Stop. BTS has assembled a team of transportation professionals (Modeling Advisory Team, or MAT, of which the author is a member) to develop a core data content standard for each mode (roads, transit, railways, waterways, and airport facilities) of the transportation framework theme. The core data content standard for roads (as well as for other transportation modes) has been drafted and revised several times, and is now in the public comment phase. It is expected that the core data content standard, once approved, will become a national standard for the exchange of transportation geospatial data ( The Geospatial One-Stop proposed road model is officially called Geographic Information Framework Data Content Standards For Transportation: Roads (ANSI 2003) but is commonly referred to as the MAT road model. The proposed MAT road standard describes the road system in three main components: segments, points, and events. Segments represent portions of the physical road system. Points represent discrete locations of interest along or near the road system, such as segment termini or the location of an intersection, bridge, etc. Events represent attributes that occur along or near the road system, such as incidents (ANSI 2003). The MAT road standard does not prescribe any specific business rules for segmentation or locating points and attributes along the road system. These rules are left to be defined by the application domain and may vary according to business and technical requirements. The focus of the MAT road standard is to define a way to encode segments, their start and end-points, and their attributes through three models (ANSI 2003: 11): 1. A Segmentation Model, which defines segments, collections of segments, and their associated geometries and topology. 2. An Event Model, which defines a method to model attributes that may have values that change along the length of a segment. 3. A Linear Reference Model, which defines a measurement method used to apply attributes to segments by locating the extent of their applicability.

8 466 Z.-R. Peng The Segmentation Model defines three features that are associated with the road system, i.e. RoadSeg, RoadPoint, and RoadPath. RoadSeg represents a linear section of the physical road system. The MAT model is flexible, to allow applications to define RoadSegs. For example, a road segment could be represented by one RoadSeg with two travel directions, or two separate RoadSegs with each RoadSeg representing one direction of travel, or even multiple separate RoadSegs representing each individual lane. RoadPoint is simply a point along the roadway system. It could be a starting or ending point of a road segment or the start or centre of a bridge or the centre of an intersection. A RoadPath is a path along the physical roadway, such as Interstate 43 or a delivery route. The RoadPath is merely a collection of one or more whole or partial RoadSegs. The Event Model defines the event or the characteristics of the road system components, with point events and linear events. A point event is anything that occurs at a single point location along or near a RoadSeg. A linear event is something that occurs along a portion of a RoadSeg. Feature Events are used to model attributes of the road features like RoadSeg, RoadPoint, and RoadPath. These include feature geometry and attributes of the feature elements. The primary difference between linear and point events and feature events is the fact that linear and point events can only represent a single attribute and cannot have associated geometries, while feature events can have associated geometries. The MAT Road standard does not specify a separate Linear Reference Model; rather, it adopts the ISO Linear Reference Methods (LRM) (ISO 2004). To address differences in semantics between identical road segments in different databases, the MAT Road standard uses the concept of Equivalency. The Equivalency table could include different names of the same road segment, different linear reference methods used, or different LRM units and measures. This is a superficial way to address semantics but is consistent with Cruz s mutually agreeable semantics model (Cruz et al. 2002). A more systematic way should be sought to address the semantic and ontology issues (Pundt and Bishr 2002). This MAT Road standard leaves it open for applications to decide on the contents and formats of equivalency tables. These efforts in data modelling and the development of geospatial data standards, as well as the advancement in the Web technology, provide a foundation for featurelevel data access and sharing. This paper employs the proposed Geospatial One- Stop MAT Road model as the standard feature-level data model. Based on this model, the following sections describe a proposed framework of a standards-based feature-level data-sharing system. 5. Modelling transportation networks To examine the feasibility of feature-level geospatial data access and exchange, a prototype geospatial data-sharing system has been created using transportationnetwork data as a case study. Two separately stored data sets are used: the street network and the transit network of the City of Waukesha, Wisconsin. 5.1 Modelling street network Based on the proposed Geospatial One-Stop MAT Road Model, the street network consists of two basic components, road segments (RoadSeg) and nodes (RoadPoint). In addition, in order to minimize the number of foreign keys, and

9 Feature-level geospatial data sharing 467 Figure 2. Street network. 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 and/or road number. Thus, individual segments of the link have a dot-extension ID like as shown in figure 2 and table 1. Common feature identification ensures that data from different sources are consistent and searchable. This is essential for feature identification, search, and extraction at the feature level. 5.2 Modelling a transit network based on the street network The transit network derives its own networks based on the same road segment and nodes. For example, in figure 3, bus route 68 (a RoadPath feature element) traverses Table 1. Street-network topology. Road# RoadSegID From_Node To_Node Figure 3. Bus route 68 (in red).

10 468 Z.-R. Peng Table 2. Bus route segments. Route RoadSegID Direction through road segment 103.1, 101.4, 104.3, and , and its corresponding feature table is shown in table 2, where RoadSegID 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. In the situation of a bus route starting or ending at the middle of a street segment (figure 4, table 3), the bus-route data can still be maintained using street segments without splitting them into separate segments by using a start- and end-segment percentage table (table 4). Table 4 maintains the percentage of length for which the start segment and end segment account. In the case of route 68 in table 4, the start segment accounts for 60% of length of the segment (starting from the from node 8), and the end segment accounts for 50% of the segment (starting from the from node 9). 5.3 Modelling transit network changes In other situations, many transit agencies take a street centreline file and add route features that are not in the original street network. For example, additional segments that run through shopping centres and transit centres are shown in figure 4. In this case, the transit agency inserts a node in segment and adds segments in a shopping centre for a turnaround. The original segment will Table 3. Bus-route segments. Route RoadSegID Direction Figure 4. Bus route starting and ending at the middle of a street segment.

11 Feature-level geospatial data sharing 469 Table 4. Start-end segments. Route StartSegPct EndSegPct have two IDs and (figure 5; tables 5 and 6). The new link will have a new Link ID This new feature extension segment may differ from one representation to another or from one year to another. To keep the relationship of the feature extension with the original feature, and to reconcile one set of feature segment extensions with 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. Alternatively, an equivalency table can be developed to associate the segments. 5.4 Standard coding of transportation networks Once the transportation networks are modelled based on the MAT Road standard, they need to be coded and stored in a database. Traditionally, different GIS vendors Figure 5. Bus route deviating from a street segment. Table 5. New bus-route segment. Route RoadSegID Direction Table 6. New start-end segments. Route StartSegPct EndSegPct

12 470 Z.-R. Peng have used different databases to code and manage the information. Some use relational databases like Oracle, Microsoft SQL Server, and Access; others use proprietary databases like Shapefile, Geodatabase, and ArcSDE. These diverse methods of coding feature elements in the database make it difficult to search, access, and extract spatial elements at the feature level from different data sources. This proposed framework uses GML as a standard model to code spatial data and link the spatial feature elements. GML is designed to code data elements at the feature level, including both the description about the data element (metadata) and the data element itself. For example, a street Broadway can be coded in GML as,street_name. Broadway,/street_name.. The,street_name. element is a set of metadata to describe the street Broadway. This GML code can be used to facilitate feature level data sharing and exchange, as well as data search and discovery on the Web (OGC 2003, Peng and Tsou 2003, Preston et al. 2003, Peng and Zhang, 2004). GML is used in this framework because it is an open standard, and no one owns it. Since it is based on XML, it can take advantage of many other XML-based technologies and standards such as Extensible Linking Language (XLink) and XML Pointer Language (XPointer). 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 spatial feature elements, vector graphic elements, or character strings of an XML document and GML-based geospatial database. 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 (universal resource identifier) 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. The transportation network data in this study were coded in GML and stored in GML at the server. It is not appropriate to display the coding details here, but the following are some examples showing how GML, specifically the XLink and XPointer, is used to code spatial feature relationships, and how feature-level data sharing is feasible. 5.5 Modelling feature relationships using XLink Given that a transit network is initially based on the street network, the two networks should be closely associated with each other. This means that a query for a transit route could automatically produce the underlying road segments. It also means that when the road segment changes, whether in geometry or attribute, that change should be automatically reflected in the transit network. Here are some examples of how this may be accomplished. Feature relations can be modelled in GML using XLink to link features as a feature collection. A feature collection is a collection of one or more feature elements called feature members. A feature collection could also be a member of another feature collection. A feature collection can use the featuremember property to show the feature members it contains. The unique segment ID RoadSegID 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.

13 Feature-level geospatial data sharing 471 For example, the bus route route_68 runs on street segments 103.1, 101.4, and as shown in figure 3, and it also has many stops along the way. The stop is a point feature event, and it sometimes is the RoadPoint, though this is not necessarily the case. This bus route can be coded in GML as a collection of feature members using XLink as follows:,busroute fid5 route_68.,datecreated.july 2002,/dateCreated.,gml:featureMember xlink:type5 simple xlink:href5 /.,gml:featuremember xlink:type5 simple xlink:href5 /.,gml:featuremember xlink:type5 simple xlink:href5 /.,gml:featuremember xlink:type5 simple xlink:href5 /.,gml:featuremember xlink:type5 simple xlink:href5 /.,gml:featuremember xlink:type5 simple xlink:href5 /.,/BusRoute. The street network data are managed by a highway department and are located at The stop file is managed by a transit facility department and is located at When the user makes a query for bus route 68 (e.g. find all features where fid 5 route_68 ), all feature members (RoadSegs 103.1, 101.4, and , stops 2568 and 3812) will be selected. This is an important element of feature-level data sharing. The links between bus route 68 and its underlying road segments and stops are loosely coupled. This means that those feature members are not stored in the transit route database; rather, the transit route database only establishes a logical link between them. Therefore, when the geometry or attribute of any feature member changes, the bus-route database would be automatically updated due to this XLink reference. 5.6 Modelling feature temporal changes in XLink The MAT Road Standard does not specify the handling of temporary feature changes, but XLink offers a means of capturing the temporal changes of a feature. For example, street element contains two locator elements that identify the historical data of this street segment, in the years 1990 and This can be implemented in GML as follows:,street XLink:type5 extended xlink:label5 current xlmns:xlink5 http// org/1999/xlink.,streetname.broadway,/streetname.,roadsegid ,/roadsegid.

14 472 Z.-R. Peng,history year xlink:type5 locator xlink:href5 gov/archive/1990/street.xml#roadseg /. xlink:label5 archive90_roadseg xlink:role5 http/ xlink:title5 street archive data 1990 for RoadSegID /.,history year xlink:type5 locator xlink:href5http:// gov/archive/1995/street.xml#roadseg /. xlink:label5 archive95_roadseg xlink:role5 http/ xlink:title5 street archive data 1995 for RoadSegID /.,/street. In this example, the road segment (as a GML element) is linked with two remote resources street.xml#roadseg that are located at highway.gov/archive/1990/ and 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. 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.,! arc elements make the connection.,nextyear xlink:type5 arc xlink:from5 current xlink:to5 archive90_ RoadSeg xlink:show5 replace xlink:actuate5 onrequest /.,nextyear xlink:type5 arc xlink:from5 archive90_roadseg xlink:to5 archive95_roadseg xlink:show5 replace xlink:actuate5 onrequest /.,prevyear xlink:type5 arc xlink:from5 archive95_roadseg xlink:to5 archive90_roadseg xlink:show5 replace xlink:actuate5 onrequest /.,prevyear xlink:type5 arc xlink:from5 archive90_roadseg xlink:to5 current xlink:show5 replace xlink:actuate5 onrequest /. Beside the links shown above, other links are also possible. More complex methods, though not shown here, can split TransSeg into two or more segments in later years. This example simply demonstrates the feasibility of using XLink to model and query temporal changes at the feature level. For example, the user can make a query about the geometry and attributes of a particular road segment at a specific year. 5.7 Modelling feature topology and associations in XLink The MAP Road standard does not specify the standard way of representing topology, but XLink in GML offers a way to encode feature topology. There are generally two ways to describe feature associations: containment and linking. Containment is used to describe binary relationships only (i.e. whether or not a feature or features are contained in another feature). Linking is generally used to

15 Feature-level geospatial data sharing 473 link multi-directional relationships among multiple features such as an adjacency relationship among multiple polygon features. GML uses featuremember to model containment and use feature topology to model linking. The following example shows both containment and linking. It should be noted that to code feature association by linking, the original data must have topology. The current version, GML 3.0, allows four classes of primitive topology objects. That is, it uses Node to represent point features, Edge to represent linear features, Face to represent polygon features and TopoSolid to represent complex polygon features. In addition, GML 3.0 also supports topological complexes. Edge, Face, and TopoSolid have directions or boundaries. Topology primitives are bounded by directed primitives of one lower dimension (OGC 2003, p. 125). For example, the direction or the topological boundary of an Edge is defined by a start Node ( 2 ) and an end Node ( + ). The orientation of the Face is defined as +, when it is on the left side of the edge, and 2, when it is on the right side of the edge. For example, the topology of the street network shown in figure 2 can be modelled in GML as follows (partial codes):,topology.,gml:node gml:id5 5.,gml:pointProperty.,gml:Point.,gml:coordinates.8, 8,/gml:coordinates.,/gml:Point.,/gml:pointProperty.,/gml:Node.,gml:Node gml:id ,/gml:Node.,gml:Node gml:id ,/gml:Node.,gml:Edge gml:roadseg_id ,gml:directedNode orientation5 2 xlink:href5 #5 /.,gml:directednode orientation5 + xlink:href5 #9 /.,gml:centerlineof.,gml:linestring.,gml:coordinates.8,8 15,8,/gml:coordinates.,/gml:LineString.,/gml:centerLineOf.,/gml:Edge.,gml:Edge gml:roadseg_id ,/gml:Edge.,gml:Edge gml:roadseg_id ,/gml:Edge.,/Topology. With the topology coded in this way, the users can query feature associations like connected road segments and directions of road segment connections. Similarly, for

16 474 Z.-R. Peng polygon features, feature topology and association can also be represented in XLink. These are just some simple examples of the uses of XLink to relate features in a distributed data environment (e.g. data located in different data servers). A much more sophisticated feature relationship can be constructed using the combination of XLink, XPointer, and XPath. In general, XLink is appropriate for linking 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 a transit agency linking with street centrelines 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. For example, it would be much easier to update the linkage of a bus route running on different street segments than to use the traditional means of importing the updated street file from the highway department and making changes to the transit network file. This represents another great advantage of sharing data at the feature level. In summary, the use of GML to code geospatial data has several advantages. First, data may be maintained and located in different departments, yet they are still closely related. In this case study, the transit agency does not need to maintain the street-network data which may be maintained by the highway department, and the transit agency needs only to maintain its transit-network data. The transit agency can access the street data via the Internet to create and update bus routes. Second, the changes in one database can be automatically reflected in related databases. For example, any update on the street information would be automatically reflected in the transit network. Third, since both the street network and the transit network are originally developed using the same MAT Road model, even though they are later maintained in different locations they can still be logically related. Any further changes in either database, whether in geometry or semantics, could be linked with the addition of an Equivalency table. This offers flexibility by allowing the coding of the same feature with different IDs. The interconnection of geospatial data coded in GML forms the foundation for feature-level data search, access, and exchange. 6. Data query, extraction and manipulation Now that the geospatial data are structured based on the standard MAT Road model and are encoded in GML, they can be made available on the Web for featurelevel search, access, and retrieval. There are many possible ways to access Webbased data, such as Active Server Page (ASP). But the implementation of ASP could result in many proprietary data access and retrieval systems. The OGC s Web Feature Service (WFS) is a standard data-extracting service. Web Feature Service is an OGC specification for describing data manipulation operations at the feature level on OGC Simple Features (e.g. points, lines, and polygons). The operations include querying, extracting, creating, deleting, and updating features. The OGC WFS 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 the OGC Web Feature Server Specification is shown in figure 6. 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.

17 Feature-level geospatial data sharing 475 Figure 6. Architecture of OGC 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. The following 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,FeatureId. element is used to reference each feature to be fetched.,getfeature.,query typename5 RoadType.,Filter.,FeatureId RoadSegID /.,FeatureId RoadSegID /.,FeatureId RoadSegID /.,/Filter.,/Query.,/GetFeature. Besides,GetFeature., the OGC Web Feature Server Specification also specifies other query and transaction functions, such as,describefeaturetype., to describe the structure of any feature type upon request;,lockfeature. to process a lock request on one or more instances of a feature type for the duration of a transaction;,transaction. to service transaction requests like create, update, and delete operations on features; and,getcapabilities. 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 It is this feature-level data manipulation that makes it possible for WFS to query and extract data at the feature level. Furthermore, WFS also supports transactions to create, delete, and update features. This capability provides the potential to conduct spatial analysis, modelling, and other operations on the Web based on spontaneous access to distributed geospatial data at the feature level. 7. Data display using SVG The query results are GML files, which are text-based. Therefore, the Web browser cannot display them in the form of maps. In order to display GML in graphic

18 476 Z.-R. Peng presentations, GML must be styled into a graphical form such as an XML graphical display format. GML files can be displayed using some Java programming codes. But in this framework, I propose to use the standard Scalable Vector Graphics (SVG). SVG is a standard vector graphic format specification proposed by the World Wide Web Consortium (W3C) ( SVG is a vector graphic, which has a better graphic quality than the raster graphic format like JPEG, GIF, and PNG. SVG file is smaller than the GML file and is faster to display than the GML file. In this case study, a program was written to convert GML files to SVG files for display on the Web browser. To display SVG at the user s Web client, an SVG viewer plug-in like the Adobe SVG Viewer is needed to transform the SVG files into a viewable map on the Web browser (Lake 1999, 2000, 2001). Of course, if the client side is an application, it is not necessary to convert GML to SVG for display. The client-side application, like an emergency response system, needs to be able to extract the data from the GML file. 8. A prototype implementation of the framework The framework discussed above covers the separate components, e.g. the use of the MAT Road model to construct the street and transit networks, the use of GML to code spatial features and feature relationships, the use of WFS to access and manipulate feature-level data, and the use of SVG for spatial data display. These different components need to be constructed together based on the framework Figure 7. Example of a feature-level data query.