revise KPDB aggregations #666
Conversation
damonmcc
force-pushed
the
dm-kpdb-for-gis
branch
2 times, most recently
from
dc7d043
to
3e48303
Compare
damonmcc
force-pushed
the
dm-kpdb-for-gis
branch
3 times, most recently
from
fdf2e7a
to
95355e3
Compare
damonmcc
force-pushed
the
dm-kpdb-for-gis
branch
from
5379a4e
to
5a78c54
Compare
damonmcc
force-pushed
the
dm-kpdb-for-gis
branch
from
5a78c54
to
4ba8727
Compare
| CASE | ||
| WHEN | ||
| has_future_units AND NOT has_project_phasing | ||
| NOT has_project_phasing AND completed_units = 0 |
There was a problem hiding this comment.
just clarifying this is intended as (NOT has_project_phasing) AND completed_units = 0 since that is the way postgres interprets it (vs NOT (has_project_phasing AND completed_units = 0))
There was a problem hiding this comment.
It seems like it just checking. Also - what's the reason to use logic on this unit value rather than its status?
There was a problem hiding this comment.
yes to ur first comment, think it's worth adding the parentheses?
There was a problem hiding this comment.
logic on the phased unit values seems more accurate and easier to understand than using the status values
the status values do determine how units get allocated to the the different phases (within_5_years, from_5_to_10_years, after_10_years). I added the table summary_record_phasing to show record counts by source + status
| @@ -23,7 +23,9 @@ future_units_with_cd AS ( | |||
| units_gross, | |||
There was a problem hiding this comment.
these are real ripe to be built with dbt
There was a problem hiding this comment.
(but that should wait till doing kpdb entirely - much prefer only the intermediate of testing with dbt, building entirely outside of it)
related to #665. this doesn't resolve it because this doesn't add
senior_housing,nycha, andclassbto aggregation outputssee commit messages for all changes
successful build here
screenshots of new columns in aggregation outputs