New gru-qaqc check - PAD BINs and BBLs

[fvankrieken]

Awaiting final confirmation from RZ, but a relatively straightforward ask from GR

The output of this report should show Addresspoints whose underlying BIN and BBL does not match the BIN and/or BBL from Function 1A in Geosupport

My interpretation is that we should have a check were we

• import PAD (which contains address, BIN, BBL among other fields)
• run geosupport on PAD address using function 1A
• create two reports (csvs)
  • all rows where PAD BIN has mismatch with geosupport BIN
  • all rows where PAD BBL has mismatch with geosupport BBL

We recently added a new check, so there are two PRs which show the basic way to do this. For now, it's easiest to add boilerplate code to the db-gru-qaqc repo - that repo needs some attention and refactoring to align with our best practices but that should happen separately. The db-gru-qaqc repo is where logic for actually running these checks lives, and runs very much like our old workflows - action runs, spins up db, runs process in runner in that repo against temporary db, spits out files to s3.

The two PRs for the last new check are

• https://github.com/NYCPlanning/db-gru-qaqc/pull/267 added the new check to the repo. I also pulled out a python utility, you can look at individual commits (primarily commit 1) to see more isolated what happened to add a new check. the action/main bash running script looks for a bash file of a given name, so what ever you name the bash script is the official "name" of the check (which will be used in the second PR)
• https://github.com/NYCPlanning/data-engineering/pull/846 adds the new check (ability to call it, view its status, and download exports) to the qa page. This page is now the only way GR interacts with these checks, so it must be added here. It's just an added entry in apps/qa/src/pages/gru/constants.py, with
  • display name
  • check name MUST MATCH SCRIPT NAME IN GR REPO
  • list of output files MUST MATCH OUTPUTS DEFINED IN GR REPO
  • list of sources - in this case, just dcp_pad

[sf-dcp]

Update

Per discussion with GRU, The request for new report is slightly different:

They would actually like us to compare dcp_addresspoints vs pad for BIN diffs. Therefore, create a report by running dcp_addresspoints through geosupport and filtering geocoded records for BIN diffs. We already have a similar check for address-point rejects, so we will just add an additional output file when running it.