This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
teaching:projh402 [2020/10/01 11:56] mahmsakr [Map-matching as a Service] |
teaching:projh402 [2020/10/03 18:14] ezimanyi [VODKA Indexes for MobilityDB] |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| ===== Course objective ===== | ===== Course objective ===== | ||
| - | The course PROJ-H-402 is managed by Dr. Mauro Birattari. Please refer to the course description page http://iridia.ulb.ac.be/proj-h-402/index.php/Main_Page for the rules concerning the project. What follows is a list of project proposals supervised by academic members of CoDE. | + | The course PROJ-H-402 is managed by Dr. Mauro Birattari. Please refer to the course description page http://iridia.ulb.ac.be/proj-h-402/index.php/Main_Page for the rules concerning the project. What follows is a list of project proposals supervised by academic members of the WIT laboratory. |
| ===== Projects in Mobility Databases ===== | ===== Projects in Mobility Databases ===== | ||
| Line 20: | Line 20: | ||
| - | ===== Visualization Moving Objects on the Web ===== | + | ===== Visualization of Moving Objects on the Web ===== |
| - | <TBD> | + | There are several open source platforms for publishing spatial data and interactive mapping applications to the web. Two populars ones are [[https://mapserver.org/|MapServer]] and [[http://geoserver.org/|GeoServer]], which are written, respectively, in C and in Java. |
| + | Newer platforms exists, such as [[https://kepler.gl/|kepler.gl]], which were designed for handling large-scale data sets. | ||
| + | However, these platforms are used for static spatial data and are unable to cope with moving objects. The goal of the project is to extend one of these platforms with spatio-temporal data types in order to be able to display animated maps. | ||
| ===== Implementing TSBS on MobilityDB ===== | ===== Implementing TSBS on MobilityDB ===== | ||
| Line 38: | Line 40: | ||
| A distributed database is an architecture in which multiple database instances on different machines are integrate in order to form a single database server. Both the data and the queries are then distributed over these database instances. This architecture is effective in deploying big databases on a cloud platform. | A distributed database is an architecture in which multiple database instances on different machines are integrate in order to form a single database server. Both the data and the queries are then distributed over these database instances. This architecture is effective in deploying big databases on a cloud platform. | ||
| - | MobilityDB is engineered as an extension of PostgreSQL. AWS supports PostgreSQL databases in Amazon RDS for PostgreSQL and in Amazon Aurora. The goal of this project is to integrate MobilityDB with these products. The key outcomes are a comprehensive assessment of which MOD API can/cannot be distributed, and an assessment of the performance gain. These outcomes should serve as a base for a thesis project to achieve effective integration. | + | MobilityDB is engineered as an extension of PostgreSQL. AWS supports PostgreSQL databases in [[https://aws.amazon.com/rds/postgresql/|Amazon RDS]] for PostgreSQL and in [[https://aws.amazon.com/rds/aurora/postgresql-features/|Amazon Aurora]]. The goal of this project is to integrate MobilityDB with these products. The key outcomes are a comprehensive assessment of which MOD API can/cannot be distributed, and an assessment of the performance gain. These outcomes should serve as a base for a thesis project to achieve effective integration. |
| Line 52: | Line 54: | ||
| Links: | Links: | ||
| - | [[https://github.com/bmwcarit/barefoot|Barefoot]] | + | * [[https://github.com/bmwcarit/barefoot|Barefoot]] |
| - | [[https://valhalla.readthedocs.io/en/latest/api/map-matching/api-reference/|Valhalla Map Matching API]] | + | * [[https://valhalla.readthedocs.io/en/latest/api/map-matching/api-reference/|Valhalla Map Matching API]] |
| - | [[https://github.com/graphhopper/map-matching|GraphHopper]] | + | * [[https://github.com/graphhopper/map-matching|GraphHopper]] |
| - | [[https://github.com/cyang-kth/fmm|Fast Map Matching]] | + | * [[https://github.com/cyang-kth/fmm|Fast Map Matching]] |
| ===== Geospatial Trajectory Data Cleaning ===== | ===== Geospatial Trajectory Data Cleaning ===== | ||
| + | Data cleaning is essential preprocessing for analysing the data and extracting meaningful insights. Real data will typically include outliers, inconsistencies, missing data, repeated transactions possibly with different keys, and other kinds of acquisition errors. In geospatial trajectory data, there are even more sources of error, such as GPS inaccuracies. | ||
| + | The goal of this project is to survey the state of the art in geospatial trajectory data cleaning, both model-based and machine learning. The work also includes prototyping and empirically evaluating a selection of these methods in the MobilityDB system, and on different real datasets. These outcomes should serve as a base for a thesis project to enhance geospatial trajectory data cleaning. | ||
| ===== Geospatial Trajectory Similarity Measure ===== | ===== Geospatial Trajectory Similarity Measure ===== | ||
| + | One of the main functions for a wide range of application domains is to measure the similarity between two moving objects' trajectories. This is desirable for similarity-based retrieval, classification, clustering and other querying and mining tasks over moving objects' data. The existing movement similarity measures can be classified into two classes: (1) spatial similarity that focuses on finding trajectories with similar geometric shapes, ignoring the temporal dimension; and (2) spatio-temporal similarity that takes into account both the spatial and the temporal dimensions of movement data. | ||
| + | The goal of this project is to survey and to prototype in MobilityDB the state of art methods in trajectory similarity. Since it is a complex problem, these outcomes should serve as a base for a thesis project to propose effective and efficient trajectory similarity measures. | ||
| ===== Spatiotemporal k-Nearest Neighbour (kNN) Queries ===== | ===== Spatiotemporal k-Nearest Neighbour (kNN) Queries ===== | ||
| + | An example of continuous kNN is when the GPS device of the vehicle initiates a query | ||
| + | to find the three closest gas stations to the vehicle at any time instant during its trip from source to destination. According to the location of the vehicle, the set of three nearest gas stations can change. The result is thus a set of intervals, where very interval is associated with a set of three gas stations. The challenge in this type of query is to find an efficient incremental way of evaluation. | ||
| + | |||
| + | The goal of the project is to survey the state of art in continuous kNN queries, and to prototype selected methods in MobilityDB. Since it is a complex problem, these outcomes should serve as a base for a more elaborate thesis project. | ||
| + | |||
| + | ===== K-D-Tree Indexes for MobilityDB ===== | ||
| + | |||
| + | Indexes are essential in databases for quickly locating data without having to search every row in a table every time a database table is accessed. Thus, an index is an auxiliary data structure that improves the speed of data retrieval operations on a database table at the cost of additional writes and storage space to maintain the index. PostgreSQL provides [[https://habr.com/ru/company/postgrespro/blog/441962/|multiple types of indexes]] for various data types. | ||
| + | |||
| + | In MobilityDB two types of indexes has been implemented, namely, [[https://habr.com/en/company/postgrespro/blog/444742/|GiST]] and [[https://habr.com/ru/company/postgrespro/blog/446624/|SP-GiST]]. More precisely, in PostgreSQL, these types of indexes are frameworks for developing multiple types of indexes. Concerning SP-GiST indexes, in MobilityDB we have developed 4-dimensional quad-trees where the dimensions are X, Y, and possibly Z for the spatial dimension and T for the time dimension. An alternative approach would be to use [[https://en.wikipedia.org/wiki/K-d_tree|K-D Trees]]. K-D trees can be implemented in PostgreSQL using the SP-GiST framework and an example [[https://github.com/postgres/postgres/blob/master/src/backend/access/spgist/spgkdtreeproc.c|implementation]] for simple [[https://www.postgresql.org/docs/current/datatype-geometric.html|geometric types]] exist. The goal of the project is to implement K-D indexes for MobilityDB and perform a benchmark comparison between K-D trees and the existing 4-dimensional quad-trees. | ||
| + | |||
| + | ===== VODKA Indexes for MobilityDB ===== | ||
| + | |||
| + | MobilityDB provides [[https://habr.com/en/company/postgrespro/blog/444742/|GiST]] and [[https://habr.com/ru/company/postgrespro/blog/446624/|SP-GiST]] indexes for temporal types. These indexes are based on bounding boxes, that is, the nodes of the index tree store a bounding box that keeps the mininum and maximum values of each of the dimensions where X, Y, Z (if available) are for the spatial dimension and T for the temporal dimension. The reason for this is that a temporal type (for example, a moving point representing the movement of a vehicle) can have thousands of timestamped points and keeping all these points for each vehicle indexed in a table is very inefficient. By keeping the bounding box only it is possible to quickly filter the rows in a table and then a more detailed analysis can be made for those rows selected by the index. | ||
| + | |||
| + | However, the drawback of keeping a single bounding box for the whole trajectory makes that the index is not very selective as shown in the following figure (extracted from a presentation by Oleg Bartunov from ProstgresPro) | ||
| + | |||
| + | {{:teaching:gist.png?400|}} | ||
| + | |||
| + | The goal of the project is to define [[https://www.pgcon.org/2014/schedule/events/696.en.html|VODKA indexes]] that enable us to store in the index multiple bounding boxes associated to each row in the table as shown in the following figure | ||
| + | |||
| + | {{:teaching:vodka.png?400|}} | ||
| + | |||