Meeting Notes Thread

[SPTKL]

find all the meeting notes here!, following the template:

## 2020/03/26 meeting notes
1. reasoning for PLUTO (just for HED, can be left out for others): 
     * for completed buildings (and alterations), the square footage is useful.  
     * use this for quality control on PLUTO? and number of units (secondary)
2. confirm final schema for YoY table + main table + CT table
3. confirm stake holder (governing body) for this product
4. enhancements priorities
     * a complete diff file (raw input vs everything that's changed)
     * when HED is doing QAQC research, a lot of issues to research records and update them correctly in the table because they are somehow changed through code. __traceability__ and __priority__. [e.g. units_.sql](https://github.com/NYCPlanning/db-developments/blob/future/developments_build/sql/units_.sql)
5. current release for DevDB

[SPTKL]

2020/03/26 meeting notes

1. reasoning for PLUTO (just for HED, can be left out for others):
   • for completed buildings (and alterations), the square footage is useful.
   • use this for quality control on PLUTO? and number of units (secondary)
2. confirm final schema for YoY table + main table + CT table
3. confirm stake holder (governing body) for this product
4. enhancements priorities
   • a complete diff file (raw input vs everything that's changed)
   • when HED is doing QAQC research, a lot of issues to research records and update them correctly in the table because they are somehow changed through code. traceability and priority. e.g. units_.sql
5. current release for DevDB

I have one (102138820) where the units_net = 13 but the sum of the yearly unit changes is 51. Another (102507253) net=-125 but the sum is +121

[SPTKL]

2020/04/06 meeting notes

• YOY table
  • Main Use Case
    • multiplier (every 5 years, agreement with SCA)
  • Main Issue:
    • the YOY table is out of scope for HED to research
    • it's generated not using cleaned/edited data
    • class A class B distinction is not captured in YOY table
    • as the code is written, it's not getting rigorous review
    • not the best for analysis with completed units in the past
    • large buildings can be getting temporary COs over and over
  • Question:
    • occupancy vs cofo, there might be a gap between the two happens (to which extent the analysis is useful?)
    • students generally appears two years after a building is built
• Potential solutions:
  • Check with SCA/DOE to see how important is YOY table (there's no need to update twice a year, since we only use it for multipliers every 5 years)
  • we can make assumptions about when hotel units come online? assign imprecision precision (like 50% or something)
  • scope: anything mixed use, completion spanning more than a year
  • run a case scenario analysis to see which is the best approach

[SPTKL]

2020/04/10 meeting notes

1. HED will rerun devdb
2. How to actually update DOB job application (weekly), CO too
   • how to set up a pipeline to get DOB data for CO (weekly)
3. a very simple dash board time series (2020), by week, number of permits, number of CO, number of status X dates. Maybe by geography. we really just need DOB applications data. all of 2019 and 2020 (seasonality)
4. stop work order not available in applications data. e.g. construction activities would be missing.
   • essential construction vs non essential construction --> dob is good, stop order isn't important
   • might not be needed

[SPTKL]

2020/04/16 meeting notes -- WOS

• temporal:
  • pre-sandy/post-sandy
• geography of interest:
  • point data (centroid of the tax lots), flood plain
  • for really large lots, might cause issues --> PLUTO has flood plain flags (pfirm)
  • flood insurance is tied to the building not the lot. (might be most convenient to capture the building foot print)
• other:
  • housing variety in flood plain, vulnerable population.
  • versioning is a issue
  • only looking at multi family, single and two family occupancy type
  • construction that are not housing?
  • industry study
  • non residential development **
  • how effective flood regulation is

[SPTKL]

2020/05/27 Kick off for 20Q2 update

• communication channel --> teams
• timing
  • 2 weeks
  • the sooner the better
  • hard deadline --> early mid June
• whenever we change a value in DevDB, it would need to be reported somewhere
  • why?
    • while doing manual research on records, it was unclear how the original data look like -> the end up at open data site to look for original number
    • manual corrections happen last, maybe we just need to create a reference file
    • "we don't care about every single change --> units_.sql", anytime units are changed, how things are interacting with each other
  • solution
    • walk through the logic?
    • field definitions
• QAQC

[github-actions[bot]]

Stale issue message