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 [2021/08/18 13:44] ezimanyi [Distributed Moving Object Database on MS Azure] |
teaching:projh402 [2021/08/18 14:09] ezimanyi [Map-matching as a Service] |
||
|---|---|---|---|
| Line 23: | Line 23: | ||
| 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. | 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. | 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. | ||
| Line 56: | Line 55: | ||
| Map-matched trajectory | 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 challenges 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. |
| Links: | Links: | ||
| Line 64: | Line 63: | ||
| * [[https://github.com/cyang-kth/fmm|Fast Map Matching]] | * [[https://github.com/cyang-kth/fmm|Fast Map Matching]] | ||
| - | **Status**: taken | + | ===== Symbolic trajectories ===== |
| + | |||
| + | Symbolic trajectories enable to attach semantic information to geometric trajectories {{:teaching:symbolic_trajectories.pdf|}}. Essentially, symbolic trajectories are just time-dependent labels representing, for example, the names of roads traversed obtained by map matching, transportation modes, speed profile, cells of a cellular network, behaviors of animals, cinemas within 2km distance, and so forth. Symbolic trajectories can be combined with geometric trajectories to obtain annotated trajectories. | ||
| + | |||
| + | The goal of this project is to explore how to implement symbolic trajectories in MobilityDB. This implementation will be based on the ttext (temporal text) data type implemented in MobilityDB and will explore how to extend it with regular expressions. This extension can be inspired from the [[https://www.postgresql.org/docs/13/functions-json.html|jsonb]] data type implemented in PostgreSQL. | ||
| + | |||
| + | |||
| ===== Geospatial Trajectory Data Cleaning ===== | ===== Geospatial Trajectory Data Cleaning ===== | ||