Framework of Feature-Level Transportation Geospatial ... - CiteSeerX

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



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.



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



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.



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



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



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



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.

GIS Users (Web Browser)

Catalog Server

Web Server

Web Feature Server

Data Sources

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.



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



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.



3

7 103.1

101.3 1

104.2

4

11

102.10

12

8 104.3

103.2 102.8 2

101.5

101.4

102.9 5

9 103.3

6

104.4

10

Figure 3 A street network Table 1 Street network topology Road# TransegID From_Node 101 101.3 4 101 101.4 8 101 101.5 11 102 102.8 2 102 102.9 5 102 102.10 9 103 103.1 3 103 103.2 4 103 103.3 5 104 104.2 8 104 104.3 9 104 104.4 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.



3

7 103.1 101.4

101.3 1

104.2

4

101.5

103.2 102.8 2

Table 2 Bus route segments

8

Route 68 68 68 68

104.3 102.10

102.9 5

9 103.3

104.4

TransegID 103.1 101.4 104.3 102.10

Directin 1 -1 -1 1

Figure 4 Bus Route 68 (in red) 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

Table 3 Bus route segments

7 103.1

104.2 101.5

101.4 4

11

8 103.2

104.3 102.10

102.9 5

12

9 103.3

104.4

Figure 5 Bus route starting and ends at the middle of a street segment

Route 68 68 68

TransegID 101.4 104.3 102.10

Direction -1 -1 1

Table 4 Start-end segments Route 68 …

StartSegPct 60 …

EndSegPct 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.



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

Table 5 New bus route segment

7 103.1

104.2 101.5

101.4 4

11

8 103.2

104.3 102.13

102.9 5

9 103.3

104.4

102.14 102.15

Route 68 68 68 68

TransegID 101.4 104.3 102.13 102.15

Direction -1 -1 1 1

12

Figure 6 Bus route deviates from a street segment

Table 6 New start-end segments Route 68 …

StartSegPct 60 …

EndSegPct 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



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”/>