It would be helpful if we could have a table of establishments sorted the date they were added. That way we could keep on top of new places opening.

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".

BoundaryLine districts from old CSV stats are manually mapped but districts from database table stats aren't, even though LA districts have been amalgamated.

Related to #21

Some establishments stay in the dataset after they have closed. It would be nice for them to no longer be shown.

I don't have a programmatic way know if an establishment is closed, however OSM does currently have 4k variations of old_fhrs:id. I've collected them here. Another option would be to allow users of fhodot to flag them.

Hey, the new version is looking good. However I hope some functionality is not lost in the transition.

In the previous version the district page provided a good overview on how a specific area was mapped, and highlighted issues and suggested matches. The new version doesn't highlight issues or show suggested matches until being quite zoomed in, making it harder to match and monitor a large area. In the old tool I felt I could easily monitor/maintain all of the Isle of Wight, but I don't think I could do that with the new tool. I think showing more data at a lower zoom would be one way to help.

Updates are currently daily, but it would be great if the updates we more frequent.

I've just noticed on the FSA Web site that they are changing their API URL, so thought I would post that here just in case it impacts on the project.

South Tyneside seems to have a had a mass update of its FHRS IDs, and so the match rate has gone from overnight from ~30% to 0%, which is very disheartening.

Perhaps this could be managed? It would require comparing looking specifically at "old" and "new" FHRS records and identifying a changed FHRS ID where all the address data remained the same. The "suggested match" layer could then be extended to propose "New FHRS ID?".

@rjw62 comments:

Looking at https://api.ratings.food.gov.uk/Help/Status it seems that over the past year, a number of Authorities have re-issued all their FHRS IDs, meaning the matches we've previously entered in OSM are now all invalid. […]

What might be helpful is if the suggested match view in your tool could have tables below it, split into whether the object has an existing defunct FHRS ID or not. If the table could provide the FHRS/OSM names and postcodes, along with the JOSM RC links that would potentially make the update a lot quicker. Better still if there could be a JOSM link to just update the FHRS ID. Typically the address details are already there if the OSM object already has an FHRS ID, and it would save having to untick those rows in JOSM.

Related to #8.

Is adding source:addr really necessary? It should be on the chnageset anyway.

Data updates are currently failing with RuntimeError: Database has 376 authorities but new data only has 363.

Presumably related to this.

These could be useful for memory jogging without having to click on each map marker in turn. It could be useful to sort by postcode in order to group objects that are geographically close.

The OSM table should include objects with (only?) invalid fhrs:id tags too. Both tables should include links to select / select & zoom as used in existing tables.

The necessary data should already be returned by the endpoints for the FHRS and OSM data sources.

This will allow matching of the considerable number of FHRS establishments with no location.

@SK53 suggests (via this mailing list post:

If one could download geojson for an area in the viewport one could do two
things with Potlatch:

• pull it in as a custom vector layer, allowing individual items to be
  pulled into the editing view along with their tags
• use the same geoson as a task list to step through the items for review.

Both can be populated via URLs, so perhaps providing a geojson end-point
for the viewport would make this easier with Potlatch.

As requested by @EdLoach for the original FHRS/OSM comparison tool.

See gregrs-uk/python-fhrs-osm#50.

There are more than a few establishments still in the FHRS dataset after they have closed eg. Old inspection dates can be an indicator for that, perhaps they shouldn't be shown.

Another option would be to make the inspection date more viable to make mappers aware. Maybe show it in the blue boxes that show the FHRS data.

This is useful for spotting matches that haven't been picked up as suggested matches, and particularly when a large number of FHRS IDs are changed in bulk for a local authority, as has happened in the past.

The table could use the OSM objects within the map area sorted by postcode and should include establishments with matching postcode but no location.

There isn't currently an API endpoint that provides this data.

The infrastructure for Python and JavaScript tests is in place, but there's quite a lot of code not covered by unit tests.

I think the FHRS data may not be getting updated at the moment.

eg:
I'm being encouraged to replace https://ratings.food.gov.uk/business/en-GB/1629260 with https://ratings.food.gov.uk/business/en-GB/1320052 on https://www.openstreetmap.org/node/5107483874

This follows on from discussion in #12. Using R, I've analysed the tags of OSM objects in some regions with > 90% of their FHRS establishments (with locations) matched.

ZIP file of analysis and data

This is also related to gregrs-uk/python-fhrs-osm#66 from old version of tool.

@rjw62 asks whether the last-clicked marker could be highlighted in some way

@rjw62 asks:

Could you consider a new "Unmatched" view, that shows unmatched OSM objects and unmatched FHRS entries (and probably mismatched pairs) at the same time? This would make it easier to spot things to manually pair, rather than having to guess if there's an OSM object for the unmatched FHRS entry.