In part one of this article, we discussed the background to the DTI-funded NERVE (North East Regional Visualisation Environment) project. To summarise, its aim was to research methods of allowing regional organisations to share information in a variety of scenarios, in order to meet the demands of recent legislation, such as the Traffic Management Act and the Civil Contingency Bill, and initiatives such as INSPIRE and the DNF (Digital National Framework).
The main project prototype was built around the scenario of an emergency situation to take place in the North East of England. Were such a situation to arise, emergency response organisations including Fire, Police and Ambulance services both in the field and in the office would need immediate access to relevant spatial and non-spatial data. Using this information, operatives could develop strategies to prevent the situation escalating and resulting in further damage, casualties or fatalities.
In an emergency situation, several sources of information would immediately be needed; types of roads surrounding the area, density of population/housing, location of schools (including type of school, number of pupils), locations of any vulnerable people housed in the area (e.g. sheltered accommodation, dialysis patients), potentially flammable objects or buildings containing hazardous material, location of hospitals and emergency services stations to name but a few. All of this information is normally held by different organisations in remote locations.
Although these existing data sources fulfilled the requirements of the end users they were originally developed for, they were typically not suited for access and use outside their initial application or user domain. One of the main challenges of the project was bringing together these data sources in a way that they could be used together and for a common purpose. Three further problems emerged:
(a) Identifying the sources of data available to the end user
(b) Accessing this data quickly, and then;
(c) Analysing the data effectively
The initial problem of gathering information was addressed with the implementation of an OGC (Open Geospatial Consortium) CS-W (Web Catalogue Service) by Newcastle University. The CS-W supports the ability to publish and search collections of descriptive information, or metadata, for data and services. This metadata can be queried by the CS-W through the use of keywords, and matching resources can be accessed for evaluation and further processing by both human operatives and software.
As an example, an emergency scenario requires operatives to establish whether there are any schools in the area. Using the keyword ‘school’, all datasets that include this keyword will be identified up by the CS-W. The CS-W is built according to OGC, ISO and OASIS specifications using C# and .NET Framework, and has been implemented as a web service so that clients can use it remotely. WordNet® from Princeton University was selected by the team to provide a powerful yet straightforward mechanism to allow simple language queries into the catalogue web service. The intention is to make the software open source in due course.
Having identified the relevant datasets, the next task was to overcome the limitations of what can be done with such potentially large quantities of data, particularly the vector data, and its effect on performance. In a normal three-tier architecture (client, business logic, resources), such data would be downloaded to a thick client on the desktop for merging and processing, but this is unfeasible for mobile devices that have limited processing power and limited connectivity. It is also much harder to share data between all the agencies in such an environment, as data generated specifically by one client may not be suitable for others.
Developing the solution
The NERVE team proposed a solution to this problem by expanding the standard 3-tier architecture to include a new layer known as the ‘common layer’. The common layer, built using the BPEL (Business Process Execution Language) and a SOA (Service Orientated Architecture), contains temporary derived resources that are being used to solve the problem(s) in hand. The common layer then naturally resides above the resource layer but beneath the business layer (see Figure 1).
This was implemented by 1Spatial via the provision of lightweight, highly configurable, shared geospatial workspaces that provided a single source of data to the clients. The configuration and population of the common layer is managed by a decision support system that attempts to translate the client’s requirements, expressed in a domain specific language, into parameterised data manipulation tasks (import, translate, conflate etc). This is achieved using the catalogue technology previously described. In summary, this common or ‘middle’ layer acts as a cache to hold data locally. Once the data is in this common layer, any client can connect to it via a WFS (Web Feature Service) interface and access the data quickly and easily, then generalise, merge, conflate or perform local analysis on the data.
The common layer supports both client-initiated requests and server-initiated, or ‘push’ requests. These are particularly suitable for streams of rapidly changing, but low volume data. The common layer provides a broker interface through which these push services can be accessed. This chain was implemented using a mixture of the OGC’s Sensor Web Enablement framework and the WS-Notification (WS-N) standard from OASIS. The broker provides a central point of control that helps simplify the identification and use of the available push services, while shielding the original sources from the extra load generated by the NERVE clients. Protection of third party sources in this way is particularly important in emergency situations, where abnormal levels of system activity are likely to be created and must be managed at that time.
Imass have developed client components for the project that allow the visualisation of real-time location data. The client provides access to a “shared view of the world” to both office-based and mobile personnel involved in the incident, supplying all users with the same view of the incident location. The client has the capability of displaying both 2.5D and 3D data – this is beneficial to personnel involved in, for example, line of sight analysis.
In order to visualise events in real-time the client handles ‘push’ requests received from the common layer. The available WS-N topics are first listed on the client screen. Selecting a topic will subscribe to the WS-N messages and will make a new data layer available to the user. If new topics are received, the list updates automatically, reducing the time spent by the user making requests for data updates. This technology is used, for example, to provide a shared view of the current location of GPS enabled resources (e.g. policeman, patrol car) on the client.
Significance of this work
So what does this mean in real-world terms? An emergency call centre operative would be able to call up all the relevant information within minutes, visualise the location(s) and share this same view with, for example, police and fire services. Not only does the system provide access to the data, it also has the potential to allow the user to analyse it, i.e. the operator can request road closure locations, then use this information to direct resources to the locations quickly.
Another useful query could be to find other fire stations in the area; the operator simply zooms out to see the locations displayed on the map, even if they are located outside of the current operational area. Officers on the scene have access to this predefined and shared view of information on hand-held devices but they can also run their own queries according to their individual needs. A fire commander may want to check for gas in the area, so types ‘gas’ and runs the query function. By using term expansion software, the search is automatically expanded to include other relevant terms, such as ‘vapour’, ‘flammable’, ‘canister’ etc. The matching data is then returned to the user as a new layer on screen.
Architecture and Components: an overview
As shown above, the NERVE project has developed a general-purpose architecture for the sharing of geospatial models and application views using distributed data sources and on-the-fly processing. Components of the NERVE system were concretely developed as web services using a variety of programming languages like Java, C# and Visual Basic, and include :
Web Services: As a highly decentralised software system designed to support interoperable machine-to-machine interactions over a network, web services have been used extensively within NERVE. Web services provide an easy to use mechanism for connecting components that have been developed for different computing systems and are interoperable.
WFS: (Web Feature Services) is an OGC standard which provides an interface that allows requests for geographic features. WFS services are used in the NERVE system for the delivery of vector-based geographic objects from remote data objects. In the NERVE system metadata, allowing data end points discovery, are being registered in catalogues (SQL Server databases). These catalogues provide the necessary means for clients to connect to the remote WFS services and consume vector data delivered as GML.
WMS: (Web Map Services) is an OGC standard which provides an interface that allows requests for geographic data. The geographic data are being delivered to the calling clients across the web using platform independent calls. A web map service uses spatial data stored in a relational database management system (RDBMS) or other means and renders them using predefined styles in order to create raster images, which are delivered to the end client through the Web.
BPEL: is a business process modelling language held as XML. BPEL scripts are used in the NERVE system to allow the creation of Infospaces and to model layers of spatial information in the Infospaces.
FDO: (Feature Data Objects) The data in the system is rendered for display by the Portrayal Service which consumes the WFS and provides the client application with a WMS service. This provides a 2D flat map view that can be observed from different angles of rotation and pitch. The 2D Portrayal Service was implemented using MapGuide Open Source 1.1. MapGuide uses FDO providers to access WFS data sources and provides a WMS service to expose data to the client. FDO providers supply a set of application program interfaces for the manipulation, definition and analysis of geospatial data, regardless of its storage format.
One of the devices investigated was a 3D client; a hand-held device to view the scene in 3D models (CityGML). Future developments would extend the drawing of 3D objects to cover the 3D rendering of line and area objects, and the rendering of text would also be enhanced to improve its readability. The project team also intends to render CityGML directly onto the map and render the map tiles using terrain data. They also intend to investigate further the use of the Web3D service and server rendering, which would enable the rendering of images for lightweight clients.
The key innovation of the project was the creation of a single interactive model of a region within a web-services environment; a model to which all users can contribute. Emphasis was kept on the need to exchange and visualise data in real-time. The potential for such technology as a key part of Spatial Data Infrastructures, such as INSPIRE and beyond, is significant and need not be confined to just emergency situations. The NERVE project has uncovered technology that would revolutionise streetworks planning, local authority or utility searches, or handling of major emergency situations.