The OSM object graph summary distinguishes between matched objects with different / missing postcodes (dark pink) and OSM objects with invalid FHRS IDs (light pink). But, at least to my eyes, the map does not.
Invalid FHRS IDs definitely are a problem that needs fixing, but postcodes sometimes are ambiguous, e.g. in a large shopping centre, there is often inconsistency in different sources on the postcode for a particular outlet. I'm not keen to use not:addr:postcode in this case (which should be for real errors in the FHRS data). These then leaves a lot of "false positives", where the genuine errors / out-of-date items are indistinguishable from non-problems.
Perhaps use red / orange for invalid FHRS ID and postcode mismatch respectively?
A more sophisticated approach for the tables view would be to show the distance between mismatched postcode centroids (or the OSM object and the assigned postcode). This would more clearly highlight real issues from "non problems".
The OSM object graph summary distinguishes between matched objects with different / missing postcodes (dark pink) and OSM objects with invalid FHRS IDs (light pink). But, at least to my eyes, the map does not.
Invalid FHRS IDs definitely are a problem that needs fixing, but postcodes sometimes are ambiguous, e.g. in a large shopping centre, there is often inconsistency in different sources on the postcode for a particular outlet. I'm not keen to use not:addr:postcode in this case (which should be for real errors in the FHRS data). These then leaves a lot of "false positives", where the genuine errors / out-of-date items are indistinguishable from non-problems.
Perhaps use red / orange for invalid FHRS ID and postcode mismatch respectively?
A more sophisticated approach for the tables view would be to show the distance between mismatched postcode centroids (or the OSM object and the assigned postcode). This would more clearly highlight real issues from "non problems".