Incorrect completion stats

[NicolasGrosjean]

Hello,

I am working on a project which is 102% mapped whereas a task is not mapped.

[ramyaragupathy]

@NicolasGrosjean - thanks for flagging!

% mapped on project card is computed with a sum of tasks mapped and tasks marked as bad imagery blocks. In this case out of the total 451 tasks 450 is set to mapped status and there seems to be nil bad imagery tasks. So that should make it 99% mapped.

However bad imagery count for the projects is set to 9 in the projects table. Investigated this issue further to understand the task history of the project. There are a total of 9 tasks that was once marked as bad imagery but later reset for mapping status. Outlining the history:

Task #	Marked for bad imagery on ...	Bad imagery count
151	28-Mar	1
106	28-Mar	2
126	28-Mar	3
262	28-Mar	4
323	31-Mar	5
269	04-Apr	6

On 4th April, all the bad imagery tasks have been reset to Ready to Map status by the Project Manager. So by end of 4th Apr, bad imagery must be reset to 0 as part of bad imagery reset (we are handling this reset in our code flow). After this reset 3 more tasks were marked for bad imagery:

Task #	Marked for bad imagery on ...	Bad imagery count
107	05-Apr	1
335	05-Apr	2
447	05-Apr	3

Again there was a reset bad imagery operation executed on 18-Apr. However I am seeing the count still standing at 9. Not sure what might have resulted in improper update.

I plan to look at production snapshots to see what has resulted in this state. @ethan-nelson please let me know if there is a better way to approach this.

[ramyaragupathy]

Just looked at data from snapshots before and after reset. Even after bad imagery reset counter reset has not gone through. This has failed twice - both the bad imagery reset did not update the correct count on DB.

[ethan-nelson]

I'll take a look as well from my side to try and help debug. As an aside, it would be good if we added the raw counts of each of these to the project API endpoint: tasks mapped, validated, marked bad instead of just percentages. I'll add that to a new ticket.

[pantierra]

This is a follow up of several issues that I unite here (and close on their end, please follow the links in case you want to have more context):

in #945, @ethan-nelson commented:

I would say the majority of this behavior is corrected by the UI change suggested in #1123. However, there still seems to be a narrow case when the counters are not modified correctly just as you bring up:

In the event a validated task is later invalidated, one is deducted not just from the validation counter but also the mapped counter. > I believe that means that, irrespective of a task being marked either mapped or bad imagery prior to the original validation, one is deducted from the mapped count. So this line should check whether the most recent action other than validation/invalidation was set to mapped or bad imagery and then subtract one from the respective counter in addition to one from validation since tasks marked as validated add to the validation count whether they are validation of a mapped or of a bad imagery.

Another option would be to remove the bad imagery count altogether and lump it under the mapped count, but I think it is useful to know how many tiles are actually marked bad imagery. We just need to be certain that number remains consistent based on the actions that occur.

in #829 it is reported this project to have 99% of validation and @ethan-nelson comments:

I see validation is stuck at 99%. This could be a corner case of a bad imagery task that was validated, then invalidated. It will require some more DB digging.

[pantierra]

Digging into this a little bit while reviewing #1689. Some comments and thoughts:

It seems like sometimes we think around the data on mapped, validated, invalidated and bad_imagery as counters and sometimes as actual state of these tasks. And I think @JorgeMartinezG is right when calculating the percentages based on states. However I would like to consolidate the two concepts rather than introducing new queries. I would suggest to compute the project's tasks_validated, tasks_mapped and tasks_bad_imagery based on the actual state of the tasks. In addition we have the tasks_history table where changes of states are reported and can be queried if needed.

When it comes to the calculation of values, I propose to substract the bad_imagery from the total_tasks when calculating the percent_mapped and percent_validated, as these are neither mapped nor validated but fall out of the total amount of what needs to be done in this project.

• How much of the mapable tasks are mapped or validated:
  • percent_mapped = ((tasks_mapped + tasks_validated) / (total_tasks - tasks_bad_imagery)) * 100
• How much of the mapable tasks are validated:
  • percent_validated = (tasks_validated / (total_tasks - tasks_bad_imagery)) * 100
• How much of all tasks are marked as not to mapable/bad_imagery:
  • percent_bad_imagery = (tasks_bad_imagery / total_tasks) * 100

[Vaomatua]

Perhaps it is a method of work for project management, but I consider tasks_bad_imagery to be tiles that need to be 1) validated that no further work can be done, or 2) tiles that still need to be mapped due to mappers not checking other image sources.
I do like: percent_bad_imagery = (tasks_bad_imagery / total_tasks) * 100
Also think it is valuable to be able to display the actual numbers of tiles rather than just the percentages.