the point geometry for colp is bbl, but we do a lot of qaqc on address. two data products in one repo
qaqc: the qaqc process is at the end (export_qaqc.sql, we do have description of the tables). but we also have a lot of flags created for this table.
Input data get geocoded twice
ipis_colp_georesults
geocoding + ipis -> so that we can qaqc
Future Enhancement
maybe model after facDB?
currently we have two geocoding script
one for qaqc (addresses)
one for colp (bbl -> translated based on if it's air-rights or not)
we should follow the model of facdb to store both geocoding in the same table
then use sql to pick an choose
easier for qaqc
the only tricky part is that it's not easy to do in python because of air-right lots
it's not source data to geocoding
qaqc for the address is for the input data
qaqc on colp
qaqc on ipis
correcting colp
or correction ipis
we are producing colp, then it opened up an opportunity for a bunch of qaqc table (anything we can do with this data, so it's messy)
GOAL with QAQC #173
qaqc to improve colp
qaqc to improve ipis
qaqc to improve geosupport
‼️ Changes to COLP leads to changes to facdb
Consolidating geocoding
combine two geocoding tables into one, so we only geocode once
Current problem:
Convoluted logic
Future Enhancement
Consolidating geocoding
combine two geocoding tables into one, so we only geocode once
Make string replacement logic more clear
we do use
geo_qaqc
in building colphttps://github.com/NYCPlanning/db-colp/blob/59b6b1e3586ab94e35d4540cd61adc166a2557a1/sql/create_colp.sql
Casting is hard and Unclear
Check recording