HOW TO: Federation of Smart Cities, by federating Smart City API and Knowledge Base

The classic GIS interoperability is limited to 1:1 exchange of geographical data for example exploiting protocols as WFS (Web Feature Service), WMS (Web Map Service), for the exchange of Maps and geoelements such as paths, points of interest, road elements, road graphs, etc. GIS protocols, according to their definition, they are typically unsuitable as API for providing data related to smart services, such as smart parking, subscription on alerts on environmental conditions, etc., as needed for smart city applications. Most of vertical Smart City API based solutions are typically focused on a limited range of data by using SQL databases which in turn can provide support for geolocated information and may be federated at level of the database.

Snap4City solutions can be federated each other, creating a cross-city environments among cities, regions, and in the same city among different areas if needed.  The federation is at level of smart city API, and this allows to mobile Apps to pass from one city/area to another without loss of continuity. This feature could be performed to federate Al Madinah and Al Munawarah Cities. Please note that, Snap4City is 100% open source, so that the solution provided can be easily replicated without costs of licensing.

Federated Knowledge Bases, Multiple Snap4City connected via their Knowledge Base, Smart City APIs allows the creation of mobile applications that may move from multiple cities and area accessing data and making queries transparently. This solution is presently in place among the Knowledge Bases of: Antwerp/Helsinki, Tuscany/Firenze, Sardegna, etc. The resulting Service is called SuperServiceMap and it is integrated in the Smart City API. [FederatedKnowledgeBase2020]

A distributed Smart City API based solution for a set of cities, let say a federated network of Smart City APIs may provide a number of advantages.

  1. support distributed search on the Federated Knowledge Bases network;
  2. support connection with smart city of any size in terms of number and volume of data sets providing services of the nodes. In addition, the geospatial size and shape of each node may be: (i) not regular (nor a circle but a shape), and multiple connected (so called multi-polygon), (ii) partially overlapped with other nodes, (iii) totally included into those of other nodes, (iv) disjoined and even far each other (this means that the union of all the areas can be disjoined with respect to the global map of the earth);
  3. Support nodes with a different number of services available. This implies that not all kinds of services and data may be necessarily available in all Federated Knowledge Bases;
  4. Support nodes with georeferenced services or not. This means that are general for the area addressed and not specifically related to the GPS position;
  5. respond to API calls in terms of services in transparent manner passing from one node to another or when the service needs to provide results coming from more Federated Knowledge Bases;
  6. support access control to prevent access to data and services by not authorised users. Since the passage of a user from one Knowledge Base to another of the Federated Knowledge Base network may imply the sending of requests which may try to access at private data/services;
  7. support the addition/removal of Federated Knowledge Bases in the network without the need of fully restructuring of the network and modifications have an immediate effect without any service reloading or disruption;
  8. provide results in real time also when a large number of Federated Knowledge Bases/areas are involved. The implementation should also provide support for creating redundant solutions with high resilience;
  9. provide the response in the coherent format with the expected response of the single services. Thus, the results of the federation may need to be merged to produce the response in any format: JSON, XML or HTML.
     

In order to avoid having a single point of failure, the Federated Knowledge Bases Super can be replicated into each node and the list of Super services on top of ServiceMap can be put accessible in one or more web servers for update. Each ServiceMap has a representation of the multi-polygon addressed by the nodes (with their data/services) and thus of their partitioning over the nodes of the Federated Knowledge Bases network. In more details, each Federated Knowledge Bases may register in the Super network the descriptor of the multi-polygon area of your competence. This approach permits at the Supers to redirect the queries to the nodes that could provide the service and data. Thus, the Supers do not need to hold the data of the nodes and perform the distribution of queries only to the involved nodes, to finally collect the results and performs data fusion. The Supers as well as the ServiceMaps/SSM2ORION may also implement some query caching solution as all the other Federated Knowledge Bases.

A single Snap4City platform isntallation can serve with multiple services a number of joined disjoined areas/cities. Thus optimizing the effort. this is the perfect solution for regional or national support buildings. 

  1.