• Get @nlebovits's original data results
• Compare against our results
• Identify areas we're off and figure out what to do

At some point, we'll want to find a way to attach street view images to every property in the dashboard. This may be best implemented in the front end, rather than in the dataset itself, but I want us to start exploring here. Philadelphia uses Cyclomedia for its street view images, although these appear to be paid. Google Street View images now cost something like 7 cents/image. This isn't urgent, but I'd like us to investigate possible options for sourcing images and come up with a best approach for getting the images onto the rest of the data in the dashboard itself, whether that's while building the dataset or in the browser.

move field trims to each file in data_utils instead of a cleanup method at the end

The current classification of lots by priority level depends only on gun crime and tree canopy cover. I would like to update it so that it is more nuanced. This will required joining PHS LandCare and L&I complaints + violations data to the primary dataset. Once this is done, the attached decision tree can be used as the basis for the updated classifications.

At some point, I'd like to add functionality to the Python script that will allow us to calculate:

1. If a given vacant property is immediately adjacent to any other vacant properties and, if so:
   a) How many such properties it's adjacent to
   b) Whether these properties share the same owner

This will give people insight into how feasible it would be to consolidate properties for things like affordable housing development.

I imagine this could be built out using something like nearest neighbors from geopandas (https://geopandas.org/en/stable/docs/reference/api/geopandas.sjoin_nearest.html), but the more complicated thing would be counting all neighbors that are either contiguous with a given property or contiguous with any properties that are contiguous with it.

Describe the task

Up you @nlebovits what you want to do here. Would be trivial to download the geojson, but understand the pros/cons.

determine if we can use the server to bypass mapbox

Currently, the gun crime layer in this project is based on a fixed bandwidth kernel density estimate. It creates a raster, the values of which are then extracted to the centroids of vacant properties in the primary dataset. Before launching this dashboard, we need to switch to an adaptive bandwidth kernel density estimate. Full justification can be found in this memo from the Philadelphia District Attorney's Office.

However, there is no implementation in Python that I have been able to find. PySal does allow for the creation of adaptive bandwidth weights, but I have not figured out how to use this in our specific case. The best example I can find is implemented in the spatstat package in R and includes references to the paper that explains the methodology. My suggestion would be to use that as the basis for writing a custom function in Python.

Just added some of the images to the 'public' subdirectory. Add them to the about page.

multi-range-slider-react is ugly out the box, we need to put working into making that look nicer and clean up the others

Describe the task

Add and update Favicon

in my haste to get things up I used vanilla js mapbox- refactor using https://visgl.github.io/react-map-gl/

Describe the task

Hook up the search bar with the results. We'll probably have to chat through what we want to search.

add

export const dynamic = "force-dynamic";

to all routes

for example, OPA ID 881088800 is duplicated. There are ~1200 others.

Describe the task

Style the table view per the mockups

Add a column for neighborhoods from here: https://opendataphilly.org/datasets/philadelphia-neighborhoods/

add this into new script: https://github.com/CodeForPhilly/vacant-lots-proj/blob/3119ea9a2d9dda1e118c531a39e232980532c142/data/archived/2023_02_02_vacant_lots_layer.ipynb

We would like to add a button to enable people to identify all the lots where they can take action immediately. This would basically be places where 1) they are high priority and 2) tactical urbanism is feasible (meaning that there would be minimal legal and safety obstacles to intervening immediately). The idea is to make it as easy as possible for people to instantly filter for these properties and find somewhere to help.

Our design team has given us font, colors, and icons for the project. These need to be integrated consistently throughout the app. See below.

Icons:
Clean & Green Icons.zip

Colors:

Fonts:

:root {
  /* TYPE */
  --heading-l-family: "Nunito";
  --heading-l-size: 26px;
  --heading-l-size-rem: 1.625rem;
  --heading-l-weight: 700;
  --heading-l-style: normal;
  --heading-m-family: "Nunito";
  --heading-m-size: 27px;
  --heading-m-size-rem: 1.6875rem;
  --heading-m-weight: 700;
  --heading-m-style: normal;
  --heading-s-family: "Nunito";
  --heading-s-size: 18px;
  --heading-s-size-rem: 1.125rem;
  --heading-s-weight: 700;
  --heading-s-style: normal;
  --body-l-family: "Nunito";
  --body-l-size: 16px;
  --body-l-size-rem: 1rem;
  --body-l-weight: 400;
  --body-l-style: normal;
  --body-m-family: "Nunito";
  --body-m-size: 14px;
  --body-m-size-rem: 0.875rem;
  --body-m-weight: 400;
  --body-m-style: normal;
  --body-s-family: "Nunito";
  --body-s-size: 12px;
  --body-s-size-rem: 0.75rem;
  --body-s-weight: 400;
  --body-s-style: normal;
  --heading-xs-family: "Nunito";
  --heading-xs-size: 16px;
  --heading-xs-size-rem: 1rem;
  --heading-xs-weight: 700;
  --heading-xs-style: normal;
  --heading-xs-line-height: 20px;
  --heading-xs-line-height-rem: 1.25rem;
  --body-xl-family: "Nunito";
  --body-xl-size: 20px;
  --body-xl-size-rem: 1.25rem;
  --body-xl-weight: 400;
  --body-xl-style: normal;
}

When the dataset is finalized, updates to the Mapbox vector tile layer need to be made via API. This can happen no more frequently than once a month, given when the underlying properties dataset updates. For further info, read documentation on the Mapbox vector tiles API, as well as how to update Mapbox layers via API.

Now that we've set up basic contributor docs, it would be good to have folks review them for clarity and accessibility. We should identify:

• things that are confusing
• gaps in information
• typos, broken hyperlinks, etc.

Additionally, it would be good to review the contributor docs for other open source projects to see if there are any ways in which we could improve ours. The Justice 40 project is a good model; their contributor docs are here.

we're calculating it here, but it's not reaching the final product

UX Design catch-up
Translating the mock-up to development web flows.

getting 500s on http://localhost:3000/api/getMeasureBounds?p=all_violations_past_year with {
"error": "column "all_violations_past_year" does not exist"
}

Code needs to be properly formatted before opening a PR. We don't have a way of doing this in Docker yet (we were using python black before).

Add the "park priority areas" data from the ParkServe dataset to each parcel (will be used in identifying park need for recommended actions)

https://www.tpl.org/park-data-downloads

To make the project clearer and more accessible, we should build out our technical documentation.

The open source Justice 40 project provides a good model. It's more complex than ours needs to be (and much bigger), but their docs folder includes good models for what we can do, including files that can be copied pretty much verbatim.

It would be good to have:

• architecture
• datasets overview
• installation
• quick start

Any other docs that seem appropriate can be added, too.

see mockups for buttons needed, and use state/context to apply