You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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 text was updated successfully, but these errors were encountered: