GPS-tracking, architecture with many sensors, users

Hello!
I am new to Cesium and have a project on the table where we would like to get some ideas on:

What is the best solution to build a GPS tracking system in 3D with

  • up to 10’000 sensors
  • up to 10’000 simultaneous viewers
  • high frequency updates (for position and viewer - <10 sec)
  • show history or live (slider)
  • dynamic selection of sensors (List of 1-10’000 sensors)

A first idea was to store all the sensor-data in a PostGIS and create a vector tile (how to update?) from there, but may be there’s a better solution for this?

Thanks for feedback,

Toni

Hiya,

Well, there’s really too many ways to slice and dice something like this, but I’d pay attention to any real-time / near-real-time needs. There’s a lot of sensors, and if they are all updated every 10 seconds you have a nightmare on your hands. But a few questions;

  1. Are all sensors on the map at the same time? Are all sensors in view on the map at the same time?

  2. What is the purpose of the requirement to have them update every < 10secs? Technical? Human? Guesswork?

I don’t think database or tech matters, it’s more about technique. I’d stuff them in a db, and the app I would create a map object packaged with all current sensors, and then use WebSockets to add/update/remove sensors / coord as needed. I’d invest some time in change detection on the back-end that only sends WebSockets when they are relevant (ie. when changes large enough to warrant an update happens).

On the Cesium side I’d go with primitives that I’d manage myself (the wrapper API can get a bit slow on large sets of entities), and I’d use a mixture of distance styling and clustering. The rest should be fairly straight forward.

But do tell more! :slight_smile:

Cheers,

Alex

Hi Alex,
Thank you for your ideas.

The sensors are used for sport-events. They should all follow the same course.
I’ve done similar thing (with less sensors) in 2d using traccar with postgres to get the sensor-data into a db and mapguide as the server. I just refreshed the layer every 5 seconds and showed the live-map using a db-view (last position of the device) and FDO-data connection. This worked with 1000 concurrent viewers.

But now it’s time to scale up and have the basemap in 3d… The numbers are the max to not get performance-problems later.

Yes, all the sensors should be on the map at the same time in the same view (live-map).

this is to get an overview of where things are (first, last, missed turns etc.)

Update every few seconds is a human requirement:

  1. Security > immediately take action if somebody is off the course - missed a turn, fallen over the cliff,…
  2. virtual ranking - who is first, second,…last and where are they.

I probably can split the layers into live and history, where
live is just a layer with the last position - so max. 10’000 points in a (clustered?) layer, which gets refreshed every few seconds - not sure if it makes sense to cache this layer on the server or to just generate it for each client request. Also not sure if GeoJson is fast enough for this.
history is all data from this event where it can take some time to load (and generate) and after generation (with timestamp) i have the possibility to use a slider.

The more info and ideas i get upfront, the less i have to dig to find out myself.

Toni

I think its not efficent show 10k point with cesium, I did not try with primitive but with datacollections I think it will not work properly, also cesium has memory leak, show and delete 10k point in 10 second it can be problem after a time I think .

Cool, well the db side is fine, but I do think you sghould invest some time in a websocket hooked to a change detector, and only send updates to your app when an entity is updated. Second, with this many pins you should use the primitive API and controll the scene yourself, as the entity API does a lot of cool things, but where you’ll run into edge cases that’s going to be hard to fix later.

You haven’t said anything about the viewing scenario, though, so maybe flesh that out a bit? Will people see all pins at all times (like a big overview thing), or are the zooming to regions / sections? Will there be filters (like; see only entities with given properties), or is it an everything-all-at-once scenario?

Cheers,

Alex