This is the home page of the relational indoor positioning database project, developed within the Data Science and Automatic Verification Laboratory at the University of Udine, Italy.
The database aims to pose itself as an integrated and generalizable framework to store, manage and leverage fingeprint positioning data collected by multiple sensors within indoor premises.
The database schema, which is depcited in the figure above, is divided into four main sub-schemas:
- fingerprint sub-schema: it stores information regarding collected (trajectories of) fingerprints, such as their exact sampling location (e.g., if they belong to the radio-map), the users that collected them, and the employed devices
- observation sub-schema: it stores information regarding a series of data that may have been observed by multiple sensors, including Wi-Fi, Bluetooth, GNSS, Cellular and Inertial Measurement Unit signals, that are all linked to a fingerprint
- place sub-schema: it stores informaton regarding the structure of indoor premises, including all and limited to the data that are useful for positioning purposes (such as containment and adjacency relationships between locations), without any pretense (or actual need) of being capable of representing the actual layout of the premises
- data_source sub-schema: it stores informaton regarding data lineage
The current repository includes:
- the code to set up the database within a Postgres database instance: link
- the code to import a new dataset into the database: link
- the code of some queries that show how to use the database: link
- some well-known and widely-used datasets that have already been converted into the format expected by the import procedure: link
The database is highly modular, and can be easily extended to handle specific usage needs.
The system can be accessed at the address http://158.110.145.70:5050/. Upon connection, users will find a pgAdmin web server interface, asking for the login data.
A read-only user, that has the privileges to perform SELECT operations over the public and evaluation_support schemas of the database Open_Fingerprinting has been provided, with the following credentials:
username = [email protected]
password = tSUD22$Indo0r
The database comes already populated with information originating from the datasets listed here. Some user defined functions aimed at easing the interaction have been implemented and can be found here. Examples of queries on the database are reported here.
Here we describe, by means of a series of examples, the notation employed in the above Entity-Relationship diagram. The figure below depicts a strong entity set named Person, that has a primary key composed of the attributes Name and Surname. Each entity of Person may have at most one Email address, and one or more Phone numbers. In addition, it always has a Birthdate, based on which the value for the derived attribute Age is established.
The following figure reports the case of a weak entity set, named Song, that has the attribute Title as its partial identifier. Its identifying relationship is Belongs to, thus, the title of a song is unique within a given album. The entity set Album has Name as its primary key. Each album contains one or more songs, and a song belongs to one and only one album (the constraint 1:1 is assumed by default by our notation, and thus has been omitted on the Song side of the relationship).
The notation for a total and disjoint specialization is showed below. Each entity of entity set Professor is uniquely identified by its SSN, and it corresponds to either a Full or an Associate professor.
Finally, we report the case of a partial specialization. Here, an entity of entity set Employee, uniquely identified by its SSN, can also be an entity of entity set Supervisor. This is quite natural, since supervisors are themselves employees, but not all employees are supervisors.
