We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.WebUI.POIDataProvider R5 - FIWARE Forge Wiki

FIWARE.OpenSpecification.WebUI.POIDataProvider R5

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.WebUi.POIDataProvider
Chapter Advanced Web-based User Interfaces,
Catalogue-Link to Implementation POI data provider
Owner Adminotech, Adminotech



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright © 2013, 2014 by University of Oulu
Copyright © 2015 by Adminotech Oy

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.


This project targets to define Points of Interest Data Provider (POI-DP) and demonstrate its feasibility with a proof-of-concept implementation.

POI-DP is a generic enabler, which provides spatial search services and data on Points of Interest via RESTful web service API. The data model for representing POIs is modular and based on the entity-component model. In the proposed model, each POI is an entity, which is identified by a universally unique identifier (UUID). The data related to an entity is stored in different data components, which are linked to the entity using the UUID. These data components are independent of each other and every POI entity can have a different set of components. This enables the concept to serve a wide range of interest groups, as the data model can easily be extended by application specific data components. POI data can be distributed and different data components can be administered by different organizations using different policies.

The project develops

  • Specification of POI-DP API
  • A proof-of-concept implementation of distributed POI-DP network,
  • An example of application area specific POI-DP,
  • A proof-of-concept web application for POI functionality demonstration with 3D content,
  • guidelines to design and implement application area specific POI-DPs, and
  • guidelines for specifications of application area specific POI-DP APIs.

Applicable parts or entirety of specifications will be contributed to standardization e.g. by OGC.

Target Usage

POI data can is useful in wide variety of applications. The most apparent applications are connected to tourism and finding something interesting in new places in general. However, generic POI data associated with application area specific data can be very useful in different applications. Examples:

  • Detailed harbor information in yachting
  • Detailed description of underground piping and cables to help avoiding them in construction work
  • Information of geographically distributed devices requiring maintenance
  • Hotels, festivals, fast food places, emergency hospitals, whatever information a tourist needs

Example Scenario

Use case: A skipper of a yacht is approaching Kemi. He wants to find detailed information of the guest harbor, find a dining place and a hotel near to harbor.
The following subsystems take part in this scenario:

  1. a mobile device to query the data
  2. a nautical application in the mobile device - The application can show nautically interesting POIs on a nautical chart.
  3. a tourist application in the mobile device - The application can show tourism related POIs on an ordinary map.
  4. a nautical server - The server does queries to a generic POI server for basic POI data, filters it for nautically interesting POIs, and appends POI information with nautically interesting details: e.g. depth of the harbor and special harbor services.
  5. a tourist server - The server does queries to a generic POI server for basic POI data and appends POI information with data relevant to tourists: e.g. classification (stars) of the hotels, class of dining places (Chaîne des Rôtisseurs, Michelin stars, etc.)...
  6. generic POI servers - A generic POI server can contain a huge amount of POIs. It is specialized in spatial searches.

Different data components of a POI may be stored in different databases in different servers managed by different organizations. These data components are associated to the POI by an UUID that identifies the POI.

Flow of operation:

  • First, the skipper uses a nautical application that shows nautical POIs on the navigation chart.
  • The nautical application send a query to a nautical POI server that in turn sends a query to a generic POI server.
  • The nautical POI server uses UUIDs of POIs to search its nautical database for extra information, and responds to the application with POIs augmented with nautical data.
  • The skipper selects the POI corresponding to the harbor, reads the extra information and drags and drops the POI to a tourist application.
  • The tourist application gets the UUID of the POI and focuses to the area of interest - harbor of Kemi. The tourist application sends a query to a tourism related server that in turn queries a generic POI server for nearby hotels and dining places.
  • The tourism server adds proper tourist information from its database to the response to tourism application.
  • The skipper can now browse more detailed data about the interesting services.

Connections to Results of Other MiWi Projects

Augmented Reality

POI-DP acts as the main data source for the Augmented Reality (AR) GE reference implementation. Different information about POIs can be visualized in the AR view, such as basic information about a POI or a 3D model representing the POI.

Real Virtual Interaction

For those applications that interact with "Internet of Things", a real-virtual extension is provided. A POI identified by its UUID is associated to a real device either by the real-virtual POI extension server or by the real-virtual interaction server. The servers cooperate to provide a connection from the application to the device. The details of cooperation will be negotiated during the project. This feature facilitates control of actuators e.g. directing a camera or adjusting a thermostat, and reading sensors e.g. a thermometer or a sea level gauge.

Basic Concepts

  • Modular POI data model (based on the principles of the entity-component model)
    • Easy to extend by introducing new data components
    • Easy to distribute as data components are independent
    • POIs relative to another e.g. restaurants within a cruise ship
    • cases where lat/long coordinates are not feasible
    • 3D data associated to POI
    • Hierarchy of POIs
  • RESTful web service API for querying and modifying POI data
    • Spatially limited searches
    • Searches constrained to specific categories e.g. dining, golf course, cemetery, dentist, casino, museum, etc.
    • Temporal constraints, e.g. for finding restaurants that are currently open
    • POI data modification functionality (add, update, delete)

Generic Architecture

A RESTful service architecture is defined for hosting and provisioning the POI data. The services provide different functionality for querying, accessing and modifying the POI data. The services are invoked via RESTful APIs using the standard HTTP protocol. As the POI data can be easily distributed due to its modular structure, the natural outcome is that the service architecture can be distributed as well. Different POI service backends can host a different set of POI data components.

The distributed service architecture also enables implementing service composition, i.e. service backends that do not necessarily host any POI data themselves, but instead fetch the POI data from a set of other backends

The POI data can be searched and accessed via RESTful web service APIs. The POI access API enables accessing specific data components for POIs based on the UUIDs of the POI entities. The POI search API provides different spatial search functions for a client to find relevant POIs in a certain location.

Figure POI-DP-1: Overview of the POI-DP service architecture

Main Interactions

The POI data provider is deployed as a RESTful web service. It has an easy to use API that can be accessed with reqular HTTP requests.

Querying POIs

POI data can be queried in different ways. The goal is to support a variety of different use cases utilizing the POI data. The query operations are accessed with standard HTTP GET requests.

Radial search

The most common use case is to search for POIs near a certain location. For this, the service provides a spatial search functionality, namely radial search. It can be used to find POIs around a certain location within a given distance, i.e. circle radius. The location is given as latitude and longitude in degrees, and the radius in meters.

Bounding Box search

Bounding Box search enables searching POIs inside a given bounding box, i.e. a rectangular geographical area.

Access POIs by UUID

In another use case, the client already knows the UUIDs of the POIs it is interested in. In this case, the POI data can be accessed directly with the POI UUIDs. Several UUIDs can be given in a single query.

Modifying POIs


New POIs can be added to the database. The POI content is sent by the client using HTTP POST request.

Update POI

Existing POI data can be updated. The updated POI content is sent by the client with HTTP POST request.

Delete POI

POIs can also be removed from the database. The client can remove existing POIs using HTTP DELETE request.

Basic Design Principles

  • The core POI data must be compact, so that it does not contain much such information that is not needed in most applications. This is to keep data bases small and fast, and to speed up responses to queries.
  • It must be easy both technically and organizationally for an application area or an organization to start utilizing the POI data and to append needed extensions to data. Generic software base, extension templates, and well documented extension guides must be provided for this end.
  • An organization must be able to administer data in its interests. E.g. a hotel chain must be able to maintain descriptions of its hotels without cooperation with other organizations.
  • Cross usage between generic and application area specific clients and servers must be possible without error conditions. Of course some data will be lost or missing in transactions.
  • Empty data fields are not transmitted.
  • The client can limit the query:
    • maximum POIs returned
    • list of wanted data fields
    • language selection for applicable text fields
    • temporally: e.g. return only restaurants that are currently open

Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

The following give complementary views to same information.

Re-utilised Technologies/Specifications

  1. PostgreSQL PostgreSQL is an open source object-relational database system.
  2. PostGIS Spatial and Geographic objects for PostgreSQL.
  3. MongoDB MongoDB is an open-source document database with JSON-style documents.
  4. W3C POI Core Points of Interest Core, W3C Working Draft.
  5. OGC POI OGC Points of Interest Encoding Specification.

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

Annotations refer to non-functional descriptions that are added to declaration of native types, to IDL interface definition, or through global annotations at deployment time. The can be used to express security requirements (e.g. "this string is a password and should be handled according the security policy defined for password"), QoS parameters (e.g. max. latency), or others.
AR → Augmented Reality
Augmented Reality (AR)
Augmented Reality (AR) refers to the real-time enhancement of images of the real world with additional information. This can reach from the rough placement of 2D labels in the image to the perfectly registered display of virtual objects in a scene that are photo-realistically rendered in the context of the real scene (e.g. with respect to lighting and camera noise).
IDL → Interface Definition Language
Interface Definition Language
Interface Definition Language refers to the specification of interfaces or services. They contain the description of types and function interfaces that use these types for input and output parameters as well as return types. Different types of IDL are being used including CORBA IDL, Thrift IDL, Web Service Description Language (WSDL, for Web Services using SOAP), Web Application Description Language (WADL, for RESTful services), and others.
Middleware is a software library that (ideally) handles all network related functionality for an application. This includes the setup of connection between peers, transformation of user data into a common network format and back, handling of security and QoS requirements.
PoI → Point of Interest
Point of Interest (PoI)
Point of Interest refers to the description of a certain point or 2D/3D region in space. It defines its location, attaches meta data to it, and defines a coordinate system relative to which additional coordinate systems, AR marker, or 3D objects can be placed.
Quality of Service (QoS)
Quality of Service refers to property of a communication channel that are non-functional, such a robustness, guaranteed bandwidth, maximum latency, jitter, and many more.
Real-Virtual Interaction
Real-Virtual Interaction refers to Augmented Reality setup that additionally allow users to interact with real-world objects through virtual proxies in the scene that monitor and visualize the state in the real-world and that can use services to change the state of the real world (e.g. switch lights on an off via a virtual button the the 3D scene).
A Scene refers to a collection of objects, which are be identified by type (e.g. a 3D mesh object, a physics simulation rigid body, or a script object.) These objects contain typed and named data values (composed of basic types such as integers, floating point numbers and strings) which are referred to as attributes. Scene objects can form a hierarchic (parent-child) structure. A HTML DOM document is one way to represent and store a scene.
Security is a property of an IT system that ensures confidentiality, integrity, and availability of data within the system or during communication over networks. In the context of middleware, it refers to the ability of the middleware to guarantee such properties for the communication channel according to suitably expressed requirements needed and guarantees offer by an application.
Security Policy
Security Policy refers to rules that need to be fulfilled before a network connection is established or for data to be transferred. It can for example express statements about the identity of communication partners, properties assigned to them, the confidentiality measures to be applied to data elements of a communication channel, and others.
Synchronization is the act of transmitting over a network protocol the changes in a scene to participants so that they share a common, real-time perception of the scene. This is crucial to implementing multi-user virtual worlds.
Type Description
Type Description in the context of the AMi middleware refers to the internal description of native data types or the interfaces described by an IDL. It contains data such as the name of a variable, its data type, the hierarchical relations between types (e.g. structs and arrays), its memory offset and alignment within another data type, and others. Type Description are used to generate the mapping of native data types to the data that needs to be transmitted by the middleware.
Virtual Character
Virtual Character is a 3D object, typically composed of triangle mesh geometry, that can be moved and animated and can represent a user's presence (avatar) in a virtual world. Typically supported forms of animation include skeletal animation (where a hierarchy of "bones" or "joints" controls the deformation of the triangle mesh object) and vertex morph animation, where the vertices of the triangle mesh are directly manipulated. Virtual character systems may support composing the character from several mesh parts, for example separate upper body, lower body and head parts, to allow better customization possibilities.
WebGL → (Web Graphics Library) is a JavaScript API for rendering 3D and 2D computer graphics in web browser.
Personal tools
Create a book