Skip to content

Pedestrian Environment Index (PEI) Documentation

Demo

This project implements the Pedestrian Environment Index (PEI) methodology as developed at the University of Illinois Chicago (see the research paper: https://www.sciencedirect.com/science/article/pii/S0966692314001343). The PEI provides a composite measure of the walkability of an environment, incorporating the following subindices:

  • Population Density Index (PDI)
  • Commercial Density Index (CDI)
  • Intersection Density Index (IDI)
  • Land-use Diversity Index (LDI)

1. Motivation and Introduction

The Pedestrian Environment Index (PEI) is a composite measure of walkability that combines four key subindices to evaluate pedestrian-friendly environments. This implementation of the PEI is useful for researchers aiming to:

  • Assess the current walkability of neighborhoods or regions.
  • Compare walkability across different areas.
  • Identify areas with potential for improvement.

2. Getting Started

Prerequisites

  1. Python 3.x:
    Ensure Python is installed and available in your system path. Check using:

    python --version
    

  2. Required Libraries:
    Install the following Python libraries:

  3. osmnx
  4. pandas
  5. numpy
  6. matplotlib.pyplot
  7. csv
  8. census

  9. Census API Key:
    Obtain a Census API key from Census API Key Signup.
    Save the key in a text file named census_api_key.txt in the same directory as PDI_generator.ipynb.

Installation

Install the required libraries using pip:

pip install osmnx pandas numpy matplotlib csv census


3. Core Subindices

Population Density Index (PDI)

  • Definition: Measures residential population density within defined areas.
  • Data Source: Population and area data are downloaded from the Missouri Census Data Center.
  • Calculation:

    \(\text{Population Density} = \frac{\text{Total Population}}{\text{Total Area (Square Miles)}}\)
    - PDI: Percentile rank of Population Density across all years and cities.

Commercial Density Index (CDI)

  • Definition: Evaluates the density of commercial establishments per block group.
  • Data Source: Data is sourced using the Overpass API.
  • Method:
  • Tags used include shops, restaurants, cafes, banks, schools, cinemas, parks, sports centers, and stadiums.
  • Area is derived from census tracts in the US Census GeoJSON files.

    \(\text{Commercial Density} = \frac{\text{Count of Commercial POIs}}{\text{Total Land Area (Square Miles)}}\)
    - CDI: Percentile rank of Commercial Density across all years and cities.

Intersection Density Index (IDI)

  • Definition: Quantifies the density of intersections in a given area.
  • Data Source: Retrieved using the Overpass API.
  • Method: \(\text{Intersection Density} = \frac{\text{Number of Nodes Part of More than One Way (Intersections)}}{\text{Area (Square Miles)}}\)
  • IDI: Percentile rank of Intersection Densities across all years and cities.

Land-use Diversity Index (LDI)

  • Definition: Analyzes the diversity of land-use types within an area.
  • Data Source: Land-use data is retrieved from OpenStreetMap using the Overpass API with the "landuse" tag.
  • Method: \(\text{Entropy} = \sum \left( \frac{\text{Area of Land Use Type}}{\text{Total Area}} \cdot \ln \left( \frac{\text{Area of Land Use Type}}{\text{Total Area}} \right) \right)\) (for all land-use types with non-zero area).
    • Normalized by: \(\frac{\text{Entropy}}{\ln(\text{Number of Land Use Types with Non-Zero Area})}\)
    • LDI: Percentile rank of Entropies across all years and cities.

4. PEI Formula

The PEI is calculated using the following formula:

\[ PEI = \frac{{(1 + PDI) \cdot (1 + IDI) \cdot (1 + LDI) \cdot (1 + CDI)}}{16} \]

5. Implementation Workflow

Step 1: Files

  • Download population data files from the Missouri Census Data Center (MCDC) for each required year.
  • Download block group and census tract files from the US Census Bureau website.

Step 2: Subindex Calculation

  • Run individual generator scripts (e.g., <subindex>_<city>_<year>.ipynb) for each subindex.
  • Outputs include CSV and GeoJSON files with fields for block group, year, and the "raw subindex" values:
  • Population Density
  • Commercial Density
  • Intersection Density
  • Entropy
  • Append all results to master files (all_PDI, all_CDI, all_IDI, all_LDI) for comprehensive cross-year/city comparison.

Step 3: Normalization

  • Normalize raw subindex data - between 1 and 0:
  • This normalization is done by taking each block group/tract's percentile rank for each "raw subindex" versus every other city and every other year:
  • Because we normalize across all cities and years, our subindex values can be compared seamlessly against any other block group regardless of time/location.
  • We are able to normalize across all cities and years thanks to these aforementioned 4 files - all_PDI.csv, all_CDI.csv, all_IDI.csv, all_LDI.csv - which contain raw data for all years/cities.
  • Once we normalize the raw subindex we can now call it an actual subindex - e.g. the normalized Commercial Density becomes CDI, normalized Entropy becomes LDI, etc.
  • The file also updates the CSV & GeoJSON files for each subindex and city with a new field - one of CDI, LDI, PDI, IDI.

  • Now we finally have finalized CSV and GeoJSON files for the 4 subindexes:

    • <subindex>_<city>_<year>.csv/geojson

Step 4: PEI Calculation

  • Combine normalized subindices using the PEI formula for each block group/tract.
  • Generate CSV and GeoJSON files (PEI_<city>_<year>.csv/geojson).

Step 5: Web App Integration

  • Upload finalized GeoJSON files to AWS S3 buckets.
  • Implement and visualize data on the web app.

6. Usage

Inside the Fall24 folder you will find 3 folders:

  • Tract_Files - we mainly used this folder for testing:
  • This contains the relevant ipynb files for creating the subindexes.
  • It also contains tracts.geojson which has the first 10 rows of tracts in the US - useful for testing. - Please download full tract files from https://www.census.gov/cgi-bin/geo/shapefiles/index.php, or contact abeesen3@gatech.edu for full files.

  • BlockGroup_Files:

  • This contains the relevant ipynb files for creating the subindexes. (In the PDI file, only run code blocks after the #NEW comment).
  • It also contains block_groups.geojson which has the first 10 rows of blockgroups in Atlanta - useful for testing. - Please create the full files using the ./Spring24/Blockgroup GeoJSON Generator folder (you need to rename the output of this to block_groups.geojson), downlaod the full files from https://www.census.gov/cgi-bin/geo/shapefiles/index.php, or contact abeesen3@gatech.edu for full files.

Step 1: Data Download

Download the required data files from the following sources: - Population Data: Obtain CSV files from Missouri Census Data Center (MCDC). - Census Block Groups/Tract GeoJSON: Retrieve the required GeoJSON files from the US Census Bureau or relevant sources: - As described above, download files from https://www.census.gov/cgi-bin/geo/shapefiles/index.php, or contact abeesen3@gatech.edu for full files.

Step 2: Update Generator Scripts

Modify the generator scripts (PDI_Generator.ipynb, CDI_Generator.ipynb, LDI_Generator.ipynb, IDI_Generator.ipynb) to include your specific file paths and input parameters. For all the subindex files, they will have a portion like the code shown below. This is the only part you must update as required:

calculate_<subindex>(
    input_geojson="path_to_your_geojson_file.geojson",  # Replace with your census tract or blockgroup GeoJSON file
    output_prefix="<tracts> or <block_groups>", # tracts or bg based on if we are analyzing tracts or blockgroups
    year=2013,
    aggregate_file="<subindex>_<tract/bg>_all.csv"  # update the <subindex> and choose tracts or bg
)

calculate_<subindex>(
    input_geojson="path_to_your_geojson_file.geojson",  # Replace with your census tract or blockgroup GeoJSON file
    output_prefix="<tracts> or <block_groups>", # tracts or bg based on if we are analyzing tracts or blockgroups
    year=2017,
    aggregate_file="<subindex>_<tract/bg>_all.csv"  # update the <subindex> and choose tracts or bg
)

calculate_<subindex>(
    input_geojson="path_to_your_geojson_file.geojson",  # Replace with your census tract or blockgroup GeoJSON file
    output_prefix="<tracts> or <block_groups>", # tracts or bg based on if we are analyzing tracts or blockgroups
    year=2022,
    aggregate_file="<subindex>_<tract/bg>_all.csv"  # update the <subindex> and choose tracts or bg
)

Step 3: Run Scripts in the Following Order

  1. Run the Subindex Generators:
    Execute the following scripts to calculate raw subindices:
  2. CDI_Generator.ipynb
  3. LDI_Generator.ipynb
  4. IDI_Generator.ipynb
    These can be run in any order.

  5. Run PDI

  6. For small input files (not many tracts or geojsons), run our current PDI_Generator.ipynb.
  7. For larger files, a custom approach using CSV files from Missouri Census Data Center (MCDC) is requied: - For this, please contact cnguyen369@gatech.edu

  8. Normalize Subindices:
    Run Normalizer.ipynb to normalize the raw subindices across all years and cities.

  9. Generate PEI:
    Finally, run PEI_Generator.ipynb to calculate the Pedestrian Environment Index.

Step 4: Output

  • This process will output normalized subindex files and the final PEI results as CSV and GeoJSON files.
  • The file format will be:
    • <subindex>_<city>_<year>.csv/geojson
  • Utilize the Subindex_Visualizer.ipynb file to visualize your geojson file output!

7. Challenges

The biggest challege in our statistic generators was developing the PDI Generator.

  • While most of our subindexes - CDI, LDI, IDI - use the Overpass API (OSM data) to gather data, this is not possible for the PDI as population data is not provided by OSM.

  • Because of this, we were forced to utilize the Census API, which had 2 main issues:

    • It often returned simply the latest data i.e. 2024 data - even when we requested historical population data.
    • On large geoJSONs, where we have to make hundreds and thousands of API calls, the Census API frequently errored due to API call limits.
      • This became a considerable problem when running our files using PACE to generate Census Tract data for Dr Ku. Our code would run for 10 or so hours and then fail - as we would run out of API tokens.
  • We got over this challenge by downloading population data by tract/block group directly - from Missouri Census Data Center (MCDC)

  • We could then easily calculate Population Density and hence PDI by block_group/tract by merging this data with our block_groups/tracts geoJSON files - which contain an area column.

Fall 2025 Additions Summary

We had 3 main goals this semester: - Adding new subindexes to the overall PEI, to flesh out the statistic and ensure it is as comprehensive as possible. - Update the web app with a few new features: namely allowing for "sliders", so that users can customize subindex weights (as well as potentially figuring out how to display our 100mb+ nationwide data onto the web app). - Continuing to work alongside Dr Ku with both data generation and tool creation for his research linking mental health issues to walkability.


8. Fall 2025 Additions - Bike Infrastructure Index (BII)

Overview

The Bike Infrastructure index scores an area based on the quantity and quality of bike infrastructure.

Motivation: Research has shown how closely related bike-ability and walkability are to a well designed urban environment. Our current approach to PEI ignored biking as a factor, so we wanted to develop a new index that incorporates biking.

Central Idea

Map out all bikeable roads in a given area. Then categorize these roads by how beneficial they are as biking infrastructure. Finally find the distance that the infrastructure covers relative to area.

Methodology

1) Weight each major category of bike infrastructure from OSM data.

\[ \text{Separate/Protected/Path/Cycle Streets} = \text{0.5} $$ $$ \text{Painted Lanes} = \text{0.25} $$ $$ \text{Shared Roads} = \text{0.15} $$ $$ \text{Local Roads} = \text{0.1} \]

2) Score each piece of infrastructure based on length and weight

\[ \text{Infrastructure Score} = \text{Category weight} * \text{Infrastructure distance} \]

3) Sum score for a given area

\[ \text{AreaScore} = \sum_{i=1}^{n} \text{Infrastructure Score}_i \]

4) Normalize by area size

\[ \text{BII} = \frac{\text{AreaScore}}{\text{AreaSize}} \]

Data Collection

We used OpenStreetMap (OSM) to identify and extract bike infrastructure through relevant polygon-based tags, including:

  • "bicycle": True, "bicycle:conditional": True, "bicycle_road": True, "cyclestreet": True,
  • "cycleway": True, "cycleway:segregated": True, "cycleway:both": True,
  • "cycleway:both:segregated": True, "cycleway:left": True, "cycleway:left:oneway": True,
  • "cycleway:left:segregated": True, "cycleway:right": True, "cycleway:right:oneway": True,
  • "cycleway:right:segregated": True, "oneway": True, "oneway:bicycle": True,
  • "direction": True, "ramp:bicycle": True, "segregated": True, "highway": True, "access": True,
  • "access:conditional": True, "foot": True, "route": True, "network": True, "ref": True

After collecting this data we had to do a lot of filtering to make sure roads were only counted once, to make sure only roads that had the bike tag were included, and to make sure no roads for only cars were included.

Results & Visualization

We were able to generate BII across 2013, 2017, and 2022 for Atlanta. The percent change of BII across all three years is shown below.

Atlanta BII

The image suggests that Atlanta has become more bikeable over time. This analysis perfects algins with the continued investment into bike infrastructure projects by the city of Atlanta.

The next steps of BII is to generate data across the US so that it can properly be integrated into the website and PEI database.

9. Fall 2025 Additions - Road Safety index (RSI)

Overview

The Road Safety Index quantifies how safe (and therefore how walkable) an area is based on the speed limits of its roads.

Motivation: Research consistently shows a strong relationship between road speed and pedestrian injury severity and pedestrian safety. Thus, we wanted to develop an index that accounts for how road speeds in neighborhoods can affect pedestrian safety, and consequently that area's walkability.

Central Idea

We treated higher road speeds as higher risk for pedestrians. RSI computes a risk score per road segment, then aggregates to an area-level score (e.g., census block group / tract) to visualize relative safety/walkability.

Methodology

1) Risk from speed: Nilsson’s Power Model

We used Nilsson’s Power Model to translate traffic speed into expected changes in crash outcomes.

\[ R_{\text{road}} = \left(\frac{v}{v_0}\right)^{\beta} \]

2) Road-level safety score (baseline = 20 mph)

Using a baseline speed of 20 mph, we compute a risk score per road segment:

\[ \text{RiskScore} = \left(\frac{\text{RoadSpeed}}{20}\right)^{1.5} \]

3) Weight by road segment length

Longer roads should contribute more to an area’s overall safety score, so we weight each segment by its length:

\[ \text{SegmentRisk} = \text{SegmentLength} \cdot \text{RiskScore} \]

4) Aggregate to area (block group / tract)

We aggregate all segment contributions inside each area:

\[ \text{AreaScore} = \sum_{i=1}^{n} \text{SegmentRisk}_i \]

5) Optional normalization by area size

To compare areas of different sizes, we optionally normalize by geographic area:

\[ \text{FinalRSI} = \frac{\text{AreaScore}}{\text{AreaSize}} \]

Data Collection

Challenge: Missing speed limits in OpenStreetMap

OpenStreetMap (OSM) does not have comprehensive maxspeed data across all roads. To address this, we used a policy-driven approach:

  1. Research state legal documentation for default speed limits by road type
  2. Match default limits to roads using OSM highway tags
  3. Assign inferred speeds where maxspeed is missing

We focused on OSM highway tags that are most likely to affect pedestrian environments: - tertiary - residential - unclassified

Results & Visualization

This semester, we focused on producing RSI data for the Atlanta area. Below, you will find a graph visualizing how walkable Atlanta is based on our RSI calculations. Note: Lower RSI scores means an area is more walkable.

Atlanta Road Safety Index Map

Several of the highest-safety block groups identified by RSI correspond to: - Smaller/local streets
- Greener residential environments
- Lower-speed road networks

There are still improvements that we are interested in making to RSI such as taking into account roads with other highway tags on OSM into our calculations and looking into decreasing the risk score for road segements that have an attached sidewalk.


10. Fall 2025 Additions – Social Greenspace Index (SGI)

Overview

The Social Greenspace Index (SGI) introduces a new dimension of walkability to the Pedestrian Environment Index (PEI) by quantifying access to outdoor social greenspaces within a given area.

Motivation: While greenspace is often measured through environmental indicators such as tree canopy coverage, air quality, or climate conditions, this subindex focuses specifically on man-made, social outdoor spaces—places where people actively gather, recreate, and spend time outdoors. We hypothesize that areas with more accessible social greenspaces are inherently more walkable, as these spaces both encourage and require pedestrian activity.

Central Idea

SGI treats social greenspace area as a proxy for pedestrian-oriented urban design. Rather than counting the number of greenspace features, the index measures the total area of social greenspaces within a census tract relative to the tract’s total land area.

This approach prioritizes: - Parks and playgrounds
- Dog parks and recreational fields
- Stadiums and other outdoor gathering spaces

The underlying assumption is that the more space a neighborhood devotes to outdoor social activity, the more conducive it is to walking.


Methodology

1) Defining Social Greenspace

SGI began as a broader Environmental Index, initially exploring factors such as: - Tree canopy coverage
- Climate variation
- Air quality (e.g., CDC air quality datasets)

However, the scope was narrowed to focus on social greenspace, as this more directly reflects pedestrian use and walkability rather than environmental conditions alone.

2) Data source: OpenStreetMap (OSM)

We used OpenStreetMap (OSM) to identify and extract social greenspaces through relevant polygon-based tags, including:

  • leisure: park, playground, dog_park, stadium, common
  • natural: grassland, wood, fell
  • landuse: meadow, vineyard

Unlike count-based indices, SGI relies on area-based polygons, allowing us to capture the actual spatial footprint of greenspaces.

3) Area-based scoring

For each census tract, the Social Greenspace Index is computed as:

\[ \text{SGI} = \frac{\text{Total Social Greenspace Area}}{\text{Total Tract Area}} \]

This produces a normalized score between 0 and 1, enabling comparison across tracts of different sizes.

4) Integration with existing PEI structure

SGI was designed to align with the existing PEI framework and methodology, adapting concepts from prior density-based subindices (e.g., CDI) while shifting from point counts to polygonal area aggregation.


Results & Visualization

This semester, SGI was implemented and visualized for the Atlanta metropolitan area, with results shown for census tracts across multiple years (2013, 2017, and 2022). This is the visualization for 2022:

Atlanta Social Greenspace Index Maps (2013–2022)

Across the three time periods, the visualizations suggest that Atlanta has become more walkable over time when evaluated through the lens of social greenspace availability. Several tracts show noticeable increases in greenspace fraction, particularly in areas surrounding large parks and recreational corridors.


Limitations & Future Work

While SGI provides a meaningful new perspective on walkability, several limitations remain and will be addressed in future work:

  1. Polygon overlay verification
  2. A full validation of the spatial overlay process is needed to ensure all greenspace polygons are correctly intersected with census tract boundaries.

  3. Computational efficiency

  4. Area-based polygon processing is computationally intensive. Future iterations will focus on optimizing spatial operations to support nationwide implementation.

  5. Comparison with original Environmental Index concept

  6. A formal comparison between the initial Environmental Index (tree canopy, air quality, climate) and SGI will be conducted to evaluate their relative explanatory power for walkability outcomes.

11. Fall 2025 Additions — Dr. Ku Research Updates

PEI Analysis Updates

This semester included several important research updates from Dr. Ku’s group. As shown below, the analysis found a strong association between census tract–level Pedestrian Environment Index (PEI) and distressing Psychotic-Like Experiences (PLEs). Notably, this relationship remained significant after adjusting for a comprehensive set of individual- and neighborhood-level covariates, including:

  • Age
  • Sex
  • Race/ethnicity
  • Parental education
  • Family history of psychosis
  • Financial adversity
  • Neighborhood crime
  • Neighborhood population density

PEI association results


Neighborhood Matching Tool — Paper & Code

In parallel with this analysis, we completed a paper this semester describing the design and implementation of our Neighborhood Matching tool, which enables privacy-preserving linkage between participant-level data and census tract–level neighborhood measures.

Code repository:
🔗 https://github.com/SustainableUrbanSystemsLab/NeighborhoodMatcher

Paper:

Neighborhood Matcher paper preview


12. Overall Future Work

To improve the comprehensiveness of the Public Infrastructure Environment (PIE) framework, a major future goal is to expand the number of subindices beyond the current set.
If we were to do this, we also want to make sure that they are properly integrated into PEI.

Planned improvements include:

  • More New Subindices:

    • The more the merrier! Because we have shifted to a "slider" approach, where users customize their subindex weights towards overall PEI based on their personal needs. Adding new subindices will only further improve on not only the comprehensiveness of PEI, but also on the customizability of our product.
  • Integrate the Subindices fully with our current PEI:

    • As mentioned above we now have data for Atlanta for 4 new subindices, but we now must re-run our PEI generation pipeline to fully integrate these 4 into our nationwide datasets. Additionally, we will work towards adding the 4 new subindices to our web app.
  • Web App Expansion:

    • While we have nationwide datasets, our web app still only displays Atlanta data. We will work on adding new cities and potentially even adding nationwide data. We also want
  • Official Publication:

    • Publish our research officially and publicly to help advance urban sustainability.
  • Ground-Truthing:

    • Conduct surveys and other research to validate PEI accuracy and compare with other walkability models.

13. Contributing

We welcome contributions to this project.

Steps to Contribute:

  1. Fork the repository.
  2. Create a feature branch:
    git checkout -b feature/new-feature
    
  3. Push your changes and submit a pull request.

14. License

This project is shared for research and educational purposes. Please do not redistribute for commercial use.


Web App Documentation

The web app is currently deployed at this link: https://vip-pei-app-2.onrender.com/ 😊

This deployment is dynamic and so any updates to our codebase (https://github.com/AtharvaBeesen/vip-pei-app-2) will automatically be displayed.

1. Introduction

  • App Name: VIP SMUR PEI Proof of Concept
  • Purpose: Visualize the work we have done in creating the aforementioned subindexes. We also wanted to allow the data we generate to be available online in a visually appealing, paletable, and easy-to-download way.

Key Features:

  • Interactive map with GeoJSON visualization for the subindexes - PDI, IDI, CDI, LDI, PEI - across different cities and years.
  • Dynamic city, statistic, and year selection.
  • Ability to download CSV and GeoJSON files for selected data.

Technology Stack:

  • Frontend: React, JavaScript, HTML, CSS
  • Backend: All functionality contained within JavaScript
  • Mapping Library: Leaflet
  • Data Source: Amazon S3 Buckets

2. Getting Started

Prerequisites

  1. Node.js and npm/yarn:
    Ensure Node.js and npm (or yarn) are installed on your system. You can check this by running:

    node -v
    npm -v
    
    If not installed, download them from Node.js official site.

  2. Code Editor (Optional):
    Install a code editor like Visual Studio Code.

  3. Browser:
    A modern browser like Chrome, Firefox, or Edge to test your app.

  4. Git:
    Install Git for cloning the repository. Check installation by running:

    git --version
    

  5. Leaflet Library Dependencies:
    The app uses Leaflet for maps, which requires:

  6. A valid internet connection to download Leaflet assets via npm or yarn.
  7. Ensure the browser supports Leaflet.

Installation

  1. Clone the repository:
    git clone https://github.com/AtharvaBeesen/vip-pei-app-2.git
    
  2. Install dependencies:
    npm install
    
  3. Ensure Leaflet is installed:
    npm install leaflet
    
  4. Run the application:
    npm start
    
  5. Access the app at http://localhost:3000.

Deployment


3. Features

3.1 Interactive Map

  • Displays GeoJSON data visualized on a Leaflet map.
  • Map dynamically updates based on city, statistic, and year selections.

3.2 City, Statistic, and Year Selection

  • Dropdown menus for users to select:
  • Cities: Atlanta, New York, Los Angeles.
  • Statistics: IDI, PDI, CDI, LDI, PEI.
  • Years: 2022, 2013.

3.3 File Downloads

  • CSV and GeoJSON files for the selected data can be downloaded with a single click.

4. Components

4.1 App.js

  • The main entry point for the application.
  • Manages state for selected city, statistic, and year.
  • Renders CitySelector, DownloadButton, and MapComponent.

4.2 CitySelector.js

  • Dropdown menus for selecting city, statistic, and year.
  • Capitalizes city names and statistics for user-friendly display.

4.3 MapComponent.js

  • Displays the Leaflet map and GeoJSON data.
  • Dynamically fetches data from S3 Buckets based on user selections (more on this below).
  • Highlights GeoJSON features with a color-coded scheme based on statistic values.

4.4 DownloadButton.js

  • Provides buttons to download CSV and GeoJSON files from S3.
  • Dynamically constructs download URLs based on user selections.

5. API Integration

The app dynamically fetches GeoJSON data from an Amazon S3 bucket: - URL format:
https://vip-censusdata.s3.us-east-2.amazonaws.com/{city}_blockgroup_{statistic}_{year}.geojson

Example:

For Atlanta, IDI, and 2022:
https://vip-censusdata.s3.us-east-2.amazonaws.com/atlanta_blockgroup_IDI_2022.geojson


5. City Comparison Tool (Spring 2025)

1. Overview

We created a City Comparison Tool MVP to allow users to dynamically compare changes in walkability-related subindices (IDI, PDI, CDI, LDI, PEI) between two different years for a selected city.

This tool calculates and visualizes the percentage change in the selected statistic for each census block group, helping to identify areas that have improved or declined over time.

2. Key Features

  • City Selection:
    Compare changes for Atlanta, New York, or Los Angeles.

  • Statistic Selection:
    Choose one of the following subindices to analyze:

  • Intersection Density Index (IDI)
  • Population Density Index (PDI)
  • Commercial Density Index (CDI)
  • Land-use Diversity Index (LDI)
  • Pedestrian Environment Index (PEI)

  • Year Selection:
    Select two different years to calculate the percent change.

  • Dynamic GeoJSON Visualization:
    The map displays block groups color-coded by the percentage change in the selected statistic.

  • Interactive Tooltips:
    Hovering over a block group shows its GEOID and computed percent change.

  • Custom Color Scale:
    The visualization uses a diverging color scheme to easily distinguish between positive and negative changes.


3. Technical Workflow

  • Data Fetching:
    The tool fetches the respective city's GeoJSON files for both selected years from the Amazon S3 bucket.

  • Difference Calculation:

  • For most subindices (IDI, PDI, CDI, PEI), block groups are matched by GEOID.

  • Percent Change Computation:
    The percent change for each block group is calculated as:

\[ \text{Percent Change} = \frac{(\text{After Value} - \text{Before Value})}{\text{Before Value}} \times 100 \]
  • Visualization:
  • Block groups are shaded according to the magnitude of their percent change.
  • Tooltips display the block group ID and the exact percent change.

  • Robust Edge Case Handling:

  • If both before and after values are zero, the percent change is set to 0.
  • If a before value is zero and after is nonzero, the block group is highlighted accordingly without division errors.

4. Known Limitations

  • Only a few cities and years are currently available.

5. Future Work

  • Add more cities and historical years to expand the tool’s coverage.
  • Improve LDI data quality by assigning proper GEOIDs.
  • Integrate this comparison tool directly into the main PEI web app navigation.
  • Add multi-year trend graphs and regional aggregation for deeper urban insights.
  • Allow users to select multiple subindices at once for richer comparisons.

6. Metric Weighting & Composite Score Tool (Spring 2025)

1. Overview

We built a Metric Weighting and Composite Score tool that lets users control how different walkability subindices contribute to an overall score at the census block group level.

Instead of showing a single fixed index, this feature allows users to adjust the importance of each subindex using sliders and immediately see how those choices change the map. This makes it easier to explore how different definitions of “walkability” affect walkability patterns across a city.


2. Key Features

  • Interactive Metric Sliders
    Users can adjust the relative weight (0–100%) of each subindex:
  • Intersection Density Index (IDI)
  • Land-use Diversity Index (LDI)
  • Population Density Index (PDI)
  • Commercial Density Index (CDI)

  • Live Map Updates
    Any change to a slider instantly recalculates scores and updates the map.

  • Weighted Composite Scores
    Each block group receives a composite score based on the selected weights.

  • Color-Coded Visualization
    Block groups are shaded using a green–yellow–red scale, where higher values indicate more favorable pedestrian environments.

  • Informative Tooltips
    Hovering over a block group displays:

  • GEOID
  • Composite score
  • Individual subindex values used in the calculation

3. Technical Workflow

  • Data Loading
    For the selected city and year, the app fetches four separate GeoJSON files (one per subindex) from an Amazon S3 bucket:
  • {city}_blockgroup_IDI_{year}.geojson
  • {city}_blockgroup_LDI_{year}.geojson
  • {city}_blockgroup_PDI_{year}.geojson
  • {city}_blockgroup_CDI_{year}.geojson

  • GEOID Matching
    Subindex values are aligned across datasets using the block group GEOID to ensure consistency.

  • Composite Score Calculation
    For each block group, the composite score is calculated as a weighted average:

\[ \text{Composite Score} = \frac{\sum_{m} w_m \cdot v_m}{\sum_{m} w_m} \]

where: - \(v_m\) is the block group’s value for metric \(m\) - \(w_m\) is the user-defined weight for metric \(m\)

If all weights are set to zero, no composite score is shown to avoid misleading results.

  • Map Rendering
  • Recalculating scores triggers a map re-render.
  • A custom color scale maps composite values to shades of green, yellow, and red.
  • Tooltips are updated to reflect the new composite and individual metric values.

4. Design Rationale

This feature is designed to make the index construction process transparent. By letting users control metric weights, the tool shows how assumptions about what matters for walkability can change the results. This is particularly useful for researchers who may be targeting specific elements of walkability more than others (for example, researchers more interested in the effects of higher land use variation may adjust so that LDI is higher weighted).

Rather than presenting a single “correct” score, the interface encourages exploration and comparison of different weighting choices.


5. Known Limitations

  • Composite scores depend on how the underlying subindices are scaled.
  • Only Atlanta data is currently available.

6. Future Work

  • Include new subindices we have created recently to be sider options (such as our transit, biking, road safety, and greenspace subindexes).
  • Allow users to save and share custom weighting presets.
  • Support side-by-side comparison of different weighting schemes.

7. Future Work

There are 3 key goals we hope to achieve:

  1. Increase the number of cities and years supported:
    This would simply require us to continue running our subindex generators over the course of the next semester(s) in order to continue to grow the size of our database.

  2. Seek Collaboration/Monetization Opportunities:
    As we grow the site and our footprint in the space, we could seek to replicate WalkScore's monetization and collaboration business model:

  3. Collaborate with products/sites:
    Work with products or sites that require walkability statistics (e.g., Zillow and City Planning Companies) to create customized statistics at a cost.

  4. Direct collaboration with local government:
    Assist local governments in achieving their goals of improving walkability in urban areas.

  5. Developing a for-cost API:
    Create an API that allows third-party researchers to use our data.

    • For Example: Collaborating with researchers like Dr. Ku, who uses our data to enhance his psychology research.

8. Contributing

  • Please contact abeesen3@gatech.edu before doing so.
  • Example of how to contribute:
  • Fork the repository (https://github.com/AtharvaBeesen/vip-pei-app-2)
  • Create a feature branch:
    git checkout -b feature/new-feature
    
  • Push your changes and submit a pull request.

9. License

This project is shared for research and educational purposes. Please do not redistribute for commercial use.


Presentation

Team

Name Seniority Major School # Semesters GitHub Handle
Atharva Beesen Senior Computer Science SCS 3 AtharvaBeesen
Mason Dewitt Sophomore Computer Engineering ECE 2 Masonrd
Katherine Davis Sophomore Industrial Engineering ISYE 1 katherine-el-davis
Lucy Chai Freshman Industrial Engineering ISYE 1 lucymchai