Data Management System for Transport Planning, Traveller Information and Traffic Control

Transcription

1 Veröffentlichung / Publication Data Management System for Transport Planning, Traveller Information and Traffic Control Autoren / Authors: Markus Friedrich Lehrstuhl für Verkehrsplanung und Verkehrsleittechnik, Universität Stuttgart friedrich@isvs.uni-stuttgart.de Thomas Friderich, PTV AG, Karlsruhe thomas.friderich@ptv.de Michael Landwehr, PTV AG, Karlsruhe michael.landwehr@ptv.de Veröffentlicht in / Published in: Friderich, T., Friedrich, M., Landwehr, M. (2004): Data Management System for Transport Planning, Traveller Information and Traffic Control, CD-ROM Proceedings of 2nd International Symposium Networks for Mobility, Stuttgart. Universität Stuttgart Institut für Straßen- und Verkehrswesen Lehrstuhl für Verkehrsplanung und Verkehrsleittechnik

2 Data Management System for Transport Planning, Traveller Information and Traffic Control Thomas Friderich PTV AG Stumpfstr Karlsruhe, Michael Landwehr PTV AG Stumpfstr Karlsruhe, Markus Friedrich Universität Stuttgart Seidenstr Stuttgart, Abstract. Up-to-date digital content is the key to high quality applications. The paper presents a comprehensive data management system, which consists of a extensive multi-modal data model and a multi-user system for decentralised editing by local actors. Keywords: data management, multi-user systems. 1 Introduction High quality and up-to-date digital content is the key to high quality applications for transport planning, traveller information and traffic control. Typically, data pools such as digital road maps, hotel registers and yellow pages provided by the major commercial providers can only reach limited completeness and actuality on a local level. Centralised content acquisition by commercial providers is costly and can often not yield sufficient quality and detail due to the lack of local knowledge. At the same time, different actors are working on a local as well as application-specific level investing in acquisition and processing of transport-related digital data. Specific data sources like public transport data of stop locations, line routes and timetables need to be integrated for intermodal applications. Including the characteristics of transfer walking links (even path, ramp, escalator, elevator) within a public transport station and connected parking lots or taxi ranks requires detailed knowledge of the local situation. 1

3 Similar knowledge is necessary for adding traffic control devices (detectors, signal heads) or local points of interests (e.g. cemetery, parking garages) to a comprehensive database for transport. The paper presents an approach for a comprehensive data management system for transport-related data called INTREST (Intermodal Referencing System for Transport Related Data). As the two main aspects the INTREST approach covers an integrated geo-referencing system and a multi-user system for decentralised editing of local data. 1.1 Objectives As part of the Bavarian mobility 21 initiative, the INTREST project develops the technical infrastructure as well as the commercial and organizational framework for a multi-user data management system. With this data management system the State of Bavaria (Board of building and public works, Bavarian Ministry of Interior Affairs) intents to achieve the following objectives: Improved access and exchange of transport-related digital map data and corresponding content areas for public and private entities in Bavaria by establishing an integrated geo-referencing system and digital map data pool which is shared and maintained by the INTREST partner network; Improved quality and completeness of transport-related digital map content for Bavaria: The content supply is ensured by different, decentralized INTREST partners with local and application-specific knowledge. A comprehensive digital vector map, which integrates public and private transport modes in a network model, forms the base of the data pool. An open and extendable system architecture and content catalogue in order to integrate diverse applications and services. To achieve this the INTREST object model and the INTREST interface are public. Maximum synergies with commercial digital maps: With a commercially available digital (vector) map as base supply, initial content layers and their regular updates are ensured. If necessary, the digital map data can easily extended to provide coverage outside Bavaria. 1.2 Use Cases Obtaining data: To acquire the data the INTREST customer needs to register with the operator and agree on the general commercial terms of INTREST. With a web browser application, the customer can specify the required content for extraction from INTREST with regard to the object layer and geo-graphical coverage. The data are then extracted and provided for down-load. 2

4 Master Update of the digital map: The underlying commercial digital map is regularly updated in INTREST, in order to maintain the compatibility with the current commercial map coverage and in order to benefit from the updated map content. Since the editing operations might have altered the original topological content of the INTREST map (see below), the two maps need to be matched, i.e. links in the INTREST map have to be mapped to links of the new commercial map update to identify the differences. The INTREST map is then enriched by those changes, new in the commercial database. All geo-references by other data objects to the INTREST network are then updated to the new enriched network base. This complex process is done at least once a year. Integrating data from foreign map databases: Certain content layers in foreign digital map databases can be useful to the INTREST data pool though their transfer cannot be handled via an editing tool. This way of data transfer into the INTREST database is important, since it allows existing databases to be tapped with their own referencing and digital map. It also allows the transfer of INTREST data to external network references in foreign data bases. In such a case, a net-matching process between the foreign map base and INTREST is performed. In an offline process, corresponding links in both networks are identified. After an automatic identification of corresponding links, a remainder of links, which could not be matched automatically, needs to be treated manually using an editor. The resulting set of corresponding network links, attributes and objects in the foreign data base can then be transferred to the corresponding object or reference in the INTREST database. Such a process cannot be handled by the INTREST partner supplying data via the INTREST interface, but requires the special intervention of the system operator. Entering and maintaining data by the community: Entities supplying the INTREST data pool become INTREST partners and have access to the data pool at preferential terms. Initially, the operator and the partner agree on the extent of the data exchange in terms of coverage, content layer and update frequency. Usually, the partner will communicate with the INTREST server via a web-browser interface in order to obtain a data base extract for local editing of the data pool. If no other editing restrictions (e.g. from another editing partner) exist, he locks this content layer for other editors and receives the data in the standard INTREST format via down-load. The data entry is then handled off-line using an INTREST editor or a compatible editing application. Having completed the editing process, he will login on the server through the browser interface, upload the changes and free the lock. The server checks the data and integrates them into the data pool or rejects them. The user is informed about the result and the user account is credited with the value of the data delivered to the server. 3

5 2 Multi-User System The basic requirement of a data pool, which is maintained by a community of users, is the possibility for more than one user to edit the data at the same time. As an example in the INTREST network it is possible for the Munich Transport Alliance to edit their public transport stops, while in Augsburg a bus company is adding new lines to the network and at the same time the building authority is working on the shapes of the housing areas in the whole country. This multiusability is achieved through a more dimensional division of the network. All objects are classified into spatial units and logically into object types. User 1 User 2 Figure 1: Spatial and logical divisions permit parallel editing. The whole network is divided into a grid of tiles having the size 2,5 km by 2,5 km. In the editing request the user has to specify the set of tiles and the object group he wants to modify. The server then provides all objects of this group that are located within the requested tiles. But only object that lie completely in the given area are permitted for editing; all objects which are partially outside the tiles are in a read-only status. For each object group certain rules apply for determining whether a object is editable, readable or not part of the request at all. For a node a simple coordinate comparison will suffice, for a more complex objects e.g. a bus line, editing is only possible if all referred object (bus stops, network links) are also located within the requested area. After a editing request has been processed by the server a lock is active for the given set of tiles and a the given object groups. No other users can now obtain this data for editing. The lock is released as soon as the respective changes referring to this lock have been delivered or the maximum check-out time has expired. 3 Data Model The INTREST data model consists of a complex referential structure, where objects point to other objects. Therefore an object hierarchy has been established: If objects in the upper hierarchy levels are edited, these objects as well as dependant objects in the lower hierarchies are blocked for other partners who wish to access this database part for editing. For example locking 4

6 detectors will automatically lock the network. This way it is ensured, that no references to the network is deleted by another user. Surface Base Regions Network PublicTransport Weather TimeSeries Town Background Address Detector POI Validity StreetStructure TrafficFeatures Figure 2: Oject groups and their relations in INTREST Despite the restrictive locking approach, some conflicts cannot be avoided. Since a user does not need to load the complete data set in a certain area, certain editing operations (e.g. the splitting of a link) can have consequences on existing objects in the database, which are not known to the user, but which refer to the object manipulated by him. When such changes are integrated into the database, these states need to be resolved, e.g. object references to the original link have to be transferred to the new links. A set of rules has been established in order to process such situations automatically. The data model covers a wide range of traffic relevant object as fare as weather information, but it can not hold all items necessary for any application. Therefore INTREST is designed as an open platform. Information which is not included in the core data can be supplemented with a reference to a given object. For example a tourist information service can use the POI information in INTREST (e.g. routing information) and add there own data for hotels and accommodation (number of beds, prices).the INTREST data model and the corresponding data format (IDF) are documented and public (available on request). 5

7 4 System Architecture A INTREST partner or customer can use the INTREST interface for the data exchange with INTREST either by using a client application (e.g. integrated into the editor) or through a web front-end. In both cases an INTREST data file (IDF) is exchanged and can be edited offline through a dedicated INTREST editor application. The INTREST interface itself is implemented as web-service. The INTREST database business logic handles all data with regard to quality checks, extracts data from the database for dispatching and integrates or rejects data objects received. Furthermore it manages the user access and account. VISUM IDF Browser Client http/html Internet IDF Browser Application (FrontEnd) Internet WebService SOAP/XML SOAP-Server business logic GeoDataServer ('INTREST core') DB Figure 3: Sstems architecture with server, front end and editor. 4.1 Server The server consists of a data base management logic and the database itself. The database management logic handles the requests from the interface and 6

8 processes the replies, including the extraction of data. A key feature of the data base management is the user access and the locking -mechanism. As soon as an extract has been generated for editing, these parts of the database are blocked against the editing of other partners in order to avoid conflicting, inconsistent data sets. 4.2 Web Front Ed For extracting a data set from the INTREST server, the user has to authenticate himself, choose the object layers he requires as well as the regional coverage. The regional coverage can be graphically determined by marking the respective tiles of an area. Figure 4: Screenshot of the web front end with graphical selection. 4.3 Network-Editor The two software partners in the project have both develop an editor compatible with INTREST, which allow different parts of the INTREST data model to be edited. Since the INTREST data model is rather large, no single editor will be able to handle the whole data model for the time being. According to the system specifications, other applications can be adapted to become INTREST editors. The INTREST editor loads the IDF and is then responsible for ensuring the quality of the digital map data during editing. No interaction with the database 7

9 occurs while editing (offline!). The editor has to ensure the topological integrity of the network as well as the referential integrity of all loaded INTREST objects. Figure 5: Screenshot of the PTV INTREST Editor. Afterwards, the editor saves the edited data set in the IDF-format. Either integrated in the editor or as a separate process, the original and the edited data set are then compared and the changes are saved again in an IDF-format. In order to be flexible with regard to small changes in the INTREST object model, the editor uses a meta data object description when interpreting the IDF content. This meta object description, which is sent in the header of each IDF file allows the editor to load and to rewrite the IDF in the current format. 5 Business model INTREST has a particular position in the value-added-chain for digital map content since it aims at a content enrichment of commercially available map material through local sources and knowledge. This content is difficult to market on its own since it typically has a limited regional coverage, is not comprehensive enough on its own and since costs for processing the data for sales and marketing outweigh the benefits of the limited content by far. In this context, INTREST offers three basic functions to INTREST partners feeding content into the data pool: The referencing to a common (commercial) map; 8

10 The compilation of separate data pools and suppliers into one database thereby creating a larger, more comprehensive content base; The brokering of the acquired data (together with the underlying commercial map); In this way, INTREST can create a market for focused and small scale content providers for which INTREST offers a central marketing and outlet of data. Such a sales perspective to third parties, while attractive in principle, will only work if INTREST has gained sufficient popularity, i.e. supplying partners and hence the INTREST specific content have reached a certain, critical level. INTREST also offers partners the possibility to edit and enrich a (commercially available) digital map in their specific area and customize it to their own specific purposes on a continuous basis. Users of proprietary and self-maintained maps might eventually adopt the INTREST solution and replace their own isolated map maintenance through INTREST. It is this latter motivation which brings content owners without own marketing activities to collaborate with INTREST during the starting phase. Typical pioneer users of INTREST, which have already indicated their interest are municipalities, public transport providers as well as public authorities involved in road management activities. Commercial digital map provider Map processing into INTREST format INTREST data supplier - data acquisition - conversion to INTREST format - use of editor INTREST - map reference - compilation of separate data sets and sources - broker between supply and demand INTREST data user - internal use INTREST data service provider - processing of data for specific application - integration into service Final customer Figure 6: INTREST in the value-chain for digital map content For the operation of the data pool, entry of data and usage of data needs to be evaluated, otherwise data suppliers cannot be credited according to the level of their contribution to the INTREST data pool. This is done through an internal user account, which records data entry and data extraction. The data entry is 9

11 valued in an internal INTREST currency according to number, type and entry type (update/delete or new). Similarly, data extracted are valued and debited to the users account. As long as no commercial turn-over of data is made by the INTREST operator, no money can be fed back to the data suppliers. As soon as data sales occur, the data suppliers can be rewarded according to their overall contribution to the whole INTREST data pool. No specific tracking of supply and sales of specific data (e.g. one specific hotel information) is envisaged so far. References Michael Landwehr: INTREST - Intermodal Referencing System for Transport Related Data in Bavaria, ERTICO ITS Europe 10th World Congress,