search

IEA-Task-43 / digital_wra_data_standard

IEA Task 43: pre-construction energy estimate data standard repository
BSD 3-Clause "New" or "Revised" License
58 stars 16 forks source link

[DataBase] introduce a mapping table between meas_point and logger_meas_config #150

Closed stephenholleran closed 2 years ago

stephenholleran commented 2 years ago

I think we need to introduce a mapping table between meas_point and logger_meas_config tables, similar to the mapping table between meas_point and sensor. This has no impact on the schema or the resulting JSON file.

Reason: A lidar's platform height can change over time (and therefore the device_datum_plane_height_m in the vertical_profiler_properties table) which changes the height in the meas_point table. This then means we have to duplicate the logger_meas_config info and column_name info in the db. To avoid this we could have a mapping table instead?

kersting commented 2 years ago

@stephenholleran agreed. How can I support it?

abohara commented 2 years ago

@stephenholleran @kersting When the lidar data reports a measurement (for e.g. wspd_60m_avg), is this meant to be from the device plane or from the ground ? Would this vary between OEM / model devices ? Could it change with firmware ? In mast the programmed height is mostly for reporting , so if there is a disagreement the meas_point table height could take precedence. In lidar, I do wonder if we need to track it carefully depending on whether the height compensation is happening in the lidar processor. This may inform how we modify the data model.

stephenholleran commented 2 years ago

Hi @abohara,

@stephenholleran @kersting When the lidar data reports a measurement (for e.g. wspd_60m_avg), is this meant to be from the device plane or from the ground ?

It depends on the lidar :(

Would this vary between OEM / model devices ?

Yes

Could it change with firmware ?

Yes. As in the case of the WindCube firmware version 2.1 (something) for the WindCube 2.1 they unfortunately introduced a height offset which then changes the heights reported in the logger file. The unfortunate thing is that they did not add these new reporting measurements but replaced the old ones. So now we are in a situation when the lidar is programmed with a height of 80 m we need to check if this is 80 m above ground level or 80 m above the datum plane. If the installer typed a 1 m height offset with an 80 m measurement height, then the heights reported are 80 m. But say if that 1 m height offset is incorrect and the device is actually installed on the ground, then we are in a situation where all the reporting heights are 80 m but the actual measurement height is 79 m. It would have been a lot easier for us if the previous 'Altitudes' (these are above datum plane) were kept and the 'Altitudes AGL' were added and not replace the 'Altitudes'. This is making life difficult for us but is a separate issue (I need to get around to writing one) than this one. I think this mapping table would help remove duplication in this scenario too depending on where this programmed height offset could go. And just to balance, ZX have a similar issue that we can't even see from the logger file.

In mast the programmed height is mostly for reporting , so if there is a disagreement the meas_point table height could take precedence.

Yes.

In lidar, I do wonder if we need to track it carefully depending on whether the height compensation is happening in the lidar processor. This may inform how we modify the data model.

Yes, as outlined above (hopefully).

abohara commented 2 years ago

@stephenholleran So we should add device-datum as a reference height option since that seems like a distinct possibility and seems a more natural way to resolve this. Essentially, it is a 1m change in the wind speed measurement height (rel. to ground) and should be a separate measurement point per the current WRA architecture. It can all be converted eventually to the ground_height during postprocessing. Does that seem like would be a better fit ?

stephenholleran commented 2 years ago

@stephenholleran So we should add device-datum as a reference height option since that seems like a distinct possibility and seems a more natural way to resolve this. Essentially, it is a 1m change in the wind speed measurement height (rel. to ground) and should be a separate measurement point per the current WRA architecture. It can all be converted eventually to the ground_height during postprocessing. Does that seem like would be a better fit ?

This is a separate issue which I have created here: #177 We can continue that discussion there.

I also don't think your suggestion of adding device_datum to the measurement_point will work as the height offset typed into the lidar can still be incorrect. A 0 m offset might be typed in with the expectation that the lidar will be mounted on the ground but it actually gets installed on a 1 m platform. Having the device_datum still doesn't solve the problem. And also the offset can be changed over time.

stephenholleran commented 2 years ago

Based on this discussion https://github.com/IEA-Task-43/digital_wra_data_standard/discussions/129#discussioncomment-2965898 we have decided to abandon this change.