Closed flacombe closed 2 years ago
frodrigo
commented
2 years ago By the past we have French postbox with the same issue, and fix ability was disabled (but now is regular again). Not sure if the option to disable is still present in the code (but not in docs).
On others, when location come from geocoding, geocoding quality is printed in message when available.
flacombe
commented
2 years ago Good, let's get a sustainable solution for that.
Which one would be the most desirable?
It could be completed with polygon area when available, but this will be added in a further step. Point with accuracy information is ok to begin with.
Message is ok for human reading but barely usable by third parties to adapt options displayed to users.
frodrigo
commented
2 years ago Which one would be the most desirable?
It is only a backend matter. The analysis could report or not a fix. The frontend just display the data. The location of the marker is not the same think as the pin.
I think the ability to report or not a fix was removed from the backend code. But can be easily reintroduced.
Dear all,
Some opendata mergers rely on geocoding or area to find features inside without ability to get their accurate position. See https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_power_plant_FR.py#L38
As I plan to add additional analyzer using the same principle, it may be useful to think about improving UX to inform users that location is approximated. We should disable editor-fix features to prevent creating osm nodes at the approximated location and encourage people to look for the exact location.
As I understand how osmose works, it may require a flag from backend to distinguish exact and approximate location, mightn't you?
Is it relevant to investigate or not?
Best regards