Floating Car Data Collection for Processing and Benchmarking

The dataset is outcome of a paper "Floating Car Data Map-matching Utilizing the Dijkstra Algorithm" accepted for 3rd International Conference on Data Management, Analytics &amp; Innovation held in Kuala Lumpur, Malaysia in 2019. The floating car data (FCD representing movement of cars with their position in time) is produced by the traffic simulator software (further referred to as Simulator) published in [1] and can be used as an input for data processing and benchmarking. The dataset contains FCD of various quality levels based on the routing graph of the Czech Republic derived from Open Street Map openstreetmap.org.<br> <br> Should the dataset be exploited in scientific or other way, any acknowledgement or references to our paper [1] and dataset are welcomed and highly appreciated. <strong>Archive contents</strong> The archive contains following folders. <strong>city_oneway</strong> and <strong>city_roadtrip </strong>- FCD from the city of Brno, Czech Republic where FCD is based on Origin-Destination in case of oneway and Origin-Destination-Origin in case of a road trip <strong>intercity_oneway </strong>and <strong>intercity_roadtrip </strong>- FCD from cities of Brno, Ostrava, Olomouc and Zlin, all Czech Republic where FCD is based on Origin-Destination in case of oneway and Origin-Destination-Origin in case of a road trip <strong>Content explanation</strong> All four of mentioned folders contain raw FCD as they come from our Simulator, post-processed FCD enriching Simulator FCD, and obfuscated raw FCD (of both low and high obfuscation level). In the both obfuscated data sets, each measured point was moved in a random direction a number of meters given by drawing a number from a Gaussian distribution. We utilized two Gaussian distributions, one for the roads outside the city (N(0,10) for the lower and N(0,20) for the higher obfuscation level) and one for the roads inside the city (N(0,15) and N(0,30) respectively). Then some predefined number of randomly chosen points were removed (3% in our case). This approach should roughly represent real conditions encountered by FCD data as described by El Abbous and Samanta [2]. In case of post-processed road trip data, there is one extra dataset with "cache" suffix representing the very same dataset limited to a 5-minute session memoization. This folder also contains a picture of processed FCD represented on a map. <strong>Data format</strong><br> Standard UTF-8 encoded CSV files, separated by a semicolon with the following columns: <strong>RAW</strong> <em>Header</em> session_id;timestamp;lat;lon;speed;bearing;segment_id <em>Data</em> session_id: (Type: unsigned INT) - session (car) identifier<br> timestamp: (Type: datetime) - timestamp in UTC<br> lat: (Type: unsigned long) - latitude as used in Google maps<br> lon: (Type: unsigned long) - longitude as used in Google maps<br> speed: (Type: unsigned INT) - actual speed in kmh<br> bearing: (Type: unsigned INT) - actual bearing in angles 0-360<br> segment_id: (Type: unsigned long) - unique edge identifier <strong>POST-PROCESSED</strong> <em>Header</em> <br> gid;car_id;point_time;lat;lon;segment_id;speed_kmh;speed_avg_kmh;distance_delta_m;distance_total_m;speedup_ratio;duration;segment_changed;duration_segment;moved;duration_move;good;duration_good;bearing;interpolated <em>Data</em> gid: (Type: unsigned long) - global identifier of a record<br> car_id: (Type: unsigned INT) - session (car) identifier<br> point_time: (Type: datetime) - timestamp with timezone<br> lat: (Type: unsigned long) - latitude as used in Google maps<br> lon: (Type: unsigned long) - longitude as used in Google maps<br> segment_id: (Type: unsigned long) - unique edge identifier<br> speed: (Type: unsigned INT) - actual speed in kmh<br> speed_avg_kmh: (Type: unsigned long) - actual average speed of a car in kmh<br> distance_delta_m: (Type: unsigned long) - actual distance delta in metres<br> distance_total_m: (Type: unsigned long) - actual total distance of a car in metres<br> speedup_ratio: (Type: unsigned long) - actual speed-up ratio of a car<br> duration: (Type: time) - actual duration of a car<br> segment_changed: (Type: boolean) - signals if actual segment of a car differs from the previous one<br> duration_segment: (Type: time) - actual duration on a segment of a car<br> moved: (Type: boolean) - signals if actual position of a car differs from the previous one<br> duration_move:(Type: time) - actual duration of a car since moving<br> good: signals if actual record values satisfies all data constraints (all true as derived from Simulator)<br> duration_good: actual duration of a car since when all constraints conditions satisfied<br> bearing: (Type: unsigned INT) - actual bearing in angles 0-360<br> interpolated: (Type: boolean) - signals if actual segment identifier is calculated (all false as derived from Simulator) <strong>References</strong><br> <br> [1] <em>V. Ptošek, J. Ševčík, J. Martinovič, K. Slaninová, L. Rapant, and R. Cmar, </em><em>Real-time</em><em> traffic simulator for self-adaptive navigation system validation, Proceedings of EMSS-HMS: Modeling &amp; </em><em>Simulation</em><em> in Logistics, Traffic &amp; Transportation, 2018.</em> [2] <em>A. El </em><em>Abbous</em><em> and N. Samanta. A </em><em>modeling</em><em> of GPS error </em><em>distri-butions</em><em>, In proceedings of 2017 European Navigation Conference (ENC), 2017.</em>