Usage<\/h2>
The notebook is structured to be followed sequentially. Detailed comments and markdown notes guide through each step of the analysis and modeling process.<\/p>
<\/p>
Models and Algorithms Used<\/h2> - Kernel Densities<\/strong><\/li>
- Space-Time Prisms<\/strong><\/li>
- Volumetric Population Estimation<\/strong><\/li>
- Vehicle Profile Routing (Itinero)<\/strong><\/li> <\/ul>
Data Description<\/h2>
Densities for segregation are calculated and output through the heatmap weighted by population. In Rhino, the heatmap overlays a segment of data from OSM that will display darker blue for greater density and red for lower. Aggregated results can be generated through dataset and certain amenity types to compare the average encounter densities.<\/p>
Key Findings and Observations<\/h2> - Kernel densities allow for a simple calculation of segregation under the definition of interaction between pedestrians in a defined 15-minute city<\/li>
- Volumetric Method with building area, building height, and census population provides general estimate for populations with data from https:\/\/opendata.atlantaregional.com\/<\/li>
- Potential for interaction is best calculated through space-time prisms which are more accurately representing spatial and temporal dynamics and constraints<\/li>
- Increased local usage correlates with higher experienced segregation for low-income residents.<\/li> <\/ul>
Conclusions<\/h2>
This notebook serves as a detailed example of using methods within provided data and activity spaces to calculate segregation values for a 15-minute city. The methodologies outlined here can be adapted and expanded for other types of assessment for pedestrian mobility and accessibility.<\/p>
References<\/h2> - Abbiasov, et al. (2024) The 15-minute city quantified using human mobility data.<\/li>
- Patterson & Farber (2015) Potential Path Areas and Activity Spaces in Application: A Review<\/li>
- Sch\u00f6nfelder (2002) Measuring the size and structure of human activity spaces: The longitudinal perspective.<\/li> <\/ul>
Itinero<\/h1> Overview<\/h2>
Itinero is a flexible open-source routing engine for a variety of transportation modes such as walking, cycling, and driving. It provides sophisticated tools to integrate customizable routing solutions into their applications, enabling efficient navigation. Itinero emphasizes versatility, offering support for various map data formats and allowing customization to suit specific needs. Most importantly, features like offline routing and routing across multiple transportation modes are provided. For the sake of this project, the pedestrian shortest path profile is utilized to calculate and map routes for individuals within the city.<\/p>
Repository<\/h2>
Itinero Routing<\/a><\/p> Features<\/h2> - Routing<\/strong>: The Router uses the RouterDb data to calculate routes for a given Profile. It starts and ends the Route at a RouterPoint.<\/li>
- RouterDb: Contains the routing network, all meta-data, restrictions and so on.<\/li>
- Profile: Defines vehicles and their behaviour.<\/li>
- RouterPoint: A location on the routing network to use as a start or endpoint of a route.<\/li>
- Router: The router is where you ask for routes.<\/li>
- GeoJSON Conversion<\/strong>: Export calculated routing to GeoJSON for use in mapping and other geospatial applications.<\/li>
- Open Street Maps Data Retrieval<\/strong>: Automatically download street and building data required for demand calculations.<\/li> <\/ul>
Getting Started<\/h2>
To start using Itinero, follow these steps: 1. Install following Itinero packages to .NET project: - Itinero: The Itinero routing core, this is usually the only package you need to install. - Itinero.Geo: This package ensures compatibility with NTS. - Itinero.IO.Osm: This package contains code to load OSM data. - Itinero.IO.Shape: This package contains code to load data from shapefiles. 2. Specify OSM file as needed 3. Run project through determined routing coordinates<\/p>
Data Requirements<\/h2> - Street data should include both OSM or FEMA tag attributes for project defined amenities and places of work<\/li>
- Open Street Maps (OSM): amenities and workplaces<\/li>
- Federal Emergency Management Agency (FEMA): residentials<\/li> <\/ul>
Credits<\/h2>
Itinero<\/a> is open-source and commercially supported, developed by the Itinero BVBA team. Itinero was built using OpenStreetMap<\/a><\/p> Future Work<\/h1> - Integrate temporal layer to find effective rates of encounter between pedestrians.<\/li>
- Generate daily routines to represent more realistic behavior.<\/li>
- Normalization of results to allow comparisons across sites with different total populations.<\/li> <\/ul>","link":"https:\/\/vip-smur.github.io\/24sp-mobility-seg\/?utm_source=documentation&utm_medium=RSS&utm_campaign=feed-syndication","pubDate":"Wed, 11 Mar 2026 12:46:50 +0000","source":"Surrogate Modeling for Urban Regeneration (SMUR)","comments":"https:\/\/vip-smur.github.io\/24sp-mobility-seg\/#__comments","guid":"https:\/\/vip-smur.github.io\/24sp-mobility-seg\/","enclosure":{"@attributes":{"url":"https:\/\/vip-smur.github.io\/assets\/images\/social\/24sp-mobility-seg\/README.png","type":"image\/png","length":"None"}}},{"title":"24-Sp-Mobility-PEI","description":"
Pedestrian Environment Index (PEI) Documentation<\/h1>
The Pedestrian Environment Index (PEI) is a composite measure of walkability that combines four key subindices to evaluate pedestrian-friendly environments.<\/p>
Core Subindices<\/h3> - Population Density Index (PDI)<\/strong><\/li>
- Measures residential population density within defined areas<\/li>
- Data sourced from Census block groups<\/li>
-
Implementation: PDI_generator.ipynb<\/code><\/p> <\/li> -
Commercial Density Index (CDI)<\/strong><\/p> <\/li> - Evaluates density of commercial establishments per Block Group<\/li>
- Indicates availability of walkable destinations and services<\/li>
-
Implementation: CDI_generator.ipynb<\/code><\/p> <\/li> -
Intersection Density Index (IDI)<\/strong><\/p> <\/li> - Quantifies intersection density within an area<\/li>
- Evaluates route options and pedestrian safety<\/li>
-
Implementation: IDI_generator.ipynb<\/code><\/p> <\/li> -
Land-use Diversity Index (LDI)<\/strong><\/p> <\/li> - Analyzes mix of land-use types (residential, commercial, industrial)<\/li>
- Assesses environment walkability through land use diversity<\/li>
- Implementation:
LDI_generator.ipynb<\/code><\/li> <\/ol> Implementation Workflow<\/h2> - Subindex Calculation<\/strong><\/li>
- Individual Jupyter notebooks (
*_generator.ipynb<\/code>) process Census block group shapefiles<\/li> - Each generator computes its respective subindex score<\/li>
-
Outputs saved as CSV or GeoJSON files<\/p> <\/li>
-
PEI Compilation<\/strong><\/p> <\/li> PEI_generator.ipynb<\/code> combines subindex outputs<\/li> -
Computes final PEI score for each block group<\/p> <\/li>
-
Visualization<\/strong><\/p> <\/li> - Results displayed as geographic maps<\/li>
- PEI scores visualized across census block groups<\/li> <\/ol>
Note: Project is transitioning to standardize all output files to GeoJSON format.<\/em><\/p> Detailed Index Methodologies<\/h2> Commercial Density Index (CDI)<\/h3> Overview<\/h4>
Calculates amenity counts per block group, normalized against the region's maximum commercial density.<\/p>
Input Data<\/h4> - Source:
atl_bg.geojson<\/code><\/li> - Contains Atlanta neighborhood data<\/li>
- Uses OSMNx for amenity quantification<\/li> <\/ul>
Amenity Categories<\/h4> - Groceries<\/strong>: supermarket, convenience, grocery, food, organic<\/li>
- Restaurants<\/strong>: restaurant, cafe, food_court, bistro, fast_food<\/li>
- Banks<\/strong>: bank, atm<\/li>
- Schools<\/strong>: school, college, university, kindergarten, music_school, language_school, driving_school<\/li>
- Entertainment<\/strong>: cinema, theatre, nightclub, casino, arts_centre, sports_centre, stadium, amusement_arcade, dance, bowling_alley, attraction, theme_park, zoo<\/li>
- Parks<\/strong>: recreation_ground, grass, greenfield<\/li> <\/ul>
Output<\/h4>
Normalized commercial density values relative to regional maximum<\/p>
Intersection Density Index (IDI)<\/h3> Overview<\/h4>
Analyzes intersection patterns within block groups to evaluate street connectivity.<\/p>
Input Requirements<\/h4> - GeoJSON file containing:<\/li>
- Block group geometries<\/li>
- State and county FIPS codes<\/li> <\/ul>
Output Data (CSV)<\/h4> - Polygon: Block group geometry<\/li>
- Area: Block group area<\/li>
- Intersection: Sum of intersection-connected roads<\/li>
- IDI: Normalized intersection density value<\/li> <\/ul>
Processing Steps<\/h4> - Read GeoJSON geometry data<\/li>
- Extract intersection data via OSMNx<\/li>
- Calculate equivalency factors<\/li>
- Compute population density<\/li>
- Generate visualization-ready output<\/li> <\/ol>
Land Diversity Index (LDI)<\/h3> Overview<\/h4>
Evaluates land use diversity within block groups.<\/p>
Input Requirements<\/h4> - GeoJSON file containing:<\/li>
- Block group geometries<\/li>
- State and county FIPS codes<\/li> <\/ul>
Output Data (CSV)<\/h4> - Polygon: Block group geometry<\/li>
- Land_use_dict: Land use type areas<\/li>
- Entropy: Block entropy value<\/li>
- LDI: Normalized land diversity value<\/li> <\/ul>
Processing Steps<\/h4> - Extract GeoJSON geometry<\/li>
- Gather land use data via OSMNx<\/li>
- Calculate block entropy<\/li>
- Compute land diversity<\/li>
- Prepare visualization data<\/li> <\/ol>
Population Density Index (PDI)<\/h3> Overview<\/h4>
Processes Census Bureau population data to calculate density metrics.<\/p>
Input Requirements<\/h4> - GeoDataFrame with:<\/li>
- Block group geometries<\/li>
- State\/county FIPS codes<\/li>
- Census API key (from parameter or
census_api_key.txt<\/code>)<\/li> <\/ul> Output Data (GeoDataFrame)<\/h4> - POP: Block group population<\/li>
- POPDENSITY: Persons per square kilometer<\/li>
- NORMPOPDENSITY: Normalized population density<\/li> <\/ul>
Processing Steps<\/h4> - Validate API credentials<\/li>
- Extract FIPS codes<\/li>
- Retrieve Census data<\/li>
- Integrate population data<\/li>
- Calculate density metrics<\/li>
- Clean and format output<\/li> <\/ol>
Error Handling<\/h4>
Raises ValueError if Census API key is unavailable<\/p>","link":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/?utm_source=documentation&utm_medium=RSS&utm_campaign=feed-syndication","pubDate":"Wed, 11 Mar 2026 12:46:50 +0000","source":"Surrogate Modeling for Urban Regeneration (SMUR)","comments":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/#__comments","guid":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/","enclosure":{"@attributes":{"url":"https:\/\/vip-smur.github.io\/assets\/images\/social\/24sp-mobility-pei\/README.png","type":"image\/png","length":"None"}}},{"title":"24-Fa-Microclimate-LSTM-Kriging","description":"
24Fa-Microclimate-Geo-LSTM-Kriging<\/h1>
Urban Weather Generator Deep Learning: LSTM-Kriging Model<\/p>
Description<\/h2>
This project aims to understand and reproduce data published by the National University of Singapore's (NUS) approach for microclimate prediction, the Geo-LSTM-Kriging Model. This model meshes three key layers to provide accurate microclimate predictions using local weatherstation data. The model takes together LULC data, historical data, and spatial distance information to learn from previous data and apply such learnings to present data. This combination is a novel combination of the strengths of LSTM's time series predictions and Kriging's spatial data dependencies.<\/p>
This team spent work cleaning up the open-source code from NUS to understand the model's inputs better. Having improved legibility, the adapatability of the model was clear to the team and allowed them to integrate campus-specific data. The team's work this semester was focused to replicate the NUS's model for Georgia Tech campus. The team used real weather data collected on GT campus coupled with Tech's Tree Viewer App to improve the accuracy of results for the campus. <\/p>
Requirements<\/h2> - Python<\/li>
- Pandas<\/li>
- Numpy<\/li>
- OSMNX<\/li>
- Scikit-Learn<\/li>
- Pytorch<\/li>
- Pykrige<\/li> <\/ol>
In addition this program requires that you provide a dataframe for the features you want to measure, as well as gridpoint data for the Kriging Regression. We\u2019ve provided test dataframes that you can find within the \u201cweather_station_5min\u201d and \u201cweather_station_60min\u201d folders. <\/p>
Repository Structure<\/h2>
This repo contains the aspects needed to replicate the Geo-Kriging LSTM Model. Inside the \u201cpython\u201d folder, you will find the necessary notebook files to execute it. The main ones to focus on are \u201cOrganized_Model_Eval.ipynb\u201d and \u201cosmnx 2.ipynb\u201d. The latter is used to gather the necessary gridpoint data for the kriging aspect and the former is utilized for execution of the models onto the data.<\/p>
Installation<\/h2>
Each of the required libraries can be easily installed with pip. For OSMNX, a separate process is required. You can find it at this link<\/a>. Once installed, run the \u201cosmnx 2.ipynb\u201d with the OX kernel.<\/p> Methodology<\/h2>
![\"\"](\"Figures\/1Methodology.png\")
<\/p>
For the methodology, the team used three wokflows: pre-processing, machine learning (ML) training, & prediction and plotting. Pre-processing involves cleaning up the data and making it usable for the ML training workflow. For the spatial method that the team incorporated into the model, the OpenStreetMap Python library osmnx, and using the library, a map of Georgia Tech's campus was used as a basis. Overlayed on top of the map is system of equally spaced out points forming a grid. For each of the equidistant points, 12 distance vectors were obtained. Theses distances are from each point on the grid to the nearest centers of various variables; these various variables are buildings, libraries, parks, parking, footways, grass, fitness centers, woods, wetlands, trees on campus, and trees in Atlanta off Tech's campus. The tree data was not easily accessible through osmnx, so the team utilized Georgia Tech's Tree Viewer App for the tree location data and distances. In the Geo-LSTM-Kriging model that our team followed, Kriging is a statistical method for spacial interpolation, predicting unknown values at locations that don\u2019t have measured values by using spatial correlations. These spatial correlations, the 12 distance vectors for each x,y point, are based off of relationships between variables. Dr. Brian Stone's weather data obtained from the several weather stations he set up a year ago on Tech's campus was used as an input for pre-processing as well, and it mainly provided information on temperatures, dew point, and relative humidity. This is the data that our group tried to find out and this data will be used as a means for comparison and training the machine learning model. The weather data from Dr. Stone's weather stations were quite messy and required cleaning. The coordinates for each of the weather stations were obtained and separated into folders. Within each of the weather station files, the averages of the data columns, namely the temperatures, dew point, and relative humidities columns, were obtained. This normalization of data to a value of zero to one ensures that during training, there will not be any errors that come up when predicting new values. Each of the normalized values were then appended into a dictionary for machine learning training. Originally, our team tried to train the weather station files in one single large data set, however it was too much for a computer to handle, so splitting it up to dictionaries ensure that it was able to run very smoothly. The outputs of the pre-processing workflow are the CSV file for the grid distances and a CSV for the normalized weather station values. <\/p>
![\"\"](\"Figures\/2Trees.png\")
![\"\"](\"Figures\/3Grid_data.png\")
![\"\"](\"Figures\/4station_id.png\")
![\"\"](\"Figures\/5coord.png\")
![\"\"](\"Figures\/6weather_dict.png\")
<\/p>
Using PyTorch, the team set the main target for the prediction as the temperature and main features as relative humidity and dew point. A sequence for the LSTM was created and set as default the 10 time steps. The team did not change the parameter values too much, as the team followed the documentation's recommendations. The hidden size was changed to about 8 layers and 200 epochs, which are how many iterations one wants the program to run through the training and ensures that the program is decently trained and not too overfitted. After training each of the weather station files independently, they are all appended into one single data frame to obtain the average prediction results for each of the stations.<\/p>
![\"\"](\"Figures\/7station_loop.png\")
![\"\"](\"Figures\/8station_results.png\")
<\/p>
The distance vectors obtained from each of the approximately 1300 different grid points mentioned earlier were used for the actual Geo-Kriging part of the project. The model is based off the random forest regression because random forest typically works well with a lot of different types of parameters, especially if the data turns out to be non linear.<\/p>
![\"\"](\"Figures\/9features.png\")
![\"\"](\"Figures\/10regression.png\")
<\/p>
The team finally fit the model with these parameters to obtain a temperature graph displaying the heat distribution of Georgia Tech's campus. <\/p>
![\"\"](\"Figures\/11output.png\")
<\/p>
Future Work<\/h2>
The team would like to run further validation studies on the model to ensure its functionality in different climates and with consistent data. As the NUS ran their model using a month's data, given steady annual temperature data, and our weather station data is inconsistent, the model should be continute to be validated before considered for further application.<\/p>
To enhance the robustness and applicability of the LSTM-Kriging Model for urban weather generation, the following future developments are proposed: 1. Accuracy Validation<\/p>
A critical next step is to rigorously test the accuracy of the model under various scenarios. Comparative analysis with existing models and observations will help assess the reliability and identify potential areas for refinement, including:<\/p>
\u2022 Assessing the model's predictions across various time scales, such as hourly, daily, and seasonal trends, to identify performance consistency over short- and long-term periods. <\/p>
\u2022 Performing a detailed breakdown of prediction errors to uncover biases or patterns associated with specific weather variables (temperature, humidity, wind speed) and urban contexts.<\/p>
- Handling Missing Data<\/li> <\/ol>
Addressing missing data in weather and spatial datasets remains a key challenge. Future work will focus on integrating advanced imputation techniques or machine learning methods to fill data gaps effectively without compromising the model's performance, including:<\/p>
\u2022 Using diffusion models to reconstruct missing data patterns.<\/p>
- Generalizability Testing<\/li> <\/ol>
The model will be tested on additional university campuses with contexts similar to Georgia Tech, particularly those featuring comparable weather station setups and spatial characteristics. This will help evaluate the model's adaptability to different urban microclimates and provide insights for broader applications. <\/p>
Reference<\/h2>
Jintong Han, Adrian Chong, Joie Lim, Savitha Ramasamy, Nyuk Hien Wong, Filip Biljecki, (2024). Microclimate spatio-temporal prediction using deep learning and land use data. Building and Environment. https:\/\/doi.org\/10.1016\/j.buildenv.2024.111358<\/a><\/p> Presentation<\/h2>
Data Description<\/h2>
Densities for segregation are calculated and output through the heatmap weighted by population. In Rhino, the heatmap overlays a segment of data from OSM that will display darker blue for greater density and red for lower. Aggregated results can be generated through dataset and certain amenity types to compare the average encounter densities.<\/p>
Key Findings and Observations<\/h2> - Kernel densities allow for a simple calculation of segregation under the definition of interaction between pedestrians in a defined 15-minute city<\/li>
- Volumetric Method with building area, building height, and census population provides general estimate for populations with data from https:\/\/opendata.atlantaregional.com\/<\/li>
- Potential for interaction is best calculated through space-time prisms which are more accurately representing spatial and temporal dynamics and constraints<\/li>
- Increased local usage correlates with higher experienced segregation for low-income residents.<\/li> <\/ul>
Conclusions<\/h2>
This notebook serves as a detailed example of using methods within provided data and activity spaces to calculate segregation values for a 15-minute city. The methodologies outlined here can be adapted and expanded for other types of assessment for pedestrian mobility and accessibility.<\/p>
References<\/h2> - Abbiasov, et al. (2024) The 15-minute city quantified using human mobility data.<\/li>
- Patterson & Farber (2015) Potential Path Areas and Activity Spaces in Application: A Review<\/li>
- Sch\u00f6nfelder (2002) Measuring the size and structure of human activity spaces: The longitudinal perspective.<\/li> <\/ul>
Itinero<\/h1> Overview<\/h2>
Itinero is a flexible open-source routing engine for a variety of transportation modes such as walking, cycling, and driving. It provides sophisticated tools to integrate customizable routing solutions into their applications, enabling efficient navigation. Itinero emphasizes versatility, offering support for various map data formats and allowing customization to suit specific needs. Most importantly, features like offline routing and routing across multiple transportation modes are provided. For the sake of this project, the pedestrian shortest path profile is utilized to calculate and map routes for individuals within the city.<\/p>
Repository<\/h2>
Itinero Routing<\/a><\/p> Features<\/h2> - Routing<\/strong>: The Router uses the RouterDb data to calculate routes for a given Profile. It starts and ends the Route at a RouterPoint.<\/li>
- RouterDb: Contains the routing network, all meta-data, restrictions and so on.<\/li>
- Profile: Defines vehicles and their behaviour.<\/li>
- RouterPoint: A location on the routing network to use as a start or endpoint of a route.<\/li>
- Router: The router is where you ask for routes.<\/li>
- GeoJSON Conversion<\/strong>: Export calculated routing to GeoJSON for use in mapping and other geospatial applications.<\/li>
- Open Street Maps Data Retrieval<\/strong>: Automatically download street and building data required for demand calculations.<\/li> <\/ul>
Getting Started<\/h2>
To start using Itinero, follow these steps: 1. Install following Itinero packages to .NET project: - Itinero: The Itinero routing core, this is usually the only package you need to install. - Itinero.Geo: This package ensures compatibility with NTS. - Itinero.IO.Osm: This package contains code to load OSM data. - Itinero.IO.Shape: This package contains code to load data from shapefiles. 2. Specify OSM file as needed 3. Run project through determined routing coordinates<\/p>
Data Requirements<\/h2> - Street data should include both OSM or FEMA tag attributes for project defined amenities and places of work<\/li>
- Open Street Maps (OSM): amenities and workplaces<\/li>
- Federal Emergency Management Agency (FEMA): residentials<\/li> <\/ul>
Credits<\/h2>
Itinero<\/a> is open-source and commercially supported, developed by the Itinero BVBA team. Itinero was built using OpenStreetMap<\/a><\/p> Future Work<\/h1> - Integrate temporal layer to find effective rates of encounter between pedestrians.<\/li>
- Generate daily routines to represent more realistic behavior.<\/li>
- Normalization of results to allow comparisons across sites with different total populations.<\/li> <\/ul>","link":"https:\/\/vip-smur.github.io\/24sp-mobility-seg\/?utm_source=documentation&utm_medium=RSS&utm_campaign=feed-syndication","pubDate":"Wed, 11 Mar 2026 12:46:50 +0000","source":"Surrogate Modeling for Urban Regeneration (SMUR)","comments":"https:\/\/vip-smur.github.io\/24sp-mobility-seg\/#__comments","guid":"https:\/\/vip-smur.github.io\/24sp-mobility-seg\/","enclosure":{"@attributes":{"url":"https:\/\/vip-smur.github.io\/assets\/images\/social\/24sp-mobility-seg\/README.png","type":"image\/png","length":"None"}}},{"title":"24-Sp-Mobility-PEI","description":"
Pedestrian Environment Index (PEI) Documentation<\/h1>
The Pedestrian Environment Index (PEI) is a composite measure of walkability that combines four key subindices to evaluate pedestrian-friendly environments.<\/p>
Core Subindices<\/h3> - Population Density Index (PDI)<\/strong><\/li>
- Measures residential population density within defined areas<\/li>
- Data sourced from Census block groups<\/li>
-
Implementation: PDI_generator.ipynb<\/code><\/p> <\/li> -
Commercial Density Index (CDI)<\/strong><\/p> <\/li> - Evaluates density of commercial establishments per Block Group<\/li>
- Indicates availability of walkable destinations and services<\/li>
-
Implementation: CDI_generator.ipynb<\/code><\/p> <\/li> -
Intersection Density Index (IDI)<\/strong><\/p> <\/li> - Quantifies intersection density within an area<\/li>
- Evaluates route options and pedestrian safety<\/li>
-
Implementation: IDI_generator.ipynb<\/code><\/p> <\/li> -
Land-use Diversity Index (LDI)<\/strong><\/p> <\/li> - Analyzes mix of land-use types (residential, commercial, industrial)<\/li>
- Assesses environment walkability through land use diversity<\/li>
- Implementation:
LDI_generator.ipynb<\/code><\/li> <\/ol> Implementation Workflow<\/h2> - Subindex Calculation<\/strong><\/li>
- Individual Jupyter notebooks (
*_generator.ipynb<\/code>) process Census block group shapefiles<\/li> - Each generator computes its respective subindex score<\/li>
-
Outputs saved as CSV or GeoJSON files<\/p> <\/li>
-
PEI Compilation<\/strong><\/p> <\/li> PEI_generator.ipynb<\/code> combines subindex outputs<\/li> -
Computes final PEI score for each block group<\/p> <\/li>
-
Visualization<\/strong><\/p> <\/li> - Results displayed as geographic maps<\/li>
- PEI scores visualized across census block groups<\/li> <\/ol>
Note: Project is transitioning to standardize all output files to GeoJSON format.<\/em><\/p> Detailed Index Methodologies<\/h2> Commercial Density Index (CDI)<\/h3> Overview<\/h4>
Calculates amenity counts per block group, normalized against the region's maximum commercial density.<\/p>
Input Data<\/h4> - Source:
atl_bg.geojson<\/code><\/li> - Contains Atlanta neighborhood data<\/li>
- Uses OSMNx for amenity quantification<\/li> <\/ul>
Amenity Categories<\/h4> - Groceries<\/strong>: supermarket, convenience, grocery, food, organic<\/li>
- Restaurants<\/strong>: restaurant, cafe, food_court, bistro, fast_food<\/li>
- Banks<\/strong>: bank, atm<\/li>
- Schools<\/strong>: school, college, university, kindergarten, music_school, language_school, driving_school<\/li>
- Entertainment<\/strong>: cinema, theatre, nightclub, casino, arts_centre, sports_centre, stadium, amusement_arcade, dance, bowling_alley, attraction, theme_park, zoo<\/li>
- Parks<\/strong>: recreation_ground, grass, greenfield<\/li> <\/ul>
Output<\/h4>
Normalized commercial density values relative to regional maximum<\/p>
Intersection Density Index (IDI)<\/h3> Overview<\/h4>
Analyzes intersection patterns within block groups to evaluate street connectivity.<\/p>
Input Requirements<\/h4> - GeoJSON file containing:<\/li>
- Block group geometries<\/li>
- State and county FIPS codes<\/li> <\/ul>
Output Data (CSV)<\/h4> - Polygon: Block group geometry<\/li>
- Area: Block group area<\/li>
- Intersection: Sum of intersection-connected roads<\/li>
- IDI: Normalized intersection density value<\/li> <\/ul>
Processing Steps<\/h4> - Read GeoJSON geometry data<\/li>
- Extract intersection data via OSMNx<\/li>
- Calculate equivalency factors<\/li>
- Compute population density<\/li>
- Generate visualization-ready output<\/li> <\/ol>
Land Diversity Index (LDI)<\/h3> Overview<\/h4>
Evaluates land use diversity within block groups.<\/p>
Input Requirements<\/h4> - GeoJSON file containing:<\/li>
- Block group geometries<\/li>
- State and county FIPS codes<\/li> <\/ul>
Output Data (CSV)<\/h4> - Polygon: Block group geometry<\/li>
- Land_use_dict: Land use type areas<\/li>
- Entropy: Block entropy value<\/li>
- LDI: Normalized land diversity value<\/li> <\/ul>
Processing Steps<\/h4> - Extract GeoJSON geometry<\/li>
- Gather land use data via OSMNx<\/li>
- Calculate block entropy<\/li>
- Compute land diversity<\/li>
- Prepare visualization data<\/li> <\/ol>
Population Density Index (PDI)<\/h3> Overview<\/h4>
Processes Census Bureau population data to calculate density metrics.<\/p>
Input Requirements<\/h4> - GeoDataFrame with:<\/li>
- Block group geometries<\/li>
- State\/county FIPS codes<\/li>
- Census API key (from parameter or
census_api_key.txt<\/code>)<\/li> <\/ul> Output Data (GeoDataFrame)<\/h4> - POP: Block group population<\/li>
- POPDENSITY: Persons per square kilometer<\/li>
- NORMPOPDENSITY: Normalized population density<\/li> <\/ul>
Processing Steps<\/h4> - Validate API credentials<\/li>
- Extract FIPS codes<\/li>
- Retrieve Census data<\/li>
- Integrate population data<\/li>
- Calculate density metrics<\/li>
- Clean and format output<\/li> <\/ol>
Error Handling<\/h4>
Raises ValueError if Census API key is unavailable<\/p>","link":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/?utm_source=documentation&utm_medium=RSS&utm_campaign=feed-syndication","pubDate":"Wed, 11 Mar 2026 12:46:50 +0000","source":"Surrogate Modeling for Urban Regeneration (SMUR)","comments":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/#__comments","guid":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/","enclosure":{"@attributes":{"url":"https:\/\/vip-smur.github.io\/assets\/images\/social\/24sp-mobility-pei\/README.png","type":"image\/png","length":"None"}}},{"title":"24-Fa-Microclimate-LSTM-Kriging","description":"
24Fa-Microclimate-Geo-LSTM-Kriging<\/h1>
Urban Weather Generator Deep Learning: LSTM-Kriging Model<\/p>
Description<\/h2>
This project aims to understand and reproduce data published by the National University of Singapore's (NUS) approach for microclimate prediction, the Geo-LSTM-Kriging Model. This model meshes three key layers to provide accurate microclimate predictions using local weatherstation data. The model takes together LULC data, historical data, and spatial distance information to learn from previous data and apply such learnings to present data. This combination is a novel combination of the strengths of LSTM's time series predictions and Kriging's spatial data dependencies.<\/p>
This team spent work cleaning up the open-source code from NUS to understand the model's inputs better. Having improved legibility, the adapatability of the model was clear to the team and allowed them to integrate campus-specific data. The team's work this semester was focused to replicate the NUS's model for Georgia Tech campus. The team used real weather data collected on GT campus coupled with Tech's Tree Viewer App to improve the accuracy of results for the campus. <\/p>
Requirements<\/h2> - Python<\/li>
- Pandas<\/li>
- Numpy<\/li>
- OSMNX<\/li>
- Scikit-Learn<\/li>
- Pytorch<\/li>
- Pykrige<\/li> <\/ol>
In addition this program requires that you provide a dataframe for the features you want to measure, as well as gridpoint data for the Kriging Regression. We\u2019ve provided test dataframes that you can find within the \u201cweather_station_5min\u201d and \u201cweather_station_60min\u201d folders. <\/p>
Repository Structure<\/h2>
This repo contains the aspects needed to replicate the Geo-Kriging LSTM Model. Inside the \u201cpython\u201d folder, you will find the necessary notebook files to execute it. The main ones to focus on are \u201cOrganized_Model_Eval.ipynb\u201d and \u201cosmnx 2.ipynb\u201d. The latter is used to gather the necessary gridpoint data for the kriging aspect and the former is utilized for execution of the models onto the data.<\/p>
Installation<\/h2>
Each of the required libraries can be easily installed with pip. For OSMNX, a separate process is required. You can find it at this link<\/a>. Once installed, run the \u201cosmnx 2.ipynb\u201d with the OX kernel.<\/p> Methodology<\/h2>
<\/p>
For the methodology, the team used three wokflows: pre-processing, machine learning (ML) training, & prediction and plotting. Pre-processing involves cleaning up the data and making it usable for the ML training workflow. For the spatial method that the team incorporated into the model, the OpenStreetMap Python library osmnx, and using the library, a map of Georgia Tech's campus was used as a basis. Overlayed on top of the map is system of equally spaced out points forming a grid. For each of the equidistant points, 12 distance vectors were obtained. Theses distances are from each point on the grid to the nearest centers of various variables; these various variables are buildings, libraries, parks, parking, footways, grass, fitness centers, woods, wetlands, trees on campus, and trees in Atlanta off Tech's campus. The tree data was not easily accessible through osmnx, so the team utilized Georgia Tech's Tree Viewer App for the tree location data and distances. In the Geo-LSTM-Kriging model that our team followed, Kriging is a statistical method for spacial interpolation, predicting unknown values at locations that don\u2019t have measured values by using spatial correlations. These spatial correlations, the 12 distance vectors for each x,y point, are based off of relationships between variables. Dr. Brian Stone's weather data obtained from the several weather stations he set up a year ago on Tech's campus was used as an input for pre-processing as well, and it mainly provided information on temperatures, dew point, and relative humidity. This is the data that our group tried to find out and this data will be used as a means for comparison and training the machine learning model. The weather data from Dr. Stone's weather stations were quite messy and required cleaning. The coordinates for each of the weather stations were obtained and separated into folders. Within each of the weather station files, the averages of the data columns, namely the temperatures, dew point, and relative humidities columns, were obtained. This normalization of data to a value of zero to one ensures that during training, there will not be any errors that come up when predicting new values. Each of the normalized values were then appended into a dictionary for machine learning training. Originally, our team tried to train the weather station files in one single large data set, however it was too much for a computer to handle, so splitting it up to dictionaries ensure that it was able to run very smoothly. The outputs of the pre-processing workflow are the CSV file for the grid distances and a CSV for the normalized weather station values. <\/p>
<\/p>
Using PyTorch, the team set the main target for the prediction as the temperature and main features as relative humidity and dew point. A sequence for the LSTM was created and set as default the 10 time steps. The team did not change the parameter values too much, as the team followed the documentation's recommendations. The hidden size was changed to about 8 layers and 200 epochs, which are how many iterations one wants the program to run through the training and ensures that the program is decently trained and not too overfitted. After training each of the weather station files independently, they are all appended into one single data frame to obtain the average prediction results for each of the stations.<\/p>
<\/p>
The distance vectors obtained from each of the approximately 1300 different grid points mentioned earlier were used for the actual Geo-Kriging part of the project. The model is based off the random forest regression because random forest typically works well with a lot of different types of parameters, especially if the data turns out to be non linear.<\/p>
<\/p>
The team finally fit the model with these parameters to obtain a temperature graph displaying the heat distribution of Georgia Tech's campus. <\/p>
<\/p>
Future Work<\/h2>
The team would like to run further validation studies on the model to ensure its functionality in different climates and with consistent data. As the NUS ran their model using a month's data, given steady annual temperature data, and our weather station data is inconsistent, the model should be continute to be validated before considered for further application.<\/p>
To enhance the robustness and applicability of the LSTM-Kriging Model for urban weather generation, the following future developments are proposed: 1. Accuracy Validation<\/p>
A critical next step is to rigorously test the accuracy of the model under various scenarios. Comparative analysis with existing models and observations will help assess the reliability and identify potential areas for refinement, including:<\/p>
\u2022 Assessing the model's predictions across various time scales, such as hourly, daily, and seasonal trends, to identify performance consistency over short- and long-term periods. <\/p>
\u2022 Performing a detailed breakdown of prediction errors to uncover biases or patterns associated with specific weather variables (temperature, humidity, wind speed) and urban contexts.<\/p>
- Handling Missing Data<\/li> <\/ol>
Addressing missing data in weather and spatial datasets remains a key challenge. Future work will focus on integrating advanced imputation techniques or machine learning methods to fill data gaps effectively without compromising the model's performance, including:<\/p>
\u2022 Using diffusion models to reconstruct missing data patterns.<\/p>
- Generalizability Testing<\/li> <\/ol>
The model will be tested on additional university campuses with contexts similar to Georgia Tech, particularly those featuring comparable weather station setups and spatial characteristics. This will help evaluate the model's adaptability to different urban microclimates and provide insights for broader applications. <\/p>
Reference<\/h2>
Jintong Han, Adrian Chong, Joie Lim, Savitha Ramasamy, Nyuk Hien Wong, Filip Biljecki, (2024). Microclimate spatio-temporal prediction using deep learning and land use data. Building and Environment. https:\/\/doi.org\/10.1016\/j.buildenv.2024.111358<\/a><\/p> Presentation<\/h2>
Conclusions<\/h2>
This notebook serves as a detailed example of using methods within provided data and activity spaces to calculate segregation values for a 15-minute city. The methodologies outlined here can be adapted and expanded for other types of assessment for pedestrian mobility and accessibility.<\/p>
References<\/h2> - Abbiasov, et al. (2024) The 15-minute city quantified using human mobility data.<\/li>
- Patterson & Farber (2015) Potential Path Areas and Activity Spaces in Application: A Review<\/li>
- Sch\u00f6nfelder (2002) Measuring the size and structure of human activity spaces: The longitudinal perspective.<\/li> <\/ul>
Itinero<\/h1> Overview<\/h2>
Itinero is a flexible open-source routing engine for a variety of transportation modes such as walking, cycling, and driving. It provides sophisticated tools to integrate customizable routing solutions into their applications, enabling efficient navigation. Itinero emphasizes versatility, offering support for various map data formats and allowing customization to suit specific needs. Most importantly, features like offline routing and routing across multiple transportation modes are provided. For the sake of this project, the pedestrian shortest path profile is utilized to calculate and map routes for individuals within the city.<\/p>
Repository<\/h2>
Itinero Routing<\/a><\/p> Features<\/h2> - Routing<\/strong>: The Router uses the RouterDb data to calculate routes for a given Profile. It starts and ends the Route at a RouterPoint.<\/li>
- RouterDb: Contains the routing network, all meta-data, restrictions and so on.<\/li>
- Profile: Defines vehicles and their behaviour.<\/li>
- RouterPoint: A location on the routing network to use as a start or endpoint of a route.<\/li>
- Router: The router is where you ask for routes.<\/li>
- GeoJSON Conversion<\/strong>: Export calculated routing to GeoJSON for use in mapping and other geospatial applications.<\/li>
- Open Street Maps Data Retrieval<\/strong>: Automatically download street and building data required for demand calculations.<\/li> <\/ul>
Getting Started<\/h2>
To start using Itinero, follow these steps: 1. Install following Itinero packages to .NET project: - Itinero: The Itinero routing core, this is usually the only package you need to install. - Itinero.Geo: This package ensures compatibility with NTS. - Itinero.IO.Osm: This package contains code to load OSM data. - Itinero.IO.Shape: This package contains code to load data from shapefiles. 2. Specify OSM file as needed 3. Run project through determined routing coordinates<\/p>
Data Requirements<\/h2> - Street data should include both OSM or FEMA tag attributes for project defined amenities and places of work<\/li>
- Open Street Maps (OSM): amenities and workplaces<\/li>
- Federal Emergency Management Agency (FEMA): residentials<\/li> <\/ul>
Credits<\/h2>
Itinero<\/a> is open-source and commercially supported, developed by the Itinero BVBA team. Itinero was built using OpenStreetMap<\/a><\/p> Future Work<\/h1> - Integrate temporal layer to find effective rates of encounter between pedestrians.<\/li>
- Generate daily routines to represent more realistic behavior.<\/li>
- Normalization of results to allow comparisons across sites with different total populations.<\/li> <\/ul>","link":"https:\/\/vip-smur.github.io\/24sp-mobility-seg\/?utm_source=documentation&utm_medium=RSS&utm_campaign=feed-syndication","pubDate":"Wed, 11 Mar 2026 12:46:50 +0000","source":"Surrogate Modeling for Urban Regeneration (SMUR)","comments":"https:\/\/vip-smur.github.io\/24sp-mobility-seg\/#__comments","guid":"https:\/\/vip-smur.github.io\/24sp-mobility-seg\/","enclosure":{"@attributes":{"url":"https:\/\/vip-smur.github.io\/assets\/images\/social\/24sp-mobility-seg\/README.png","type":"image\/png","length":"None"}}},{"title":"24-Sp-Mobility-PEI","description":"
Pedestrian Environment Index (PEI) Documentation<\/h1>
The Pedestrian Environment Index (PEI) is a composite measure of walkability that combines four key subindices to evaluate pedestrian-friendly environments.<\/p>
Core Subindices<\/h3> - Population Density Index (PDI)<\/strong><\/li>
- Measures residential population density within defined areas<\/li>
- Data sourced from Census block groups<\/li>
-
Implementation: PDI_generator.ipynb<\/code><\/p> <\/li> -
Commercial Density Index (CDI)<\/strong><\/p> <\/li> - Evaluates density of commercial establishments per Block Group<\/li>
- Indicates availability of walkable destinations and services<\/li>
-
Implementation: CDI_generator.ipynb<\/code><\/p> <\/li> -
Intersection Density Index (IDI)<\/strong><\/p> <\/li> - Quantifies intersection density within an area<\/li>
- Evaluates route options and pedestrian safety<\/li>
-
Implementation: IDI_generator.ipynb<\/code><\/p> <\/li> -
Land-use Diversity Index (LDI)<\/strong><\/p> <\/li> - Analyzes mix of land-use types (residential, commercial, industrial)<\/li>
- Assesses environment walkability through land use diversity<\/li>
- Implementation:
LDI_generator.ipynb<\/code><\/li> <\/ol> Implementation Workflow<\/h2> - Subindex Calculation<\/strong><\/li>
- Individual Jupyter notebooks (
*_generator.ipynb<\/code>) process Census block group shapefiles<\/li> - Each generator computes its respective subindex score<\/li>
-
Outputs saved as CSV or GeoJSON files<\/p> <\/li>
-
PEI Compilation<\/strong><\/p> <\/li> PEI_generator.ipynb<\/code> combines subindex outputs<\/li> -
Computes final PEI score for each block group<\/p> <\/li>
-
Visualization<\/strong><\/p> <\/li> - Results displayed as geographic maps<\/li>
- PEI scores visualized across census block groups<\/li> <\/ol>
Note: Project is transitioning to standardize all output files to GeoJSON format.<\/em><\/p> Detailed Index Methodologies<\/h2> Commercial Density Index (CDI)<\/h3> Overview<\/h4>
Calculates amenity counts per block group, normalized against the region's maximum commercial density.<\/p>
Input Data<\/h4> - Source:
atl_bg.geojson<\/code><\/li> - Contains Atlanta neighborhood data<\/li>
- Uses OSMNx for amenity quantification<\/li> <\/ul>
Amenity Categories<\/h4> - Groceries<\/strong>: supermarket, convenience, grocery, food, organic<\/li>
- Restaurants<\/strong>: restaurant, cafe, food_court, bistro, fast_food<\/li>
- Banks<\/strong>: bank, atm<\/li>
- Schools<\/strong>: school, college, university, kindergarten, music_school, language_school, driving_school<\/li>
- Entertainment<\/strong>: cinema, theatre, nightclub, casino, arts_centre, sports_centre, stadium, amusement_arcade, dance, bowling_alley, attraction, theme_park, zoo<\/li>
- Parks<\/strong>: recreation_ground, grass, greenfield<\/li> <\/ul>
Output<\/h4>
Normalized commercial density values relative to regional maximum<\/p>
Intersection Density Index (IDI)<\/h3> Overview<\/h4>
Analyzes intersection patterns within block groups to evaluate street connectivity.<\/p>
Input Requirements<\/h4> - GeoJSON file containing:<\/li>
- Block group geometries<\/li>
- State and county FIPS codes<\/li> <\/ul>
Output Data (CSV)<\/h4> - Polygon: Block group geometry<\/li>
- Area: Block group area<\/li>
- Intersection: Sum of intersection-connected roads<\/li>
- IDI: Normalized intersection density value<\/li> <\/ul>
Processing Steps<\/h4> - Read GeoJSON geometry data<\/li>
- Extract intersection data via OSMNx<\/li>
- Calculate equivalency factors<\/li>
- Compute population density<\/li>
- Generate visualization-ready output<\/li> <\/ol>
Land Diversity Index (LDI)<\/h3> Overview<\/h4>
Evaluates land use diversity within block groups.<\/p>
Input Requirements<\/h4> - GeoJSON file containing:<\/li>
- Block group geometries<\/li>
- State and county FIPS codes<\/li> <\/ul>
Output Data (CSV)<\/h4> - Polygon: Block group geometry<\/li>
- Land_use_dict: Land use type areas<\/li>
- Entropy: Block entropy value<\/li>
- LDI: Normalized land diversity value<\/li> <\/ul>
Processing Steps<\/h4> - Extract GeoJSON geometry<\/li>
- Gather land use data via OSMNx<\/li>
- Calculate block entropy<\/li>
- Compute land diversity<\/li>
- Prepare visualization data<\/li> <\/ol>
Population Density Index (PDI)<\/h3> Overview<\/h4>
Processes Census Bureau population data to calculate density metrics.<\/p>
Input Requirements<\/h4> - GeoDataFrame with:<\/li>
- Block group geometries<\/li>
- State\/county FIPS codes<\/li>
- Census API key (from parameter or
census_api_key.txt<\/code>)<\/li> <\/ul> Output Data (GeoDataFrame)<\/h4> - POP: Block group population<\/li>
- POPDENSITY: Persons per square kilometer<\/li>
- NORMPOPDENSITY: Normalized population density<\/li> <\/ul>
Processing Steps<\/h4> - Validate API credentials<\/li>
- Extract FIPS codes<\/li>
- Retrieve Census data<\/li>
- Integrate population data<\/li>
- Calculate density metrics<\/li>
- Clean and format output<\/li> <\/ol>
Error Handling<\/h4>
Raises ValueError if Census API key is unavailable<\/p>","link":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/?utm_source=documentation&utm_medium=RSS&utm_campaign=feed-syndication","pubDate":"Wed, 11 Mar 2026 12:46:50 +0000","source":"Surrogate Modeling for Urban Regeneration (SMUR)","comments":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/#__comments","guid":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/","enclosure":{"@attributes":{"url":"https:\/\/vip-smur.github.io\/assets\/images\/social\/24sp-mobility-pei\/README.png","type":"image\/png","length":"None"}}},{"title":"24-Fa-Microclimate-LSTM-Kriging","description":"
24Fa-Microclimate-Geo-LSTM-Kriging<\/h1>
Urban Weather Generator Deep Learning: LSTM-Kriging Model<\/p>
Description<\/h2>
This project aims to understand and reproduce data published by the National University of Singapore's (NUS) approach for microclimate prediction, the Geo-LSTM-Kriging Model. This model meshes three key layers to provide accurate microclimate predictions using local weatherstation data. The model takes together LULC data, historical data, and spatial distance information to learn from previous data and apply such learnings to present data. This combination is a novel combination of the strengths of LSTM's time series predictions and Kriging's spatial data dependencies.<\/p>
This team spent work cleaning up the open-source code from NUS to understand the model's inputs better. Having improved legibility, the adapatability of the model was clear to the team and allowed them to integrate campus-specific data. The team's work this semester was focused to replicate the NUS's model for Georgia Tech campus. The team used real weather data collected on GT campus coupled with Tech's Tree Viewer App to improve the accuracy of results for the campus. <\/p>
Requirements<\/h2> - Python<\/li>
- Pandas<\/li>
- Numpy<\/li>
- OSMNX<\/li>
- Scikit-Learn<\/li>
- Pytorch<\/li>
- Pykrige<\/li> <\/ol>
In addition this program requires that you provide a dataframe for the features you want to measure, as well as gridpoint data for the Kriging Regression. We\u2019ve provided test dataframes that you can find within the \u201cweather_station_5min\u201d and \u201cweather_station_60min\u201d folders. <\/p>
Repository Structure<\/h2>
This repo contains the aspects needed to replicate the Geo-Kriging LSTM Model. Inside the \u201cpython\u201d folder, you will find the necessary notebook files to execute it. The main ones to focus on are \u201cOrganized_Model_Eval.ipynb\u201d and \u201cosmnx 2.ipynb\u201d. The latter is used to gather the necessary gridpoint data for the kriging aspect and the former is utilized for execution of the models onto the data.<\/p>
Installation<\/h2>
Each of the required libraries can be easily installed with pip. For OSMNX, a separate process is required. You can find it at this link<\/a>. Once installed, run the \u201cosmnx 2.ipynb\u201d with the OX kernel.<\/p> Methodology<\/h2>
<\/p>
For the methodology, the team used three wokflows: pre-processing, machine learning (ML) training, & prediction and plotting. Pre-processing involves cleaning up the data and making it usable for the ML training workflow. For the spatial method that the team incorporated into the model, the OpenStreetMap Python library osmnx, and using the library, a map of Georgia Tech's campus was used as a basis. Overlayed on top of the map is system of equally spaced out points forming a grid. For each of the equidistant points, 12 distance vectors were obtained. Theses distances are from each point on the grid to the nearest centers of various variables; these various variables are buildings, libraries, parks, parking, footways, grass, fitness centers, woods, wetlands, trees on campus, and trees in Atlanta off Tech's campus. The tree data was not easily accessible through osmnx, so the team utilized Georgia Tech's Tree Viewer App for the tree location data and distances. In the Geo-LSTM-Kriging model that our team followed, Kriging is a statistical method for spacial interpolation, predicting unknown values at locations that don\u2019t have measured values by using spatial correlations. These spatial correlations, the 12 distance vectors for each x,y point, are based off of relationships between variables. Dr. Brian Stone's weather data obtained from the several weather stations he set up a year ago on Tech's campus was used as an input for pre-processing as well, and it mainly provided information on temperatures, dew point, and relative humidity. This is the data that our group tried to find out and this data will be used as a means for comparison and training the machine learning model. The weather data from Dr. Stone's weather stations were quite messy and required cleaning. The coordinates for each of the weather stations were obtained and separated into folders. Within each of the weather station files, the averages of the data columns, namely the temperatures, dew point, and relative humidities columns, were obtained. This normalization of data to a value of zero to one ensures that during training, there will not be any errors that come up when predicting new values. Each of the normalized values were then appended into a dictionary for machine learning training. Originally, our team tried to train the weather station files in one single large data set, however it was too much for a computer to handle, so splitting it up to dictionaries ensure that it was able to run very smoothly. The outputs of the pre-processing workflow are the CSV file for the grid distances and a CSV for the normalized weather station values. <\/p>
<\/p>
Using PyTorch, the team set the main target for the prediction as the temperature and main features as relative humidity and dew point. A sequence for the LSTM was created and set as default the 10 time steps. The team did not change the parameter values too much, as the team followed the documentation's recommendations. The hidden size was changed to about 8 layers and 200 epochs, which are how many iterations one wants the program to run through the training and ensures that the program is decently trained and not too overfitted. After training each of the weather station files independently, they are all appended into one single data frame to obtain the average prediction results for each of the stations.<\/p>
<\/p>
The distance vectors obtained from each of the approximately 1300 different grid points mentioned earlier were used for the actual Geo-Kriging part of the project. The model is based off the random forest regression because random forest typically works well with a lot of different types of parameters, especially if the data turns out to be non linear.<\/p>
<\/p>
The team finally fit the model with these parameters to obtain a temperature graph displaying the heat distribution of Georgia Tech's campus. <\/p>
<\/p>
Future Work<\/h2>
The team would like to run further validation studies on the model to ensure its functionality in different climates and with consistent data. As the NUS ran their model using a month's data, given steady annual temperature data, and our weather station data is inconsistent, the model should be continute to be validated before considered for further application.<\/p>
To enhance the robustness and applicability of the LSTM-Kriging Model for urban weather generation, the following future developments are proposed: 1. Accuracy Validation<\/p>
A critical next step is to rigorously test the accuracy of the model under various scenarios. Comparative analysis with existing models and observations will help assess the reliability and identify potential areas for refinement, including:<\/p>
\u2022 Assessing the model's predictions across various time scales, such as hourly, daily, and seasonal trends, to identify performance consistency over short- and long-term periods. <\/p>
\u2022 Performing a detailed breakdown of prediction errors to uncover biases or patterns associated with specific weather variables (temperature, humidity, wind speed) and urban contexts.<\/p>
- Handling Missing Data<\/li> <\/ol>
Addressing missing data in weather and spatial datasets remains a key challenge. Future work will focus on integrating advanced imputation techniques or machine learning methods to fill data gaps effectively without compromising the model's performance, including:<\/p>
\u2022 Using diffusion models to reconstruct missing data patterns.<\/p>
- Generalizability Testing<\/li> <\/ol>
The model will be tested on additional university campuses with contexts similar to Georgia Tech, particularly those featuring comparable weather station setups and spatial characteristics. This will help evaluate the model's adaptability to different urban microclimates and provide insights for broader applications. <\/p>
Reference<\/h2>
Jintong Han, Adrian Chong, Joie Lim, Savitha Ramasamy, Nyuk Hien Wong, Filip Biljecki, (2024). Microclimate spatio-temporal prediction using deep learning and land use data. Building and Environment. https:\/\/doi.org\/10.1016\/j.buildenv.2024.111358<\/a><\/p> Presentation<\/h2>
Itinero<\/h1> Overview<\/h2>
Itinero is a flexible open-source routing engine for a variety of transportation modes such as walking, cycling, and driving. It provides sophisticated tools to integrate customizable routing solutions into their applications, enabling efficient navigation. Itinero emphasizes versatility, offering support for various map data formats and allowing customization to suit specific needs. Most importantly, features like offline routing and routing across multiple transportation modes are provided. For the sake of this project, the pedestrian shortest path profile is utilized to calculate and map routes for individuals within the city.<\/p>
Repository<\/h2>
Itinero Routing<\/a><\/p> To start using Itinero, follow these steps: 1. Install following Itinero packages to .NET project: - Itinero: The Itinero routing core, this is usually the only package you need to install. - Itinero.Geo: This package ensures compatibility with NTS. - Itinero.IO.Osm: This package contains code to load OSM data. - Itinero.IO.Shape: This package contains code to load data from shapefiles. 2. Specify OSM file as needed 3. Run project through determined routing coordinates<\/p> Itinero<\/a> is open-source and commercially supported, developed by the Itinero BVBA team. Itinero was built using OpenStreetMap<\/a><\/p> The Pedestrian Environment Index (PEI) is a composite measure of walkability that combines four key subindices to evaluate pedestrian-friendly environments.<\/p> Implementation: Commercial Density Index (CDI)<\/strong><\/p> <\/li> Implementation: Intersection Density Index (IDI)<\/strong><\/p> <\/li> Implementation: Land-use Diversity Index (LDI)<\/strong><\/p> <\/li> Outputs saved as CSV or GeoJSON files<\/p> <\/li> PEI Compilation<\/strong><\/p> <\/li> Computes final PEI score for each block group<\/p> <\/li> Visualization<\/strong><\/p> <\/li> Note: Project is transitioning to standardize all output files to GeoJSON format.<\/em><\/p> Calculates amenity counts per block group, normalized against the region's maximum commercial density.<\/p> Normalized commercial density values relative to regional maximum<\/p> Analyzes intersection patterns within block groups to evaluate street connectivity.<\/p> Evaluates land use diversity within block groups.<\/p> Processes Census Bureau population data to calculate density metrics.<\/p> Raises ValueError if Census API key is unavailable<\/p>","link":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/?utm_source=documentation&utm_medium=RSS&utm_campaign=feed-syndication","pubDate":"Wed, 11 Mar 2026 12:46:50 +0000","source":"Surrogate Modeling for Urban Regeneration (SMUR)","comments":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/#__comments","guid":"https:\/\/vip-smur.github.io\/24sp-mobility-pei\/","enclosure":{"@attributes":{"url":"https:\/\/vip-smur.github.io\/assets\/images\/social\/24sp-mobility-pei\/README.png","type":"image\/png","length":"None"}}},{"title":"24-Fa-Microclimate-LSTM-Kriging","description":" Urban Weather Generator Deep Learning: LSTM-Kriging Model<\/p> This project aims to understand and reproduce data published by the National University of Singapore's (NUS) approach for microclimate prediction, the Geo-LSTM-Kriging Model. This model meshes three key layers to provide accurate microclimate predictions using local weatherstation data. The model takes together LULC data, historical data, and spatial distance information to learn from previous data and apply such learnings to present data. This combination is a novel combination of the strengths of LSTM's time series predictions and Kriging's spatial data dependencies.<\/p> This team spent work cleaning up the open-source code from NUS to understand the model's inputs better. Having improved legibility, the adapatability of the model was clear to the team and allowed them to integrate campus-specific data. The team's work this semester was focused to replicate the NUS's model for Georgia Tech campus. The team used real weather data collected on GT campus coupled with Tech's Tree Viewer App to improve the accuracy of results for the campus. <\/p> In addition this program requires that you provide a dataframe for the features you want to measure, as well as gridpoint data for the Kriging Regression. We\u2019ve provided test dataframes that you can find within the \u201cweather_station_5min\u201d and \u201cweather_station_60min\u201d folders. <\/p> This repo contains the aspects needed to replicate the Geo-Kriging LSTM Model. Inside the \u201cpython\u201d folder, you will find the necessary notebook files to execute it. The main ones to focus on are \u201cOrganized_Model_Eval.ipynb\u201d and \u201cosmnx 2.ipynb\u201d. The latter is used to gather the necessary gridpoint data for the kriging aspect and the former is utilized for execution of the models onto the data.<\/p> Each of the required libraries can be easily installed with pip. For OSMNX, a separate process is required. You can find it at this link<\/a>. Once installed, run the \u201cosmnx 2.ipynb\u201d with the OX kernel.<\/p> For the methodology, the team used three wokflows: pre-processing, machine learning (ML) training, & prediction and plotting. Pre-processing involves cleaning up the data and making it usable for the ML training workflow. For the spatial method that the team incorporated into the model, the OpenStreetMap Python library osmnx, and using the library, a map of Georgia Tech's campus was used as a basis. Overlayed on top of the map is system of equally spaced out points forming a grid. For each of the equidistant points, 12 distance vectors were obtained. Theses distances are from each point on the grid to the nearest centers of various variables; these various variables are buildings, libraries, parks, parking, footways, grass, fitness centers, woods, wetlands, trees on campus, and trees in Atlanta off Tech's campus. The tree data was not easily accessible through osmnx, so the team utilized Georgia Tech's Tree Viewer App for the tree location data and distances. In the Geo-LSTM-Kriging model that our team followed, Kriging is a statistical method for spacial interpolation, predicting unknown values at locations that don\u2019t have measured values by using spatial correlations. These spatial correlations, the 12 distance vectors for each x,y point, are based off of relationships between variables. Dr. Brian Stone's weather data obtained from the several weather stations he set up a year ago on Tech's campus was used as an input for pre-processing as well, and it mainly provided information on temperatures, dew point, and relative humidity. This is the data that our group tried to find out and this data will be used as a means for comparison and training the machine learning model. The weather data from Dr. Stone's weather stations were quite messy and required cleaning. The coordinates for each of the weather stations were obtained and separated into folders. Within each of the weather station files, the averages of the data columns, namely the temperatures, dew point, and relative humidities columns, were obtained. This normalization of data to a value of zero to one ensures that during training, there will not be any errors that come up when predicting new values. Each of the normalized values were then appended into a dictionary for machine learning training. Originally, our team tried to train the weather station files in one single large data set, however it was too much for a computer to handle, so splitting it up to dictionaries ensure that it was able to run very smoothly. The outputs of the pre-processing workflow are the CSV file for the grid distances and a CSV for the normalized weather station values. <\/p> Using PyTorch, the team set the main target for the prediction as the temperature and main features as relative humidity and dew point. A sequence for the LSTM was created and set as default the 10 time steps. The team did not change the parameter values too much, as the team followed the documentation's recommendations. The hidden size was changed to about 8 layers and 200 epochs, which are how many iterations one wants the program to run through the training and ensures that the program is decently trained and not too overfitted. After training each of the weather station files independently, they are all appended into one single data frame to obtain the average prediction results for each of the stations.<\/p> The distance vectors obtained from each of the approximately 1300 different grid points mentioned earlier were used for the actual Geo-Kriging part of the project. The model is based off the random forest regression because random forest typically works well with a lot of different types of parameters, especially if the data turns out to be non linear.<\/p> The team finally fit the model with these parameters to obtain a temperature graph displaying the heat distribution of Georgia Tech's campus. <\/p> The team would like to run further validation studies on the model to ensure its functionality in different climates and with consistent data. As the NUS ran their model using a month's data, given steady annual temperature data, and our weather station data is inconsistent, the model should be continute to be validated before considered for further application.<\/p> To enhance the robustness and applicability of the LSTM-Kriging Model for urban weather generation, the following future developments are proposed: 1. Accuracy Validation<\/p> A critical next step is to rigorously test the accuracy of the model under various scenarios. Comparative analysis with existing models and observations will help assess the reliability and identify potential areas for refinement, including:<\/p> \u2022 Assessing the model's predictions across various time scales, such as hourly, daily, and seasonal trends, to identify performance consistency over short- and long-term periods. <\/p> \u2022 Performing a detailed breakdown of prediction errors to uncover biases or patterns associated with specific weather variables (temperature, humidity, wind speed) and urban contexts.<\/p> Addressing missing data in weather and spatial datasets remains a key challenge. Future work will focus on integrating advanced imputation techniques or machine learning methods to fill data gaps effectively without compromising the model's performance, including:<\/p> \u2022 Using diffusion models to reconstruct missing data patterns.<\/p> The model will be tested on additional university campuses with contexts similar to Georgia Tech, particularly those featuring comparable weather station setups and spatial characteristics. This will help evaluate the model's adaptability to different urban microclimates and provide insights for broader applications. <\/p> Jintong Han, Adrian Chong, Joie Lim, Savitha Ramasamy, Nyuk Hien Wong, Filip Biljecki, (2024). Microclimate spatio-temporal prediction using deep learning and land use data. Building and Environment. https:\/\/doi.org\/10.1016\/j.buildenv.2024.111358<\/a><\/p> Features<\/h2>
Getting Started<\/h2>
Data Requirements<\/h2>
Credits<\/h2>
Future Work<\/h1>
Pedestrian Environment Index (PEI) Documentation<\/h1>
Core Subindices<\/h3>
PDI_generator.ipynb<\/code><\/p> <\/li> CDI_generator.ipynb<\/code><\/p> <\/li> IDI_generator.ipynb<\/code><\/p> <\/li> LDI_generator.ipynb<\/code><\/li> <\/ol> Implementation Workflow<\/h2>
*_generator.ipynb<\/code>) process Census block group shapefiles<\/li> PEI_generator.ipynb<\/code> combines subindex outputs<\/li> Detailed Index Methodologies<\/h2>
Commercial Density Index (CDI)<\/h3>
Overview<\/h4>
Input Data<\/h4>
atl_bg.geojson<\/code><\/li> Amenity Categories<\/h4>
Output<\/h4>
Intersection Density Index (IDI)<\/h3>
Overview<\/h4>
Input Requirements<\/h4>
Output Data (CSV)<\/h4>
Processing Steps<\/h4>
Land Diversity Index (LDI)<\/h3>
Overview<\/h4>
Input Requirements<\/h4>
Output Data (CSV)<\/h4>
Processing Steps<\/h4>
Population Density Index (PDI)<\/h3>
Overview<\/h4>
Input Requirements<\/h4>
census_api_key.txt<\/code>)<\/li> <\/ul> Output Data (GeoDataFrame)<\/h4>
Processing Steps<\/h4>
Error Handling<\/h4>
24Fa-Microclimate-Geo-LSTM-Kriging<\/h1>
Description<\/h2>
Requirements<\/h2>
Repository Structure<\/h2>
Installation<\/h2>
Methodology<\/h2>
<\/p> <\/p> <\/p> <\/p> <\/p> Future Work<\/h2>
Reference<\/h2>
Presentation<\/h2>
![\"Final](\"https:\/\/img.youtube.com\/vi\/deMabiRxBAA\/maxresdefault.jpg\")
<\/a><\/p>