In the context of Smart City applications, the usage of Smart City APIs, for exposing services and data towards web and mobile applications, is quite frequent. Most of the mobile solutions, using the Smart City APIs, are focused on a single city which can expose several services, contextualized on a single geographic area. In fact, passing from one city/area to another, the users must change application and services, and consequently, discontinuities problems could occur at the border. This also happens for the lack of interoperability among the Smart City APIs and related operators that may strongly differ, depending on the applicative levels at which they are developed. A large part of the services proposed via Smart City APIs are geo-localized, and as a result, may provide different results according to the GPS coordinates of the client context. In this paper, the problem of federation of smart city services is addressed by proposing a solution for federating smart city APIs, related knowledge-base, and ontology. To this end, a formal model has been presented to autonomously federate API services together with other requirements (e.g., efficiency, overlapped and included areas of competence, distributed searches, security and privacy, scalability, interoperability among different smart city application servers) which are typically neither all satisfied by classical Geographical Information System (GIS) solutions that federate the services at level of database nor by those based on Internet of Things (IoT) Brokers. The solution is open-source and has been developed in the context of Snap4City European platform enhancing former Km4City Ontology and API of Sii-Mobility national project (https://www.snap4city.org ). The solution is presently in use in Snap4City federation of Smart City Services in Europe, among several cities/area including, Florence, Tuscany, Bologna, Helsinki, Antwerp, Valencia, Dubrovnik, Mostar, just to mention a few.
Super Servicemap (https://www.snap4city.org/MultiServiceMap/) enables users to enjoy Servicemap services of different region (like Florence, Helsinki, and Valencia) without the need to change the application when passing from a region to another. It is based on a distributed system of Smart City API (SCAPI) to create a federation of City services. The federated network is conceptually a middleware based on a set of services, independently offered, and maintained by a number of cities/areas. The main features of the Super Servicemap are as follows:
- provides a network of geolocated services without constraining the providers to agree on the service shared with the other providers;
- allows a Node, called Super, in the network, which manages data and services regarding a region, to provide different kinds of services without constraints and to autonomously decide the set of provided /removed services;
- provides the clients a GIS/IoT list of results services without reporting eventual duplications on overlapped and/or duplicated services;
- supports distributed search on the network of federated Nodes. The computational workload for providing results is distributed among the nodes which can work only on their own data;
- supports services (non-) georeferenced; In fact, there may exist services that are generic for a certain Node and not associated with a GPS position (e.g., a global service of payment, a global service to save the car position);
- does not pose limits to the size/shape of the geo-area and of the shared number of services;
- avoids addressing the problems of data privacy in a centralized structure;
- decides (or not) and provides to join the network of services. In fact, it supports joining and abandoning the network without the need of network restructuring. The effect of modifications is immediate effect without any service reloading or disruption;
- offers geolocalized and non-geolocalized information and services in the network;
- provides a scalable and fault tolerant solution for recovering services;
- provides query results in real time even in presence of a large number of Nodes involved;
- provides search query results in the coherent format with the expected response of the single services. For example, REST calls in some cases provide responses in JavaScript Object Notation (JSON), eXtensible Markup Language (XML) or Hypertext Markup Language (HTML) formats;
- supports services based on IoT Devices. This is possible if the Node is able to manage IoT Devices as an IoT Broker or the Knowledge Base, KB, exploited by the Node is capable to model, index, and search queries oriented to IoT Devices. To this end, the Km4City Ontology has been extended to model IoT Devices as well as including a range of IoT Brokers, protocols and devices supporting the Industry domain;
- supports the creation of disjoint federations of Nodes as well as the presence of independent services, which are not connected to any federation of Nodes;
- supports an interactive user interface;
Each node should provide its own data and services. The identified area for each node is more logic rather than geographic because when a number of services are accessed from a city/region, in most cases, they are not precisely into their legal borders. For example, regional railways, major roads, etc. typically are continued to the next main cities. As one can see in the following figure, two regions of services may be overlapped or one included in another, and services can be present in both (duplicated) or in one, and even shared among them.
Fig. 1 - Overlapped and included areas of services, with duplicated, exclusive, and shared services, of two areas.
Architecture
As can be seen in the following figure, Node (a) manages data of Area 1 by the Km4City RDF store and ServiceMap. Nodes (b) and (c) share the same geo-Areas 2a and 2b, by the Km4City RDF stores, in a balancing and fault tolerant approach. Node (d) is covering Area 3 with an IoT Orion Broker FIWARE and related storage. While Areas 4a and 4b are managed by an independent service, some of the Nodes manage overlapped areas. It is noted that some of the areas covered by Nodes contain multiple disjoined subareas. Each node provides access to services to client applications of the federated network, and (ii) exploits SCAPI of the actual Smart City service providers and of other Supers. The Nodes/Supers can be on the front of the SCAPI interface of two kinds of smart city servers:
- Snap4City/Km4City, which provides services via SCAPI, querying the smart city server with SPARQL queries as well as exploiting Km4City Ontology on the RDF store Virtuoso. The same solution can provide GIS data via WFS/WMS;
- SSM2ORION (SuperServiceMap to Orion FIWARE) which provides data information accessible from FIWARE solution based on IoT Orion Context Broker with storage support. The module converts the call on SCAPI to NGSI V2 REST Calls.
Fig. 2 - General Architecture of Super and Federated SCAPI network
User Interface
In this section, we present details on the designed and developed we-based user interface, as depicted the following figures. Using the combo-box in the center, the user can easily switch between different regions/organizations (e.g., Firenze, Helsinki, Valencia) or consider all of them (using the Super Servicemap).
The menu on the lower left is used to show the weather information (e.g., minimum/maximum temperature) in a region. Using the LOGIN button, on the top of the menu on the right, it is possible to login with different users/organizations. The menu on the right comprises two tabs. One is dedicated to categories (e.g., Accommodation) and sub-categories (e.g., Camping, Farm, Hostel) associated with Regular Services while the other contains categories (e.g., Area) and sub-categories (e.g., Gardens, Sports_facility) regarding Transversal Services. The user can select, in addition to the possibility of instant searching, a set of categories and sub-categories of Regular or Transversal Services, to find them. Also, it is possible to limit the search results, using N. Results, or filter them, using the Text Search and Search Range (e.g., ) together with the Service Model and Value Type options.
Fig. 3 - Super Servicemap - Main page
As can be seen in the following figure, the menu on the upper left is used to obtain information on Public Transportation, Address Search, and Events together with the possibility of text service search in a desired area. Considering the Public Transportation tab, it is possible to detect the current position of vehicles, using the associated Agency (and Line). The user can also see a Route (or all of them) of a Line and a Stop/station (or all of them) of a Route, together with detailed information on stops. Also, it is possible to Search Path, considering the Route Via (e.g., car, public_transport) and Start date&time options, and Search Geometry between two selected points.
Fig. 4 - An example of path and geometry search
As depicted in the following figure, Using the second tab, Text Search, it is possible to search for a service using the text field provided.
Fig. 5 - An example of text search
As presented in the following figure, the Address Search tab is used to search for addresses by providing a Position and maxDists (i.e., radius), and a set of Categories and sub-categories, considering different options (e.g., sort results by distance).
Fig. 6 - An example of address search
The Event tab is used to search for daily, weekly, or monthly events in a desired area. Considering the described services, using the Disk icon, it is possible to see and copy the associated API query, used for retrieving result.
Fig. 7 - An example of event search
Also, as shown in the following figure, using the Disk icon, it is possible to see, save, and copy the associated API query in different formats including with queryID, JSON or HTML.
Fig. 8 - Saving search results in different formats
