Hi Dave, I think that does not sound too bad. The actual cap/weighting and the number of signals used data, should be calculated using data that is available from the server over various periods of time, and IMO the longer periods do not need to be "real-time," i.e. they could be calculated and stored only once over that time period.
I still think that geographical clusters might serve some useful purpose, but maybe they aren't so important.
For several days the results in the station lists do not appear to be updating for several stations and in many cases near strokes are not registered at all? This could be a software bug.
Although, I seem to have very low "ping" rates and over the last few days Traceroute has shown a lot of hops within the internet network, with very long delays, so this might be part of the problem.
At the height of the storm over southern Spain and Italy, the archives did not seem to produce any graphics, even for strokes that were several hours old, was this data lost?
These things would also matter if you were adjusting the station, just using the raw data.
The, more or less, ten percent of stations on the far right and, especially the ones at the bottom right, of the meteomelin graph (the stations sending 10,000+ signals per hour, for very few strokes.) should have a closer look at how their station is functioning and make the appropriate adjustments and mitigate their sources of interference as much as is possible.
Maybe these stations should be excluded from the server during busy periods automatically.
It is not all noise that triggers interference mode and maybe the criteria for this needs to be reassessed.
These stations could be jamming up the server, when others are actually trying to send real data.
My 2 cents.
Brian.
I still think that geographical clusters might serve some useful purpose, but maybe they aren't so important.
For several days the results in the station lists do not appear to be updating for several stations and in many cases near strokes are not registered at all? This could be a software bug.
Although, I seem to have very low "ping" rates and over the last few days Traceroute has shown a lot of hops within the internet network, with very long delays, so this might be part of the problem.
At the height of the storm over southern Spain and Italy, the archives did not seem to produce any graphics, even for strokes that were several hours old, was this data lost?
These things would also matter if you were adjusting the station, just using the raw data.
The, more or less, ten percent of stations on the far right and, especially the ones at the bottom right, of the meteomelin graph (the stations sending 10,000+ signals per hour, for very few strokes.) should have a closer look at how their station is functioning and make the appropriate adjustments and mitigate their sources of interference as much as is possible.
Maybe these stations should be excluded from the server during busy periods automatically.
It is not all noise that triggers interference mode and maybe the criteria for this needs to be reassessed.
These stations could be jamming up the server, when others are actually trying to send real data.
My 2 cents.
Brian.
Stations: