Add Waterbody type

[Makram95]

We should introduce an new type, that allows us to display all sensors belonging to a water body.

Optimally it should consist of:

• An id
• A name
• A description
• An array of all the sensor ids that belong to it
• A central coordinate to easily display it in maps
• Average temperature (current, overall)
• Optional: Temperature history like the sensors have (day, week, month, min., avg. max.)

[dbrgn]

Good idea!

@rnestler maybe you have time, now that you're a Rails-ninja?

[rnestler]

We should introduce an new type, that allows us to display all sensors belonging to a water body.

I'd prefer a use-case description for what you want to do 🙂

An array of all the sensor ids that belong to it

I'd store it the other way in the DB (a sensor has a water_body / lake), but we can still return all the sensor_ids with the water_body.

Average temperature (current, overall)

Is this really useful? You could just calculate it in the app. The thing is it has a few edge cases when the measurements are out of date (so one measurement is from a day ago and one from ten minutes ago for example).

Optional: Temperature history like the sensors have (day, week, month, min., avg. max.)

I would also leave this off for the start.

[Makram95]

I'd prefer a use-case description for what you want to do 🙂

This would add the ability to filter sensors by waterbody, for example, I want to go swimming in the lake of Zurich and therefore I'm only interested in the sensors that are placed around it. Or maybe I want to compare the temperature of different sensors at the same lake only. I would create an overview of all waterbodies we have sensors at, for ease of comparison between them, or filtering the sensors.

I'd store it the other way in the DB (a sensor has a water_body / lake), but we can still return all the sensor_ids with the water_body.

Like his we could fetch the data aggregated of the water body together with the IDs of the belonging sensors, to then only request the specific data for these sensors, instead of having fetch all of them and then filter them by the water_body id. But a nice solution would probably be to have both. What do you think?

Is this really useful? You could just calculate it in the app. The thing is it has a few edge cases when the measurements are out of date (so one measurement is from a day ago and one from ten minutes ago for example).

I guess one benefit would be, that we wouldn't have to implement the calculation in all clients, which could lead to inconsistencies. Regarding the aggregation, we could do it similarly to the hourly temperatures. We just sum the values of the sensors that we have measurements for the defined period and divide it by the count. This might lead to jumps though if the average is calculated by few sensors. Maybe we can come up with a better solution.

[dbrgn]

@rnestler we discussed whether we could cover this issue just with key-value tags. However, then you can't put a description and location in the API response, and would need to hardcode the waterbodies/lakes in the apps.

Having first-class waterbodies in the API would probably be better :)

[rnestler]

@Makram95 @dbrgn The Waterbody change is live. For now without

• Average temperature (current, overall)
• Optional: Temperature history like the sensors have (day, week, month, min., avg. max.)