New Data Model : Add a wildfire table

[RonanMorgan]

The wildfire table is containing the starting_date and ending_date of a fire. The wildfire_id is be saved in the Detection table in order to be able to find all the Detection which have been used to define the table. We consider that the fire has ended after 30min without Detections. Thanks to the camera_id and the azimut we will be able to request easily all the fire detected by a camera.

[frgfm]

Before diving into the review, sorry if that was discussed but I don't see the point of the wildfire table for now. I see two counter arguments:

1. right now we're in a position to confidently notify detection & identify the camera it's from. Those detections can be confirmed or rejected. We can't aggregate detections for now, at least not in any robust way. So if we are to add a wildfire table, I think it shouldn't have a common column with the detection_id
2. And now, if we don't have detections, my bigger question is: considering the quality/reliability of those wildfires, who will be using this data? My feeling is that this will be the final table we'll add to the system once R&D, data science & the product are more mature. But until then, I don't think we can add value in this new table :/

But I have missed a few discussions, so I might be missing something! Happy to hear the motivations :)

[RonanMorgan]

hum why do you say that "We can't aggregate detections for now, at least not in any robust way. " ? @frgfm

On this we agree : the wildfire table would be much more useful if we had a clear vision of the product part. For exemple we could have an interface showing the widfire and we could acknowled it so it would turn the is_wildfire boolean for all Detection of the same object Wildfire at once.

The difference I do between Detection and Wildfire is that Wildfire is more a product Object, used to interact with our User, while Detection should be use by data scientist and ML Engineer but I have clearly a narrow vision of this part so maybe @MateoLostanlen can clarify this

[frgfm]

hum why do you say that "We can't aggregate detections for now, at least not in any robust way. "

The plan is that détections are aggregated into wildfires on two dimensions: spatial and time wise. We don't yet have a good spatial location estimation method, and the model isn't robust enough for time wise (until we imbue it with time perception I think)

Long story short, we can't reliably offer a robust aggregation of détections into wildfire.

On the product part, we need to confirm this but I think wildfires will only be used for post mortem reporting, which isn't a priority in my opinion 🙂

[MateoLostanlen]

If it's not a problem for you, I prefer not to have a wildfriee table at all, as it leaves more flexibility on the platform side

[MateoLostanlen]

We'll need a fetch_detection route that returns the last X detections if nothing is specified.

and we can pass a detection_id or a date to get all detections since this id / date