It’s ADSB + MLAT + other aircraft that didn’t get MLAT’d.
6000 to 7000 “other aircrafts”? This seems not plausible for me, the feeder is close to Cologne airport, not Atlanta, Beijing or Dubai. Other feeders nearby do not see this “other aircrafts”.
This is a Planeplotter feed; it is probably bad upstream data, but there are a few different ways it manifests and stats doesn’t catch them all yet.
(It’s not a new thing, and it doesn’t really break anything other than stats)
edit: if I had to speculate, I’d say this is a planeplotter being fed by a SBS-3; we fix the same problem for direct SBS-3 feeds, but with planeplotter in between it gets harder because the planeplotter data is quite processed compared to the SBS-3 so it masks the problem.
I’m going to roll out a change to planeplotter processing at midnight that deduplicates aircraft reports from each feeder before stats processing. This happened anyway for FA’s main use of the data, this change moves it earlier in the processing chain so that stats picks it up too. That should help with the bad data case above; it will also affect planeplotter report counts (but those numbers are not particularly meaningful anyway).
So thats why my count is also on pp account lower then normal, second change to make fa worse.
And to make those change without telling it to us, thinking something was wrong on my side.
I’m not sure what else you want me to do, beyond posting here as I already did.
edit: does this help? ads-b-flight-tracking-f21/changes-to-planeplotter-feeder-report-counts-from-6-jan-2015-t36575.html
I hope that explanation makes it clear that it’s about making the stats better, not worse. Assuming you want stats to actually be useful, rather than “big numbers good”.
Been here for a while now but never chipped in with an opinion so here goes;
The whole concept of flight TRACKING is surely the deciding factor here so I would have thought that calculations based on reported positions would give the best ranking to acknowledge the contribution of feeders.
I don’t think that the intermittent appearance of Jed Clampett’s crop-spraying activities from Somewheresville in the 53rd State has much in the way of meaningful data other than pumping up an A/C count, not to mention the bewildering amount of metal that is hovering around the average US city which seems to be another amplification for the ‘world dominating’ numbers game being played out at the moment.
International & Domestic commercial flights are the ones I am monitoring & the MLATted ones are only of passing interest but I am happy to share the harvested data with the team so their positions can be identified on the map.
I don’t wish to offend but let’s stop ‘waving them about’ peeps & count the chickens & not the feathers. 
Thank you, great 1st post. You were able to put into words what I could not without sounding offensive.
…blackdot/Tom
The problem with using report counts is that every feeder type/version reports differently; the counts can only be usefully compared to other feeders of exactly the same type and version.
Maybe there is a misunderstanding about what these stats are about. They’re there to give you an idea of the raw data that your site provides, as a courtesy for feeding the data in the first place. The stats are collected very early on, well before any sort of flight tracking or association is done.
The flight tracking parts of FA involve selecting and aggregating data from many sources; any stats based on that data aren’t going to be specific to any one receiver.
I appreciate what you are saying but from my (simplistic) view, if I send you; Time, A/C ID, Lat & Lon, that would count as 1 unit regardless of what produces it. The general opinion expressed on this thread seems to be that of a convoluted aggregation of the data biased to rank by total metal seen, regardless of the data quality for A/C tracking purposes. 
Almost all of the feeders do not work in this way, they do not send one message to FA per position message received which is what I think you are describing.
Rather, they send a summary of the most recently seen aircraft state at intervals.
Different feeder types and versions have different rules about how that interval is chosen. For example, Planeplotter sends everything it has seen recently every N seconds. Piaware sends only when changed data is received, and only if enough time has elapsed since the last report for that aircraft, where “enough time” depends on what the aircraft is doing (altitude etc).
The number of these reports seen doesn’t have much relation to the quality of the data.
(edit: in fact, nothing that we gather in these stats has much relation to the quality of the data. It’s a raw measurement. Quality gets very very tricky to measure, and subjective. Should I penalise all the feeders on the east coast of the US or in western Europe because there are lots of them therefore the marginal benefit to FA of any one receiver is low? That sounds like a bad idea)
Almost all of the feeders do not work in this way, they do not send one message to FA per position message received which is what I think you are describing.
Rather, they send a summary of the most recently seen aircraft state at intervals.
Different feeder types and versions have different rules about how that interval is chosen. For example, Planeplotter sends everything it has seen recently every N seconds. Piaware sends only when changed data is received, and only if enough time has elapsed since the last report for that aircraft, where “enough time” depends on what the aircraft is doing (altitude etc).
The number of these reports seen doesn’t have much relation to the quality of the data.
(edit: in fact, nothing that we gather in these stats has much relation to the quality of the data. It’s a raw measurement. Quality gets very very tricky to measure, and subjective. Should I penalise all the feeders on the east coast of the US or in western Europe because there are lots of them therefore the marginal benefit to FA of any one receiver is low? That sounds like a bad idea)
Sorry, when I said quality I intended it to refer to the value of the data to the accuracy of locating traffic.
Unfortunately your subscript edit referred to ‘penalising’ which rather implied what was suspected, that this is some sort of competition, not what the rapidly falling sites in your rankings wanted to hear. 
Finally, if the data I am sending you is not granular enough, how can you feed back the data shown below?
It’s not a competition. I really wouldn’t care if the ranking page disappeared tomorrow, it would make my life a lot easier and I could get on with useful things rather than explaining why the ranking isn’t a very useful thing to look at anyway. The main thing that you can do with stats is compare your site over time, or compare to nearby similar sites; those are useful things.
But there are lots of people who do seem to treat it as a competition and they would certainly treat it as being “penalised” and I’d have to deal with the complaints.
The value of the data is very hard to work out (for example: one feeder covering Iran is probably worth 100 covering Boston) and it is not going to be a particularly useful thing to show anyway as most of the variables are out of the control of individual feeders.
I don’t understand your question about data granularity.
I agree, the rankings must be a constant source of confusion, if they showed any column with an ascending or descending continuity they would make sense but they don’t & therein lies your problem. I used to use the ranking to assess my rig’s performance against all the others but then you announced that wasn’t fair on some & changed it, the new one doesn’t give me the comparisons I had previously which prompted me to question why such confusion had to be introduced?
The granularity question comes from your advice that the data I send you is not granular enough to make a unit count of the positions I send yet you can tell me by feedback that at a certain time Tail Number G-LCYT was 11 miles away, you would have to extract A/C ID, Time, Lat & Lon in order to feed this back which to me would represent 1 unit on a position count.
Value of data for tracking purposes would refer to a message from an actual A/C giving at least the 4 elements mentioned previously & not some estimated data based on MLAT calculations.
I appreciate all the work you put in here & thanks for the advice you have given, I’m sure that the majority of users would prefer you to support the serious participants here & not feel you have to pander to the inadequacies of the few ‘phallus-wavers’ that insist on seeing this as a competition.
I fully agree with the above. May I suggest the following:
Retain all individual statistics for the above-mentioned purposes but eliminate the overall ranking and sorting. Instead, give options to sort all feeders and sites by:
- user name (alphabetically)
- days since first feed (by user and site)
- days for current streak (by user and site)
For die-hard statistics and ranking fans, provide a daily updated csv file that can be downloaded and interpreted according to individual preferences.
It’s mostly that introducing stats for mlat highlighted several problems with how stats were previously gathered that were mostly masked when non-ADS-B aircraft weren’t being used for much. The changes were not made for the sake of “fairness” (whatever that is!), they were made for the sake of correctness, so that they are actually measuring what they claim to measure. This involved changing what was measured, because it was impossible to correctly measure what they previously claimed to measure.
I agree that the display of the stats, especially the main table, is currently unclear and needs work.
The granularity question comes from your advice that the data I send you is not granular enough to make a unit count of the positions I send yet you can tell me by feedback that at a certain time Tail Number G-LCYT was 11 miles away, you would have to extract A/C ID, Time, Lat & Lon in order to feed this back which to me would represent 1 unit on a position count.
That reflects a report which your feeder sent; the report does indeed tell us, for that aircraft, the time/lat/lon of the latest position that your feeder saw at the time of the report. But reports are not sent for every position message received. The rate at which reports are sent varies between feeder types and versions, so if you were to measure report rate, you’d really be measuring the software versions more than the real position rate received.
For example, a piaware receiver that sees one position every 5 seconds and a piaware receiver (running the same version) that sees one position every 2 seconds will generate approximately the same number of reports for that aircraft, because the minimum interval between piaware reports is 5 seconds. A planeplotter receiver that sees one position every 2 seconds might generate more or less than the equivalent piaware receiver, depending on aircraft altitude and whether it is maneuvering or not, because planeplotter uses a fixed interval and piaware uses a variable interval. I have explained this previously, I think.
my email notification subscription to this thread was suspended - cabalistic things can happen here …
what counts is submitted track. the total track of flights in a given and meaningful (e.g. 5 seconds) measured rhythm.
site 1 submitted minimum 720 positions for a flight of one hour through their reach → then it gets 720 points
site 2 submitted only e.g. 400 positions for a flight of one hour through their reach → then it gets 400 points
=> result: site 1 is better than site 2
for those who are very much into what the aircrafts are doing on the ground (i’m not) - simply count these position-points with factor 1.5
edit: that the ‘new’ way counting ads-b is ‘math for beginners’ everybody can see in us ads-b decrease of 25-30% and european ads-b decrease 50-60%
I agree that the display of the stats, especially the main table, is currently unclear and needs work.
This is a tongue-in-cheek comment but how about adding a “rarity” factor.
If the top 100 ranking sites suddenly switched off, would it make any difference to FA’s coverage?
But those locations in remote areas with few flights are never going to be high in the rankings. Importantly without the few receivers in those locations there would be a black hole in FA’s coverage. Hence are they more important to FA than the top 100?
I think I have 60+sites sharing data for MLAT so no one is going to miss my receiver if it went dark since they would cover my area in my absence.
I don’t know of a suitable “rarity” factor - perhaps divide the number of aircraft/flights by the number of receives also reporting the aircraft/flight? Or another pseudo-scientific approach.
Or better still, just go for the idea from “mgunther”. Then anyone interested can interpret the data as they wished without the public display of “mine’s bigger than yours”
Hello,
just trowing my two cents:
I do not understand the new top ranking default calculation.
Results or background calculation for the table show no rational.
It deserve an explanation, or to be put offline to be fix someday.
come on - what’s hard to understand:
goal: put all us sites in front
approach: (number of aircrafts x birthdate of programmer) + (square-root(3.1415926 + log(number of letters from programmers daily horoscope)))
result: et voila