# Design consideration for vehicle trajectory database

Hi all,

I’m very new to the Influx world and quiet impressed what InfluxDB could do. I read come articles like the blog post about the data layout [Data Layout and Schema Design Best Practices for InfluxDB | InfluxData]. Now I’m pretty confused how to approach our problem:

We capture vehicle data from the top view perspective on motorways for example. After some processing we end up with a trajectory of each vehicle at a certain time in each recording. So our data has one global timestamp and vehicles that enter the picture at a certain time, do their way in the picture, and leave the picture after some seconds. For each vehicle we calculate position x/y, velocity x/y, acceleration x/y, line number, vehicle in front/back, length/width etc.

What we are locking for is to calculate the relations between the vehicles and filter specific scenarios like: Trigger = lane change → look 5 s before if a certain distance to the front vehicle was fallen below AND → look 5 s after the lane change another vehicle was present beside the ego vehicle after the lane change. As fahr as I understand Flux this should be possible to build such query in Flux?

The actual question is how should we push the data into InfluxDB? We are interested mostly in relations between two vehicles like relative distance and velocity. So how to set it up:

Solution 1: each car, one measurement
measurement car1: field:pos_x, field:pos_y, field:vel_x, field:vel_y, …
measurement car2: field:pos_x, field:pos_y, field:vel_x, field:vel_y, …

And than filter by cars that are present in the same time frame and calculate the relations with join()

Solution 2: all cars in one single measurement
measurement all:
field:car1_pos_x, field:car1_pos_y, field:car1_vel_x, field:car1_vel_y, … car2_pos_x, field:car2_pos_y, field:car2_vel_x, field:car2_vel_y, … car500…

Solution 2 would lead to a lot of empty fields, when car1 has left the picture but on the other hand all vehicles would stay in one single measurement. We have in a worse case appx. 500 vehicles with lets say 50 fields per vehicle in one measurement which is appx. 20 minutes long. The complete database we want to query is currently 100 h long, but will increase to hopefully some thousand hours one day. So if I sum up: 500 vehicle * 50 fields each = 25.000 cardinality right?
25.000 * 3 recordings per hour * 1000 hours: 75 mio. time series, each sampled with 30 hertz. Is this a problem or the warm up for InfluxDB?

I would really appreciate any design considerations before we start doing this.
Kilian

Hello @turborierer,
I think you should go towards solution 2. 75M points in 1000 hours shouldn’t be a problem. Are you looking towards Cloud or OSS? 25,000 series cardinality isn’t considered large either.

Hi @Anaisdg,

we are looking for a OSS in a docker.