search

jkall / qgis-midvatten-plugin

Midvatten plugin for QGIS
25 stars 8 forks source link

loggerdata - new db table and import function #57

Open jkall opened 9 years ago

jkall commented 9 years ago

There should be a table for storing any logger data which is not appropriate for storing in tables: w_levels_logger w_flow

Perhaps using a similar design as meteo table? Of course, there needs to be import support for this table. The import function must be very flexible to allow for different importing formats.

On a long term (version 2.0) any logger data should be stored in just one logger data table. No need to use w_levels_logger, w_flow etc

jkall commented 8 years ago

Support for the Nemos-LP is closely related. High priority: https://github.com/jkall/qgis-midvatten-plugin/issues/85

HenrikSpa commented 8 years ago

There is a need for separation manual flow measurements from logger measurements.

Maybe w_flow could be kept for manual measurements and a new w_flow_logger could be made.

Or store flow logger data in "w_logger" together with "logger data which is not appropriate for storing in tables"

The columns: "temp_degc", "cond_mscm", and "level_masl" could be stored as parameters instead in w_logger:

w_logger:

"obsid", "instrumentid", "parameter", "date_time", "reading", "unit", "comment" rb1, Flm01, Accvol, 2016-01-01 00:00:00, 123, m3, '' rb1, '', level, 2016-01-01 00:00:00, 100, cm, '' rb1, '', temperature, 2016-01-01 00:00:00, 7, grC, '' (from w-level logger) rb1, '', conductivity, 2016-01-01 00:00:00, 7, mS/cm, '' (from w-level logger) rb1, '', level_masl, 2016-01-01 00:00:00, 100, m, '' (calculated from the parameter "level" as it is today)

jkall commented 8 years ago

Similarly to what is reported for w_flow vs. "w_flow_logger", the need for a distinction between manual readings and automatic recordings by a data logger is also valid for the w_qual_field table (or else this table will be full of online measurements of pH, DO, el.cond. etc)

It might be that manual measurements and readings never should be mixed with automatic readings/measurements which are preformed and stored by a data logging system.

Then, this particular design decision turns into two questions: which are the tables needed for manual readings/measurements? which are the tables needed for automatic readings/measurements?

Perhaps there should be only one of each?

HenrikSpa commented 8 years ago

This will also affect the zz_-tables. If levels, flow and quality measurements are stored in the same table, maybe only one zz_parameters is needed. Den 23 maj 2016 12:32 skrev "Josef K" notifications@github.com:

Similarly to what is reported for w_flow vs. "w_flow_logger", the need for a distinction between manual readings and automatic recordings by a data logger is also valid for the w_qual_field table (or else this table will be full of online measurements of pH, DO, el.cond. etc)

It might be that manual measurements and readings never should be mixed with automatic readings/measurements which are preformed and stored by a data logging system.

Then, this particular design decision turns into two questions: which are the tables needed for manual readings/measurements? which are the tables needed for automatic readings/measurements?

Perhaps there should be only one of each?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jkall/qgis-midvatten-plugin/issues/57#issuecomment-220944736