Trajectory Data Warehousing

1,805
-1

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,805
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Trajectory Data Warehousing

  1. 1. A Study on Trajectory Data Aggregation Simone Campora February 4th 2009
  2. 2. Introduction  The Purpose: ◦ Building a data warehouse for Rio de Janeiro Traffic Dpt ◦ Prototype a trajectory datawarehouse ◦ Explore DW potentialities  Challenges: ◦ How to integrate GPS data into a TrDW? ◦ Which kind of information could be extracted? ◦ Discover the issues ◦ How the results could be presented?
  3. 3. Rio The Janeiro: a Metropolis Population (2007) Municipality 7,145,472 Density 4,781/km2 Metro 13,782,000 HDI (2000) 0.842 – high Streets 13858  Some Facts:  Number of cars is mostly doubled during the last year!
  4. 4. Problems  Which problems will be considered?  Congestions: is a condition on any network as use increases and is characterized by slower speeds, longer trip times, and increased queuing  Emissions of CO2: How much CO2 is produced by vehicles? Calculated on average production index of 200 gr/Km
  5. 5. Traffic Problem: Congestions
  6. 6. From Velocity to Traffic Density  How to use that information? ◦ We can extract the same information while looking at vehicles’ average speed points/KM (50 km/h) Traffic Density 72 9 96 18 144 35 288 70 -> ∞ 140
  7. 7. Why a TrDW for Rio?  We would like to run queries like ◦ How the traffic congestions are evolving during the week? (Spatial) ◦ Q2: Which are the most polluted streets? (Spatio-Temporal) ◦ Q3: Which streets are the most congested? (Numeric) 1 2 3
  8. 8. How could Trajectories be helpful?  Trajectory is the unit of work for our traffic management application we partially use the trajectory model developed (i.e. Stops-Moves) ◦ Stops have been already calculated and are represented by an attribute for each trajectory ◦ Trajectory segmentation is constrainted by road network segmentation Note
  9. 9. Our Dataset  GPS Signals ◦ Position ◦ Time ◦ Speed  Street Network ◦ Street segmentation ◦ Street names $GPRMC, €,V,2253.7009,S,04321.2711,W,,,,021.8,W,N*1C $GPGGA,,2253.7009,S,04321.2711,W,0,00,00.00,000012.8,M,-005.8,M,,*6E $GPZDA,103037,11,05,2007,+00,00*65 $GPRMC, €,V,2253.7009,S,04321.2711,W,,,,021.8,W,N*1C ... $GPRMC,103501,A,2300.0632,S,04319.8165,W,017.2,100.3,110507,021.8,W,A*0C $GPRMC,103502,A,2300.0642,S,04319.8120,W,015.1,103.3,110507,021.8,W,A*0B $GPRMC,103503,A,2300.0651,S,04319.8082,W,013.1,103.4,110507,021.8,W,A*00 Trajectories
  10. 10. The Star Schema Time Streets Trajectories Fact table entry: A trajectory instance segment
  11. 11. Oracle OLAP SQL interface  How to access MOLAP using SQL?
  12. 12. First Query: Spatial  Which is the correlation between pollution caused by high speed and congestions?
  13. 13. Second Query: Spatio-Temporal  How Congestions are evolving during week?
  14. 14. Third Query: Numeric  Which streets have globally the worst traffic conditions? Traffic Index Street 25,131 For the Overall Rio 39,077 AVN AMARO CAVALCANTE 27,886 ACESSO A PTE PRES COSTA E SILVA 24,032 ACESSO AVN GOVERN CARLOS LACERDA (LINHA AMARELA) 15,651 ACESSO DO VTO DE MANGUINHOS
  15. 15. Remarks using Oracle OLAP  Positives: ◦ Good Expressive Power for Aggregations ◦ Multi-dimensional representation ◦ SQL interface from MOLAP to Relational  Drawbacks ◦ Too many Catalog tables! ◦ No robust bulk loading methods: Fatal Errors! ◦ Slow queries also with simple mapping to Relational ◦ To query a Cube with streets and Time dimension, it is required 3-4 Mins. ◦ Limitations of supported types: ◦ Only TEXT, Number, Date ◦ No Complex Objects
  16. 16. Conclusions  The design process is dangerous! ◦ Lack of Error Handling  SQL interface leads to wider uses e.g. GIS tools  Future work: use OLAP DML to enhance running times
  17. 17. Thanks for the Attention

×