Traffic Data Exchange Format
Opened this issue · 2 comments
How do we exchange traffic data in bulk and/or real-time?
- How do we stream LR data with time/speed info?
- Does the OpenLR binary spec work for this or should we use something more modern/well defined. E.g. web mercator tiles via protocol buffers?
- What produces the stream? How to consumers attach to it and/or define extent of the stream that they care about? Can we build on the success of vector mercator tiles to segment/distribute data?
- How do we store archival time/speed data? Our pilot uses an in-memory OLAP cube store. Fun for getting quick time slices, but probably not scalable. Could we move this to an offline S3-based system? * Are there good object store-centric models for archiving temporal data at planet.pbf scale?
These are thorny questions I don't know enough technically to contribute on, but this might also be worth considering... experience from Cebu re: emerging country contexts is that if these data services/tools are to work in-country context (rather than just for actors working on a country/local colleagues behalf) then the data formats need to be as light and simple as possible to aid timely transfer and aggregation in poor data environments/slow connections.
Having pre-defined, fixed OpenLR "segments" defined would lessen the amount of data to be transferred and would reduce work clients need to do to use traffic/speed data. This would be increased burden to define and maintain the segment definitions but would remove the need to send OpenLR (or like) definitions with each traffic conditions update. I saw with Inrix data that the OpenLR segment definitions were large and could not realisitcally be downloaded with every traffic update. SO the traffic update to the client would be a list of IDs and speeds - the client would look at the dictionary of traffic segments (which would change slowly through time).
A zipped protocol buffer would make the data transfer small and easy to use on both sides.