Come on, when your consumer-market station shows 1234 also 1250 or 1200 can be right for solar radiation (if you are lucky). I can't believe that you really want to discuss rounding vs truncating with me given that error range.
I do not question the fact that a station may deliver more digits than can be considered significant for their sensor's abilities. In my particular case I am actually trying to use MB functions to build a record of the values reported by my station, exactly so I can study sensor stability, quality of data etc. In other words, I would like to record values, as received from the station, not truncated, or manipulated.
Are you saying that because I have a "consumer station" MeteoBridge's approach is justifiable? Are you having different code for those of us who have "pro" stations? I doubt it, but if you do I would highly question it.
Based on your reasoning you might also consider adding a random number ±50 in that range to our station's numbers, or deciding to only deliver multiples of 100. Seems you think that all would not matter. The only thing I am discussing is MeteoBridge not making decisions for us, rounding wise. If our stations are reporting certain values, we should be allowed to be responsible for how we treat them and how want to deal with them.
Now, if memory constraints then dictate that for the various modifiers over 60 minutes etc. you can only store integer values, so be it and nobody can create memory that does not exist, but basic science dictates that you should round, unless you want to introduce further bias in the numbers.
