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/03 18:20] ezimanyi [VODKA Indexes for MobilityDB] |
teaching:projh402 [2021/08/18 13:44] ezimanyi [Distributed Moving Object Database on MS Azure] |
||
|---|---|---|---|
| Line 26: | Line 26: | ||
| 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. | 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. | ||
| + | |||
| + | {{:teaching:trips2.gif?direct|}} | ||
| + | |||
| + | Animated visualization of car trajectories | ||
| ===== Implementing TSBS on MobilityDB ===== | ===== Implementing TSBS on MobilityDB ===== | ||
| Line 35: | Line 39: | ||
| The project consists in implementing a multidimensional generalization of the time_bucket function that allows the user to partition the spatial and/or temporal domain of a table in units (or tiles) that can be used for aggregating data. Then, the project consists of performing a benchmark comparison of TimescaleDB and MobilityDB. | The project consists in implementing a multidimensional generalization of the time_bucket function that allows the user to partition the spatial and/or temporal domain of a table in units (or tiles) that can be used for aggregating data. Then, the project consists of performing a benchmark comparison of TimescaleDB and MobilityDB. | ||
| + | **Status**: taken | ||
| - | ===== Distributed Moving Object Database on Amazon AWS ===== | ||
| - | 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 [[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. | ||
| - | |||
| - | ===== Distributed Moving Object Database on MS Azure ===== | ||
| - | 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. MS Azure supports distributed PostgreSQL databases using [[https://www.citusdata.com/|Citus]]. We have made successful tests for integrating MobilityDB and Citus on a local cluster. The goal of this project is to repeat this work on MS Azureintegrate 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. | ||
| ===== Map-matching as a Service ===== | ===== Map-matching as a Service ===== | ||
| GPS location tracks typically contain errors, as the GPS points will normally be some meters away from the true position. If we know that the movement happened on a street network, e.g., a bus or a car, then we can correct this back by putting the points on the street. Luckily there are Algorithms for this, called Map-Matching. There are also a handful of open source systems that do map matching. It remains however difficult to end users to use them, because they involve non-trivial installation and configuration effort. Preparing the base map, which will be used in the matching is also an issue to users. | GPS location tracks typically contain errors, as the GPS points will normally be some meters away from the true position. If we know that the movement happened on a street network, e.g., a bus or a car, then we can correct this back by putting the points on the street. Luckily there are Algorithms for this, called Map-Matching. There are also a handful of open source systems that do map matching. It remains however difficult to end users to use them, because they involve non-trivial installation and configuration effort. Preparing the base map, which will be used in the matching is also an issue to users. | ||
| + | |||
| + | {{:teaching:original.png?direct&400|}} | ||
| + | |||
| + | Original trajectory | ||
| + | |||
| + | {{:teaching:mapmatched.png?direct&400|}} | ||
| + | |||
| + | Map-matched trajectory | ||
| The goal of this project is to build an architecture for a Map-Matching service. The challanges are that the GPS data arrives in different formats, and that Map-Matching is a time consuming Algorithm. This architecture should thus allow different input formats, and should be able to automatically scale according to the request rate. Another key outcome of this project is to compare the existing Map-Matching implementations, and to discuss their suitability in real world problems. | The goal of this project is to build an architecture for a Map-Matching service. The challanges are that the GPS data arrives in different formats, and that Map-Matching is a time consuming Algorithm. This architecture should thus allow different input formats, and should be able to automatically scale according to the request rate. Another key outcome of this project is to compare the existing Map-Matching implementations, and to discuss their suitability in real world problems. | ||
| Line 59: | Line 64: | ||
| * [[https://github.com/cyang-kth/fmm|Fast Map Matching]] | * [[https://github.com/cyang-kth/fmm|Fast Map Matching]] | ||
| + | **Status**: taken | ||
| ===== Geospatial Trajectory Data Cleaning ===== | ===== Geospatial Trajectory Data Cleaning ===== | ||