EBAS reader: Handle time step sizes that differ over the provided time series

[jgriesfeller]

This concerns all types of EBAS readers...

From EMEP report 2022:

Precipitation:
Amberd looks VERY high

Remaining issue: Når jeg ser på Amberd, så er måleperiodene totalt irregulære. Det varierer mellom en halv dag og flere dager 
(feks 10 jan fra 10:20 til 19:10, og 4.3 kl 7 til 9.3 kl 7). Dette klarer ikke Pyaerocom å håndtere (ihvertfall ikke enda), 
så disse dataene må vi kaste ut.

• The first discussion needs to be about how we want pyaerocom to handle this?
• What to do if not all time steps fit?

How it is today (to my best knowledge): Because the colocation can't handle time colocation with start and stop times. it has to assume a certain time step size and do the colocation on the middle points. We do accept small deviations from the time step sizes we have (details are here: https://github.com/metno/pyaerocom/blob/b06cfde9eeb62efc8e4d5dee38afda00a1196632/pyaerocom/tstype.py#L22-L42

But the devil might like in the details of the reader implementations

[lewisblake]

I would say we should ask the modelers how they want the comparison done and then we implement that rather than us coming up with a solution which they might not be satisfied with. If we are to include this data, what should we do with it? If no solution is given, then it is fair to throw out this station.

[jgriesfeller]

@lewisblake agreed. The "probblem" right now is that the station is not ignored automatically. (Yes, I should have mentioned that above) Pyaerocom's focus is to get as much data as possible.

[lewisblake]

To be discussed: https://github.com/metno/AeroToolsIssues/issues/80

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity. This issue will be closed in 14 days if no action is taken.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.