Development of a low cost graphical interface for traffic data representation: application to DATEX information.

Transcription

1 Development of a low cost graphical interface for traffic data representation: application to DATEX information. Ignacio Sánchez Reig Civil Engineer LISITT, Univeristy of Valencia. Ph. (+34) i.sanchez@robotica.uv.es P.O. Box: 2085, VALENCIA SPAIN Vicente Niñerola Molina Computer Science Engineer LISITT, Univeristy of Valencia. Ph. (+34) Sento.Ninerola@robotica.uv.es P.O. Box: 2085, VALENCIA SPAIN - Some words about Geographical Information Services (GIS). Manuel Cid García Computer Science Engineer LISITT, Univeristy of Valencia. Ph. (+34) Manuel.Cid@robotica.uv.es P.O. Box: 2085, VALENCIA SPAIN Nowadays the best way to show information for both operators and end users is a graphical interface. Classical GIS, where the cartographic elements, the data, and the engine are located in the same server, can be a solution, but it has many constraints. The main detected are: It normally has high costs in development and in cartography maintenance; this means that usually it is very difficult to move from one provider to another, due to the huge amounts invested. It has many limitations to present real time data, And has many restrictions when traffic information is shown over the Internet. Normally, users must install some kind of plug-in or client application on the remote workstations. The dimension of the service server is very big, because it hosts the cartographic database, and also all the data. It must process data, locate and serve it to all the clients/connections. Of course a GIS is a powerful tool, but from our experience it is only recommendable under certain data mining requirements. At this moment there are many cartographic services based on the Internet that can be used to present information. These services have been shown very useful for traffic data representation. The main existing services are: GoogleMaps, Microsoft LocalLive and Yahoo! Maps. All of them are evolving quickly to provide the best service, but from our experience in Spain, the best one for our purpose is the GoogleMaps service. In the following table there is a comparison of these mentioned services: Terms of use Google Maps Microsoft Local Live Yahoo! Maps - Public access restricted in the Internet - Max queries - Public access restricted in the Internet - Max queries. - Public access restricted in the Internet - Max queries Version Beta v2 (Feb. 07) Beta v3 (March 07) Beta v3 (Feb. 07) API 1 API (AJAX) 1 API (AJAX) 4 APIs (AJAX & 3 Flash) Documentation API & examples API & examples API & examples Ortho-photos Quality Very good. Street level Good. City level detail. Good. City level detail. detail. Cartography Quality Very good Very good Poor. Navigation control Zoom, pan & change view Zoom, pan & change view Zoom, pan & change view GoogleMaps vs Microsoft Local Live Test Map events Good Good Marks draw Simple use Simple use Page 1 of 6

2 Google Maps Microsoft Local Live Yahoo! Maps Drawing efficiency Quick Quick Line draw Simple use Quick Full delete Simple use Slow & unstable Independent delete Locator (Geocoder) Street level detail No kilometre points. Street level detail No kilometre points Implementation Easy E Diffusion Very extended A lot of support (forums) Less extended No too much support in Spain -Trafficviewer development. For this reason, we at LISITT, in collaboration with the Servei Català de Trànsit in Catalonia (SCT), decided to develop traffic information tools, based on GoogleMaps. The first service, named Trafficviewer, has been applied to the DATEX information coming from France, Andorra, and the rest of Spain; however, this is just a first step for the later expansion of the information to CCTV images, the static inventory of resources (location of radars, cameras, VMS, loops, etc.), the definition of traffic flow (congestions) maps, etc. - System Architecture. SCT receives traffic information from France, Andorra, and the rest of Spain by means of the DATEX system. This data (including SCT s own data) are in a standard format where the traffic incident is described and located. The traffic viewer application translates the location into an xml format and it is drawn on top of the Google Map, and includes the additional incident information. The main advantage of this application is that it is lightweight and only the traffic data server part is needed at the SCT, all graphical functionality are provided by the Google server. The service can be accessed over the Intranet or from any workplace, where Page 2 of 6

3 Internet is available. However, for this last to be possible it is necessary to place the application in a public accessible server. Regarding the modules that define the packets diagram application, these are represented in the following schema: Config Datex TMC Sources TIC Drawing Library Servlets Other Menus & other jsp Utilities - Trafficviewer interface & capabilities. Layers Cameras Radars Representation Module Configuration Module Aux. Classes Module Queries Mgmnt. Module Sources Processing Module Layers Processing Module The aspect is very well-know by the users of GoogleMaps. This is something positive, because we are not introducing new interfaces to learn by the user. There are zoom, and pan possibilities, also hybrid, map or satellite presentation layers can be shown. As mentioned before, all geographic and graphic support is provided by Google. The added value rests in the information presented (traffic incidents), and the filtering tools. Information content: location of the incident, road code, kilometre point, date time, cause, impact, level of service (colour code), length, type of incident, etc. The grouped types of incidents are shown in the following table: ROADWORKS WEATHER ADDITIONAL LANE MOUNTAIN PATH TRAFFIC JAM LEVEL REGULATION PHRASES (according with DATEX dictionary) RMT FOG, RAI, RIC, WIS, SFL, WIN RET, CTR, LCD RCD, SM TNC, LSO, ACI, FLD, ESP, EVF, EPD, ROC, BKD, FIR RCA, LC2, LC3, LC4, LC5 LCR, LCC, LCL, LCH, LC2, LC3, SAT Filtering characteristics: data source, type of incident, province, interval of time, etc. All these filtering characteristics can be concurrent. The incident can be directly located on the map by mean of the road code and kilometre point (see right side bar). Number of active incidents (number of roadwork incidents) Page 3 of 6

4 The colour of the balloon represents the level of service, so the operator can detect quickly where the problems are located. Incidents or locations can be searched by mean of the x,y co-ordinates, or by the address. This screen capture corresponds with the situation occurred during the last snow storm in the northern region of Spain, with many secondary roads closed (L.O.S. in black). The incident can be located directly clicking on the right column list, and they are sorted by road code and kilometre point. In the bottom area the filtering menus are Page 4 of 6

5 displayed. In this example the province list is displayed. When the user clicks on a balloon, the detailed information is displayed as shown in the following example: The incident can be defined by many different and successive messages (for example, explaining the evolution of the incident), this is kept grouped by the application and can be shown by clicking in the left side balloons within the incident details. Also additional information, like a zoom of the area, or camera images can be displayed in these description areas. -About the future development: We find that these kinds of services are actually a big success, and there will be more in the future. Google, Microsoft, Yahoo, are competing in this area to improve the basic capabilities that can be used by developers to personalise the services. The short term evolution will provide the implementation of real time images, guided services, representation of segments and areas, etc. Many of these services are already available in the USA. Also it is very important the possibility of reporting the information directly from the road network by mean of a GPS, directly into the application by mean of the (x,y), co.- ordinate. Page 5 of 6

6 In the figures above, we show a segment event representation, (i.e. congestions length), but these are still under development. Also the implementation of real time cameras images has been tested, and any inventory of resources can be displayed easily (i.e. VMS, loops, paths, cameras, accidents, black spots, etc.). The development of applications for mobile devices is also under consideration. To conclude, we would like to state that this platform has unlimited possibilities for new developments. It is very flexible and extensible; it doesn t require many programming efforts, neither big hardware requirements to offer a first level service, and the interface is very familiar to users. Page 6 of 6