Neighborhoods

This note describes how the Food Oasis project processes geospatial data representing Los Angeles City Neighborhood Councils. The intent is twofold:

• to document for Food Oasis management, architects and developers how the current features are implemented and why we chose a particular implementation, and
• as documentation of "lessons learned" on the Food Oasis project that might be useful to people on other projects to streamline their path to implementing similar features.

Food Oasis currently has a few features related to Neighborhood Councils. The city of Los Angeles is divided into about 100 Neighborhood Councils for purposes of connecting Los Angeles' diverse communities to City Hall. Each council has it's own board of directors and many have a dedicated web site for the area they cover. The Food Oasis application has a few features related to Neighborhood Councils:

1. When the address of an organization (Food Pantry or Meal Program) is entered into the application, the address is geolocated to determine the (latitude, longitude) of the organization, so it may be displayed on a map. When this listing is saved to the database, some code runs that determines if the coordinates fall in one of the neighborhood regions. If so, the listing is associated with that neighborhood in the database. The code essentially runs a query that finds which, if any, neighborhood area contains the (latitude, longitude).
2. The Administration Dashboard then allows an administrator to query listings by neighborhood. The idea is that we could recruit neighborhood representatives as data verification volunteers to work on updating or maintaining the listings in their own neighborhood.
3. The Food Oasis application's organizations page can be embedded as a widget on another organization's web site using an iframe. In the hopes that we might get neighborhood councils to embed Food Oasis on their council web sites, we implemented a feature that allows adding a query string parameter (e.g., la.foodoasis.net/organizations?neighborhood_id=78), which causes the corresponding neighborhood's boundary to be shown as a map layer, and, by default centers the map in the widget on the centroid of the neighborhood region.

To implement these features, we did the following:

• Created a neighborhood table in the Postgres database, with one row per neighborhood and a column that represents the shape of the boundary. The boundary information is stored in a PostGIS proprietary geometry format, which allows us to conveniently perform several calculations and transformations efficiently with PostGIS functions. (Initially, the boundary column was in the OGC WKT (Well Known Text) format, but we found that the PostGIS geometry data type gave us better functionality.)
• Populated the table by exporting the neighborhood data from the Mayor's Office Data Portal: https://data.lacity.org/City-Infrastructure-Service-Requests/Neighborhood-Councils-Certified-/fu65-dz2f. I don't know what kind of scripts, etc. were used to convert the data into the SQL database migration script that was used to populate our neighborhood table, but the initial migration loaded the table with WKT format boundary information as mentioned above. An easier approach would have been to export to the GeoJSON format and use an upload script that uses the PostGIS function ST_GeomFromGeoJSON.
• Implemented code that find the neighborhood for a given (lat,lon). (May not be hooked up now).
• Coded the ResultsContainer React component to read the neighborhood_id query string parameter, query for the neighborhood info, and store the neighborhood object in the appReducer as part of application state. Modify the Map component to look for the neighborhood info in the reducer. If found, render an extra layer on the map with the neighborhood boundary, and overwrite the defaultCoordinates for the tenant with the coordinates of the neighborhood region centroid. This causes the map to implicitly be initialized as centered on the neighborhood centroid.