analysis-#70 updated fairfax vacant analysis

[christopherdavisw]

@lhendey this is the correct pull request.

[christopherdavisw]

@lhendey ready for review

[lhendey]

@cdavisurban - i can't seem to knit vacant-lots-fairfax. comes up with an error on line 293 - "Evaluation error: could not find function "str_ends" cc @sstrochak

[christopherdavisw]

@lhendey So when I knit it seems to work fine. For some reason it seems like your "stringr" package is not installed or is working incorrectly. This is weird as I believe it should be installed and loaded through the tidyverse package. Try typing "install.packages("stringr")" in your console and/or adding "library(stringr)" to the markdown document.

[lhendey]

@cdavisurban - yes, was able to knit after installing stringr. will try to review later today.

[christopherdavisw]

@lhendey I updated per your comments.

[christopherdavisw]

@sstrochak I committed the subset fix. Let me know if you have questions.

[sstrochak]

@lhendey Fairfax results also different from table, and don't make sense- (more singe family attached lots than units?)

[christopherdavisw]

@lhendey @sstrochak I have updated clean fairfax to substitute parcel_area for lotsize_sf when lotsize_sf is more than 1,000,000 ft. higher than parcel_area. There were 8 vacant lots that were clearly too big, and one that was designated as other; all 9 had similar information in their corresponding area variables (e.g. area_tax was less than 500 for all of the problem vars, but for all other parcels area_tax was high/normal). I don't expect the same problem to exist for other vacant lots, and if lotsizes are too big in nonvacant lots, it is likely due to a different cause than this one. I realized the areas from these other files weren't showing up in the vacant file because they weren't kept in (I had replaced NAs and zeros in lotsize_sf with them in the clean file, but didnt keep them for the vacant file), so I just did this change in the clean file.

[sstrochak]

@lhendey Most of the time, area_tax and Black Knight's lotsize_sf are the same (232k out of 300k cases). When they are different (68k obs), 376 cases are an exact match for a unit conversion error (Black Knight has acres mislabeled as square feet). The vast majority of other cases have a very small difference (62k obs had a difference less than 10 square feet). I replaced lotsize_sf with area_tax as long as area_tax is not missing. Does that seem reasonable?

[lhendey]

@sstrochak yes