Fountains with processing errors should display differently on map

[mmmatthew]

1. if you reach the catch{}-Block put the fountain with red on the map and show the error message as name

Originally posted by @ralfhauser in #192 (comment)

[mmmatthew]

I can see this interface as being handy for the developer but not really desirable for the typical end user. In certain cases, the end-user might not care at all that an error occurred (e.g., when retrieving photo metadata). In addition, color coding is already used for potability. If we start also using colors to communicate processing errors things become unclear.

What we need is a way for advanced users/developers to i) be aware of processing errors and ii) see the context of processing errors. I would propose:

1. add an error indicator in the navbar, with the number of processing errors encountered for the current city's dataset. Clicking on the indicator would bring up a list of the problematic fountains including the errors and links to each fountain.

location of indicator

2. add an error indicator in the fountain detail view. For each fountain, we can show an indicator of whether processing was successful or not for the fountain. A tooltip on the indicator gives the readout of the errors.

location of indicator

@ralfhauser what do you think of this counter-proposal?

[mmmatthew]

3. Becoming more explicit about processing and data issues requires a refactoring of statuses and issues. Currently, status (warning, error) and issues can be defined at a property level. However, we would now be interested in defining a status for each issue individually, and issues should be tied to each level of processing. The issues can be associated to a raw property value (e.g. unknown water type) or to a derived property value (e.g. issue with image metadata) or to conflicting property values from OSM and wikidata, for example.

[mmmatthew]

4. It is still not clear how the data for the image gallery should be clearly represented. It is not a derivation of a single property, but of both the "image" and the "wikicommons category". The data for the image gallery will therefore also need its own special representation for viewing. In the short term, any processing errors relating to the gallery data can be listed as suggested in 2.

[ralfhauser]

Re 1 and 2): Very elegant ideas but probably more effort.
The better is the enemy of the good.
I suggest to start with my approach that will need a lot less refactoring and

• hope the number of errors asymtotes to a really low number
• once we are out of beta and water quality ad flow (with monthly refinement) is availble, resume your idea

[mmmatthew]

Yes, the refactoring is more effort but it is not necessary for 1 and 2. Refactoring would be necessary so that the error messages can be properly placed within the property detail dialog, and in order to filter error messages by importance.

In a first stage, I would recommend implementing my proposal 1 by itself as it requires similar effort to your proposal and reaches the same objective, but with higher clarity (no mixing of visual languages) and maintainability (separation of functionalities).

[ralfhauser]

5. if two fountains have the same operator ID this should show here
   (See on filter hits, add identifier #189 (comment))

[mmmatthew]

The data issue indicator and list have been implemented:

What remains is issue detection (e.g. detecting if two fountains have same operator ID), issue documentation at different stages of processing.

The indicator is only displayed on screens wider than 900px.

[ralfhauser]

10. say what the error was
11. make it possible to click the error away again (e.g. in case of image not found despite refresh #212 (comment)) - I trying to open link
    https://beta.water-fountains.org/ch-zh?l=de&i=Q64213962

[mmmatthew]

10. is Wikidata Q-Number-Tester #247, since in this case you were trying to access a fountain that was incorrectly/incompletely documented.

[ralfhauser]

1. is #247, since in this case you were trying to access a fountain that was incorrectly/incompletely documented.

But even without a Q-Tester, the current error message is not "production level"
"Show case" error messages are a lot more user-friendly

[FlipHaesli]

Another one when refreshing https://beta.water-fountains.org/ch-zh?l=de&lat=47.3780992&lng=8.5455864

[mmmatthew]

I followed the link but was not able to reproduce the issue.

[ralfhauser]

not reproducible on my side either, but I guess you should also see stacktraces or alike in the server-side log around 11am ?

[mmmatthew]