Create view from cmap data EI issue#1022
Conversation
| -- Combined municipality name is an array. Empty arrays indicate | ||
| -- unincorporated parcels. Null values indicate missing data. | ||
| CASE | ||
| WHEN CARDINALITY(vpu.combined_municipality_name) = 0 | ||
| THEN 'UNINCORPORATED' | ||
| ELSE ARRAY_JOIN(vpu.combined_municipality_name, ', ') | ||
| END AS municipality, |
There was a problem hiding this comment.
Updated from the EI issue.
| - name: class_description | ||
| description: 'A short description of the class code' |
There was a problem hiding this comment.
We could move this to a shared column description if we feel the need, but the only other place I saw a column like this was in pinval and I'm not sure if that column is exactly the same as what we have here.
There was a problem hiding this comment.
[Thought, non-blocking] Yeah, the HomeVal class description is slightly different. It seems like this column is just coming directly from the ccao.class_dict seed though, so potentially those two columns could share docs? But since we're not currently documenting the columns on ccao.class_dict, I don't feel strongly about it.
jeancochrane
left a comment
There was a problem hiding this comment.
I only took a quick skim of the query since it was already reviewed, but overall it looks good to me! This is a very cool view that aggregates a lot of disparate tables and I bet other folks outside CMAP would be interested it. I assume you and @ccao-jardine have talked about this already, but it would be interesting to think about what this could look like as an open data asset, which would also remove the need for scheduling and completing a yearly export.
Regarding the schema name: We could also consider external, which I think would be slightly more descriptive than export. But ultimately I'm fine with either.
| - name: class_description | ||
| description: 'A short description of the class code' |
There was a problem hiding this comment.
[Thought, non-blocking] Yeah, the HomeVal class description is slightly different. It seems like this column is just coming directly from the ccao.class_dict seed though, so potentially those two columns could share docs? But since we're not currently documenting the columns on ccao.class_dict, I don't feel strongly about it.
| AND procname = 'BORVALUE' | ||
| AND valclass IS NULL -- Class 999 are test pins | ||
| AND class NOT IN ('999') | ||
| AND taxyr IN ('2023', '2024') |
There was a problem hiding this comment.
[Question, non-blocking] What's our plan for updating this in subsequent years? Do we just plan to put up a PR every year incrementing these year values? I could also add it to my draft list of yearly update chores, if we want to institutionalize it.
There was a problem hiding this comment.
oh gosh, i think i should just remove these years. i dont' think there's any reason someone can't just add their own where clause when pulling the data.
| CASE WHEN char_frpl = 1 THEN 'Full' | ||
| WHEN char_frpl = 2 THEN 'Partial' | ||
| WHEN char_frpl = 3 THEN 'None' |
There was a problem hiding this comment.
[Thought, non-blocking] No action now, but it would be really cool if we could centralize this kind of SQL char conersion logic in the same way we do for R/Python code in the ccao package. Something to think about for a future improvement.
Co-authored-by: Jean Cochrane <jeancochrane@users.noreply.github.com>
Co-authored-by: Jean Cochrane <jeancochrane@users.noreply.github.com>
Co-authored-by: Jean Cochrane <jeancochrane@users.noreply.github.com>
Re: potential Open Data Asset, agreed, @jeancochrane, I think this has strong potential! We didn't go for it quite yet because of the nuance of working with this bespoke data model. Rows are distinct to PIN and card (and year), but we provide PIN AVs -- such that if a PIN has two cards, the AV is duped in two rows. Users without CMAP-level knowledge could draw the wrong conclusions by, for example, summing up all AVs of all rows, rather than summing AVs per distinct PIN. But I'm open to being convinced 😎 |
This view should make a yearly export to cmap more manageable. It is essentially the same as the query from this EI issue. I created a new
exportschema for this since it didn't seem to fit well into anything we already have, but I'm happy to move it elsewhere if we're not into it.