codeforkansascity / Neighborhood-Dashboard

We're working to help neighborhoods help themselves by giving them easy access to useful data to allow them to identify and track problem areas in their neighborhood.
https://neighborhood-dashboard.codeforkc.org/
MIT License
18 stars 9 forks source link

Update + Rename Problem Tenants Query #139

Closed AmandaWilsonKC closed 5 years ago

AmandaWilsonKC commented 5 years ago

Change name of query on Misc. tab from Problem Tenants to Problem Landlords. This should pull up rental properties (where the physical address does not match the owner address) and there are code violations. Will need to double check that the KCMO open data code violations are being pulled from the correct dataset...

moldybeats commented 5 years ago

A couple notes as I dived into this issue:

  1. To find rental properties, we compare the county_owner_address to the street_address obtained from the Address API. That sounds right, but I'm not sure where this info comes from and if it's current. Quite a few addresses were missing the county_owner_address.

  2. The request to the KCMO Property Violations API uses a old endpoint URL, but even after trying the new-style endpoint with the same neighborhood coordinate data, I wasn't able to get any violations for any neighborhoods I tested, even when including closed violations. I wonder if something has changed with Socrata's within_polygon method?

buzwells commented 5 years ago

It looks like within_polygon works for some KCMO datasets (e.g., crime and 311), but not for property violations. We noticed that the property violations dataset includes the latitude and longitude fields in its schema, but they do not appear to be populated. Datasets where within_polygon works properly appear to have those fields populated. The documentation suggests that these fields drive the determination of whether the location point is within the described polygon. Notably, property violations does include a neighborhood name field. When this is used in place of the polygon keyword/function, the query returns the matching violations in the neighborhood. One possibility is to leverage this field for property violations. But before doing that we can check with Eric Roche to understand better whether these fields used to be populated (and whether there is any other reason the queries used to work but no longer do).

moldybeats commented 5 years ago

In addition to the issues with the KCMO data sets mentioned above, it seems there are a few issues with the Address API we'll need to work through in order to accurately identify rentals by comparing street_address to county_owner_address. The Neighborhood Dashboard uses the address-by-neighborhood endpoint for this.

address_by_neighborhoods_stats-20190204.xlsx

moldybeats commented 5 years ago

I updated the filter label for this as part of issue #132, but there's still some stuff behind the scenes that uses the "problem renter" terminology (eg. the ProblemRenters class, the problem-renters query parameter, etc.). It would be nice to update all those for consistency.

moldybeats commented 5 years ago

I got rid of the "problem renters" terminology behind the scenes, so I think this issue is complete.