search

avaldebe / PyPMS

Data acquisition and logging for Air Quality Sensors with UART interface
https://avaldebe.github.io/PyPMS/
MIT License
29 stars 8 forks source link

Consistent attribute names #17

Closed stantond closed 3 years ago

stantond commented 3 years ago

For n attributes, the numbers are consistent, with _ representing the decimal.

For consistently and to make the numbers easier to understand, should the following change?

From To
raw01 raw1
raw25 raw2_5
pm01 pm1
pm25 pm2_5
pm04 pm4
avaldebe commented 3 years ago

The naming came from work, the Open Source EMEP MSC-W model uses PM25 for PM2.5 and I'm so used to it that pm2_5 looks wrong to me.

I already have 1.5 years collected as pm25 so I won't change the fields names, but I could define raw2_5/pm2_5 as properties for all relevant PM sensors. Would this be sufficient?

stantond commented 3 years ago

Makes sense if you're confirming to another standard, does Open Source EMEP MSC-W model also present PM1 as PM01 and PM4 as PM04?

avaldebe commented 3 years ago

Makes sense if you're confirming to another standard, does Open Source EMEP MSC-W model also present PM1 as PM01 and PM4 as PM04?

It only has PM2.5 and PM10 outputs. Some of my colleagues have research versions with more detail but I do not know what they call the extra tracers.

... I could define raw2_5/pm2_5 as properties for all relevant PM sensors. Would this be sufficient?

What do you think about the raw2_5/pm2_5 properties?

stantond commented 3 years ago

I think that's a good idea to give consistent names without making a breaking a change

avaldebe commented 3 years ago

I only pushed raw2_5/pm2_5 properties, when I add them all the coverage goes under 95%... I'll add some tests before pushing the rest