Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improves Admin Analytics, Adds Choropleth #692

Merged
merged 68 commits into from
Jun 20, 2017

Conversation

misaugstad
Copy link
Member

@misaugstad misaugstad commented Jun 19, 2017

On admin overview page

  • The coverage table now has "rate" as a column instead of a row

On admin analytics page:

  • neighborhood completion choropleth added
  • DC coverage progress area chart added
  • daily label counts chart updated to include all data, not just past month
  • severity rating histograms for each label type added
  • onboarding completion time histogram updated to be more informative
  • coverage % by neighborhood chart's axes switched so neighborhood names are legible
  • neighborhood coverage % histogram added
  • completed missions histogram removed
  • neighborhood total distance covered chart removed

Other:

  • region_completion table added to database

Resolves #691
Resolves #622
Resolves #676
Resolves #697
Partially Resolves #342

…analytics-graphs

Conflicts:
	public/javascripts/Admin/src/Admin.js
@manaswisaha
Copy link
Member

Meta point: Another rule of thumb for PRs that I am realizing now is that we should aim to keep PRs as small as possible. Just address a single bug or small number of related bugs. Currently, this PR is really huge to review with a lot of changes. Would take quite some time to review the code.

@manaswisaha
Copy link
Member

I'll create a doc on creating PRs after relaunch and add it to the wiki of this repo.

@jonfroehlich
Copy link
Member

At this point, I think you can do a light code review of admin-centric stuff. We can then do a more heavyweight review after relaunch (which I do think is important because we want to make sure not just that the admin interface contains the analytics that we need and is coded well but that the underlying calculations are correct).

@misaugstad
Copy link
Member Author

I agree with @jonfroehlich to keep the code review light. Especially since there are still changes to be made, the code needs to be cleaned up a little bit as well, and there is some time-sensitivity to getting the backend stuff integrated for testing purposes.

I also agree that PRs should be as small as possible. The problem here is that it is meant to address an issue, but the issue is huge; the issue has over 20 charts to be added/modified that are mentioned, so should I be making a dozen PRs that all partially address that one issue..? I don't think that the issue should be split up, as that would be hard to manage, but does it make sense to split up the PRs?

@manaswisaha
Copy link
Member

@misaugstad

Feedback:
I tested the neighborhoodCompletionRate code by doing couple of missions both as an anonymous and a registered user. It updates properly. Other comments:

  • I left a few comments in the PR to address.

  • About the region_completion table,
    - it initializes with audited distance for region ids from 195 - 373. What happened to the ids before that? Are those invalid?
    - The distance captured in the table is in feet?

  • There are print statements left to be removed within Scala code:

image

@manaswisaha
Copy link
Member

Also, didn't comment on the cosmetic changes that are needed (e.g. spacing between graphs, graphs sticking to the window border). I assume those will taken care of in the next round of updates.

@jonfroehlich
Copy link
Member

jonfroehlich commented Jun 20, 2017 via email

@manaswisaha
Copy link
Member

@misaugstad Actually, I was wrong. This doesn't work as expected. I did some more testing. The code within updateAuditTaskCompleteness() --> RegionCompletionTable.updateAuditedDistance(auditTask.streetEdgeId) is called for multiple audits of the same street. I audited the street multiple times to check if the table is being updated again or not, and it does.

if (updatedCount == 1) {
        print("Updated only once " + auditTask.streetEdgeId)
        RegionCompletionTable.updateAuditedDistance(auditTask.streetEdgeId)
      }
    } else if (incomplete.isDefined && incomplete.get.issueDescription == "GSVNotAvailable") {
      // If the user skipped with `GSVNotAvailable`, mark the task as completed and increment the task completion
      AuditTaskTable.updateCompleted(auditTaskId, completed=true)
      val updatedCount: Int = StreetEdgeAssignmentCountTable.incrementCompletion(auditTask.streetEdgeId) // Increment task completion
      // if this was the first completed audit of this street edge, increase total audited distance of that region.
      if (updatedCount == 1) {
        RegionCompletionTable.updateAuditedDistance(auditTask.streetEdgeId)
      }
    }

@misaugstad
Copy link
Member Author

I left a few comments in the PR to address.

Not sure what you mean, is this not the PR?

About the region_completion table, it initializes with audited distance for region ids from 195 - 373. What happened to the ids before that? Are those invalid?

The ones before that have the deleted flag set to true.

The distance captured in the table is in feet?

I am pretty sure they are in meters. Whatever those "geom.transform(26918).length" calls give.

There are print statements left to be removed within Scala code:

I will find and eliminate.

@manaswisaha
Copy link
Member

Not sure what you mean, is this not the PR?

Yes, I meant within the code on github's website. Scroll up or go to Files Changed tab to see those. Looks like this:

image

@jonfroehlich
Copy link
Member

When you guys find code like this that is poorly documented and/or non-sensible:

I am pretty sure they are in meters. Whatever those "geom.transform(26918).length" calls give.

I would strongly prefer that you fix the documentation and/or improve code clarity. We need to know what metrics we are using (see http://articles.latimes.com/1999/oct/01/news/mn-17288).

@misaugstad
Copy link
Member Author

I audited the street multiple times to check if the table is being updated again or not, and it does.

This should be fixed now.

@misaugstad
Copy link
Member Author

Yes, I meant within the code on github's website. Scroll up or go to Files Changed tab to see those. Looks like this:

I scrolled up and clicked on Files changed but I am not seeing any comments

Copy link
Member

@manaswisaha manaswisaha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed

val CRSEpsg26918 = CRS.decode("epsg:26918")
val transform = CRS.findMathTransform(CRSEpsg4326, CRSEpsg26918)

RegionCompletionTable.initializeRegionCompletionTable()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the table initialized each time the function is called?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see if (regionCompletions.length.run == 0) line in RegionCompletionTable. Could you confirm if this prevents it from running from than once?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I had confirmed that this didn't run multiple times using the magic of print statements. You also know that it isn't because the call takes >10 seconds to run, but there are never any 10 second lags when calling the getNeighborhoodCompletionRate after the first call.

@@ -112,7 +112,7 @@ object AuditTaskTable {
def auditCounts: List[AuditCountPerDay] = db.withSession { implicit session =>
val selectAuditCountQuery = Q.queryNA[(String, Int)](
"""SELECT calendar_date::date, COUNT(audit_task_id) FROM (SELECT current_date - (n || ' day')::INTERVAL AS calendar_date
|FROM generate_series(0, 30) n) AS calendar
|FROM generate_series(0, current_date - '11/17/2015') n) AS calendar
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

11/17/2015 - What does this date refer to?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question! I am also wondering that. It appears to be maybe the day after the audit_task_table was first created or something, because up until 11/16/2015 there are no audits at all then on 11/16/2015 there is an absurdly large number of audits, then the data starts looking normal after that.

In summary: 2 days before that date, there are no audits. The day before that date, the data is not reliable. So this is the date where reliable data begins.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Could you add a comment in the code for this?

@@ -467,7 +467,7 @@ object LabelTable {
def selectLabelCountsPerDay: List[LabelCountPerDay] = db.withSession { implicit session =>
val selectAuditCountQuery = Q.queryNA[(String, Int)](
"""SELECT calendar_date::date, COUNT(label_id) FROM (SELECT current_date - (n || ' day')::INTERVAL AS calendar_date
|FROM generate_series(0, 30) n) AS calendar
|FROM generate_series(0, current_date - '11/17/2015') n) AS calendar
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above about the hard coded date

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same response :)

@manaswisaha manaswisaha mentioned this pull request Jun 20, 2017
41 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants