search

gregrs-uk / python-fhrs-osm

Python tools and Leaflet maps for downloading, comparing and visualising Food Hygiene Rating Scheme (FHRS) and OpenStreetMap data
http://gregrs.dev.openstreetmap.org/fhrs/
GNU General Public License v3.0
8 stars 2 forks source link

Include OSM objects with a non-matched FHRS ID as candidates for matching #74

Closed rjw62 closed 3 years ago

rjw62 commented 4 years ago

When a previous FHRS ID disappears, it's normally because the business has ceased trading. But there are also a significant number of instances where the Authority has issued a new FHRS ID to what appears to be the same business. (Perhaps it's an admin error, or the result of a change of ownership, or some other meta-data associated with the application.)

From my personal observations, I would guess that the latter applies to maybe around 50% of the FHRS IDs that disappear. It would be useful to be able to help the process of matching these to the new IDs and updating them in OSM. Currently, I don't think objects with an fhrs:id=* are considered as candidates for a match in the second map.

I'd like to suggest that OSM objects with a non-matched fhrs:id=* are considered as matching candidates for the second map. I don't know if it's possible to do something better with the JOSM links, so it will override the existing FHRS ID value by default, and perhaps not suggest the address tags -- as they'll probably already be there. Perhaps an additional link could be supplied, that just updates the FHRS ID in JOSM?

SK53 commented 4 years ago

Technically the ID should change when the management changes. So a pub which continues trading should change each time the manager changes (or possibly even the chef). I imagine many less scrupulous outfits honour this rule in the breach.

gregrs-uk commented 4 years ago

Thanks @rjw62 for the good suggestion.

Including OSM objects with a non-matched fhrs:id should be possible, but not necessarily a quick fix. The database view of suggested matches currently selects from the OSM and FHRS tables (which have no notion of whether objects are matched) rather than from the compare view, which does. The query would need adapting here.

The link for adding JOSM tags is created here. It should be possible to change the behaviour depending on whether a suggestion includes an OSM object which already has a (mismatched) fhrs:id, but this will be quite fiddly!

I'm afraid I don't have much time to dedicate to this project at the moment but pull requests are welcome. (Sorry there has been a delay with your other one.)

gregrs-uk commented 3 years ago

This is implemented in fhodot, which will soon replace the original FHRS/OSM comparison tool