Repository navigation
Create pdf report of on demand ratio analyses - #21
Conversation
|
@wrridgeway Take a quick look at the output and see if anything stands out. After that we can do a code review. |
|
In the quick edit round, I also added a table for descriptive stats, which makes the initial text kind of obsolete. Just left in both for now. |
ccao-jardine
left a comment
There was a problem hiding this comment.
Great work so far, @Damonamajor! Some comments here for your next iteration.
Co-authored-by: Nicole Jardine <138712135+ccao-jardine@users.noreply.github.com>
Co-authored-by: Nicole Jardine <138712135+ccao-jardine@users.noreply.github.com>
|
Oh, one more request @Damonamajor: in the intro paragraph, can we list the modeling groups (Single-Family, Multi-Family, Condo?) and/or the class codes that the ratio analysis entails? |
They come from the res model. Is that considered single and multi family? |
|
New file is in the sale shared drive. Didn't make changes on the last question since I didn't know how it should be stated. |
ccao-jardine
left a comment
There was a problem hiding this comment.
Thanks for continuing your work on this!
Co-authored-by: Nicole Jardine <138712135+ccao-jardine@users.noreply.github.com>
…thub.com:ccao-data/recurring-data-requests into 19-create-pdf-report-of-on-demand-ratio-analyses
|
New file is uploaded |
| # Extracts low and high bounds from each assessr *_met function body | ||
| met_bounds <- function(fn) { | ||
| b <- body(fn) | ||
| c(low = eval(b[[2]][[3]]), high = eval(b[[3]][[3]])) |
There was a problem hiding this comment.
There's not a great way to take the bounds from the function (as far as I can think of). Billy may have thoughts on it.
There was a problem hiding this comment.
Oh, I actually liked in your previous versions that you hard-coded the IAAO Standard goal ranges, instead of creating another function that references something confusing -- I think it made it much easier to understand what was going on. (Sorry if I wasn't clear! I just wanted to use assessr's prd_met function to determine the TRUE/FALSE boolean of whether the PRD standard was met, which you did implement.)
I'll leave this comment for Billy's review and let him be the great decider on the cleanest way to do this!
There was a problem hiding this comment.
yeah, i think just hard-coding them is preferable. i do appreciate the effort to use assessr and make sure the values align with what we've formalized, though.
ccao-jardine
left a comment
There was a problem hiding this comment.
Good work taking a stab at a chunky project! I'm ready to hand over the reins but left a couple comments.
@wrridgeway, tagging you in for review! This is a pretty big boi. I'll let you decide whether you want to review this for correctness only and merging and then doing a PR of your own for Damon's review, or a different way to do this.
Thanks, this is looking solid!
| # Extracts low and high bounds from each assessr *_met function body | ||
| met_bounds <- function(fn) { | ||
| b <- body(fn) | ||
| c(low = eval(b[[2]][[3]]), high = eval(b[[3]][[3]])) |
There was a problem hiding this comment.
Oh, I actually liked in your previous versions that you hard-coded the IAAO Standard goal ranges, instead of creating another function that references something confusing -- I think it made it much easier to understand what was going on. (Sorry if I wasn't clear! I just wanted to use assessr's prd_met function to determine the TRUE/FALSE boolean of whether the PRD standard was met, which you did implement.)
I'll leave this comment for Billy's review and let him be the great decider on the cleanest way to do this!
|
While I'm reviewing this, could we add a readme like we have in the other recurring data request folders? |
|
For Billy's reference
would be something like this |
There was a problem hiding this comment.
The values from the Bremen report all seem to align with the values from the old report so looks good! I've got some suggestions below, but nothing major. Obviously this is a ton of work and we haven't done much PDF output in the past, so awesome job on that. I leave graph presentation to you two, but I will say, this graph is a little chaotic and hard to read if you don't already know what you're looking for:
Thoughts:
- The line labels for figure 5 worked better in the HTML and we might need to try using something like ggrepel to help us out here.
- We should start using
gt()rather thankable() - All tables and graphs are labeled as "Figure" in the output, not sure how easy (or possible) it is to get the tables to actually be labeled as tables using cross-referencing.
There was a problem hiding this comment.
Could we get some commenting in this file?
There was a problem hiding this comment.
Yup, do you also have preferences on what we name the files and where they are stored? We talked briefly about it, but I don't know what conclusion was reached.
There was a problem hiding this comment.
[Question, non-blocking] Hijacking this thread to discuss file naming and folder structure:
File names look fine to me! The directory name ratio-analysis/ also seems reasonable, but I wonder if it would make more sense to nest this directory under provisional-ratio-curves/ (i.e. provisional-ratio-curves/ratio-analysis/) since it seems like the two projects are related? I don't have full context into this work, so admittedly I may be misinterpreting the relationship between the two projects; if you feel strongly about keeping them separate, that's fine by me too.
| # Extracts low and high bounds from each assessr *_met function body | ||
| met_bounds <- function(fn) { | ||
| b <- body(fn) | ||
| c(low = eval(b[[2]][[3]]), high = eval(b[[3]][[3]])) |
There was a problem hiding this comment.
yeah, i think just hard-coding them is preferable. i do appreciate the effort to use assessr and make sure the values align with what we've formalized, though.
| #| Fair Market Values by Group.\newline Model and desk review fair | ||
| #| market values for properties with qualifying arm's-length sales | ||
| #| (Sold), properties without a recorded sale (Unsold), and all | ||
| #| residential parcels (All). Sold and Unsold do not sum to All | ||
| #| because properties removed by desk review as outliers are counted | ||
| #| in All but neither in Sold nor Unsold. |
There was a problem hiding this comment.
Perhaps we could add an "Excluded" group as well so the counts add up?
There was a problem hiding this comment.
Just commenting for posterity! We did make this change to add an "Excluded" group, but it produced a confusing summary. Because Excluded PINs are no longer represented in the FMV data, they were showing up as having null FMVs, 0 changes, and 0% change in Figures 3 and 4. This is an issue because it's very likely that these PINs did have FMV changes -- it's just that these changes are hidden, because the row for the PIN's FMV is excluded from the analysis.
For this PR, we're resolving this either by not having the "Excluded" PINs in the summary tables for Figs 3 and 4, or by replacing the null, 0 change, and 0% change results with a string that says "excluded".
Edited to add: I'll let @Damonamajor decide how to proceed, as either of the above options may require some text replacement too. Then feel free to resolve this convo!
Co-authored-by: William Ridgeway <10358980+wrridgeway@users.noreply.github.com>
Co-authored-by: William Ridgeway <10358980+wrridgeway@users.noreply.github.com>
Co-authored-by: William Ridgeway <10358980+wrridgeway@users.noreply.github.com>
|
https://r-graph-gallery.com/lollipop-plot.html there are some cool graphs in here you guys could steal elements from. in particular i think this one has a good idea for labeling the points on figure 2. |
Co-authored-by: William Ridgeway <10358980+wrridgeway@users.noreply.github.com>
jeancochrane
left a comment
There was a problem hiding this comment.
Just popping in to leave some feedback on folder structure and import duplication, I didn't take a serious look at the code since Billy has done that already! Wherever we decide to store the new ratio-analysis/ directory, I would also request that we create a README in the root of that directory with a brief summary describing what this project is for and how to run it.
There was a problem hiding this comment.
[Question, non-blocking] Hijacking this thread to discuss file naming and folder structure:
File names look fine to me! The directory name ratio-analysis/ also seems reasonable, but I wonder if it would make more sense to nest this directory under provisional-ratio-curves/ (i.e. provisional-ratio-curves/ratio-analysis/) since it seems like the two projects are related? I don't have full context into this work, so admittedly I may be misinterpreting the relationship between the two projects; if you feel strongly about keeping them separate, that's fine by me too.
|
Just noting that we don't want two ratio_reports in the same folder. We will ask res-val if they want this and then decide how we want to merge it in. |
|
Adding one comment that there are unresolved issues working between trellix and local windows environments. |
Draft can be found here:
O:\CCAODATA\tmp\ratio-analysis.pdf