import geopandas as gpd
import pandas as pd
import geosnap
geosnap.__version__'0.14.0'
geosnap - the geospatial neighborhood analysis package - provides a suite of tools for understanding the composition and extent of [endogenous] neighborhoods and regions in a study area. It provides:
Today, we want to focus on getting data from geosnap. This involves two basic steps: instantiate a DataStore class which points to datasets installed on the 385 course server, then querying the new DataStore object using functions from the geosnap io (for input-ouput) module
All of the datasets available in geosnap can be streamed from the cloud or installed on a local machine for analysis. In many cases, streaming works fine, but for repeated use of the same datasets, it is easier to install the data permanently. We have already done that on the course server. To ensure geosnap can access that data, we instantiate a new DataStore object pointing to the location of the data
The datasets object can now be used to read and write data from the "/srv/data/geosnap/" folder, which is where the course data lives).
As a quick shorthand to see the available datasets, you can use the dir function to peek inside the datasets object
['acs',
'bea_regions',
'blocks_2000',
'blocks_2010',
'blocks_2020',
'codebook',
'counties',
'ejscreen',
'lodes_codebook',
'ltdb',
'msa_definitions',
'msas',
'ncdb',
'nces',
'seda',
'show_data_dir',
'states',
'tracts_1990',
'tracts_2000',
'tracts_2010',
'tracts_2020']
Each of these is a dataset that can be accessed. For more information on the datasets, see the geosnap datasets page.
As one example, we can collect data from the U.S. Census American Community Survey (5-year survey estimates) using the get_acs function in geosnap’s io module.
First we import the io module, aliased as gio, then we query the DataStore (called datasets) for ACS data at the tract level for state 06 (which is California) and year 2016 (which is the 2012-2016 ACS).
from geosnap.io import get_acs
ca = get_acs(datasets, state_fips=['06'], level='tract', years=[2016])/home/serge/miniforge3/envs/workshop-pysal/lib/python3.10/site-packages/geosnap/_data.py:16: UserWarning: Streaming data from S3. Use `geosnap.io.store_acs()` to store the data locally for better performance
warn(warning_msg)
The ca variable now holds a geodataframe of California census data at the tract level. To get a different year or a different geographic level, we could specify different input parameters to the get_acs function
| geoid | n_mexican_pop | n_cuban_pop | n_puerto_rican_pop | n_russian_pop | n_italian_pop | n_german_pop | n_irish_pop | n_scandaniavian_pop | n_foreign_born_pop | ... | p_poverty_rate | p_poverty_rate_over_65 | p_poverty_rate_children | p_poverty_rate_white | p_poverty_rate_black | p_poverty_rate_hispanic | p_poverty_rate_native | p_poverty_rate_asian | geometry | year | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 06001400100 | 55.0 | 0.0 | 13.0 | 49.0 | 62.0 | 147.0 | 13.0 | 8.0 | 843.0 | ... | 3.752906 | 0.531385 | 0.631020 | 3.055463 | 0.000000 | 0.000000 | 0.0 | 0.000000 | MULTIPOLYGON (((-122.24692 37.88544, -122.2466... | 2016 |
| 1 | 06001400200 | 118.0 | 0.0 | 25.0 | 17.0 | 39.0 | 57.0 | 26.0 | 6.0 | 243.0 | ... | 5.430328 | 1.946721 | 0.000000 | 4.047131 | 0.000000 | 0.563525 | 0.0 | 0.000000 | MULTIPOLYGON (((-122.25792 37.84261, -122.2577... | 2016 |
| 2 | 06001400300 | 171.0 | 0.0 | 0.0 | 0.0 | 154.0 | 81.0 | 75.0 | 0.0 | 857.0 | ... | 8.732777 | 1.765962 | 0.329905 | 3.299049 | 3.648360 | 0.426936 | 0.0 | 0.000000 | MULTIPOLYGON (((-122.26563 37.83764, -122.2655... | 2016 |
| 3 | 06001400400 | 127.0 | 9.0 | 0.0 | 56.0 | 55.0 | 84.0 | 37.0 | 0.0 | 471.0 | ... | 6.445406 | 0.721501 | 0.000000 | 3.799904 | 0.673401 | 0.553151 | 0.0 | 0.000000 | MULTIPOLYGON (((-122.26183 37.84162, -122.2618... | 2016 |
| 4 | 06001400500 | 282.0 | 29.0 | 11.0 | 10.0 | 7.0 | 103.0 | 51.0 | 0.0 | 635.0 | ... | 9.081168 | 0.375033 | 0.000000 | 4.178945 | 3.375301 | 3.402089 | 0.0 | 0.642915 | MULTIPOLYGON (((-122.26951 37.84858, -122.2693... | 2016 |
5 rows × 158 columns
To trim down the existing dataset, for example to “slice out” the tracts in San Diego county, we use pandas dataframe operations. Here we use the geoid column to select tracts that begin with “06073”, which is the county FIPS code for San Diego
The Environmental Protection Agency (EPA)’s envrironmental justice screening tool (EJSCREEN) is a national dataset that provides a wealth of environmental (and some demographic) data at a blockgroup level. For a full list of indicators and their metadata, see the EPA page, but this dataset includes important variables like air toxics cancer risk,ozone concentration in the air, particulate matter, and proximity to superfund sites.
The EJSCREEN data can be queried similarly to the ACS data. For example to get blockgroup-level data for the Seattle metropolitan region in 2019, we would use the following
/home/serge/miniforge3/envs/workshop-pysal/lib/python3.10/site-packages/geosnap/_data.py:16: UserWarning: Streaming data from S3. Use `geosnap.io.store_ejscreen()` to store the data locally for better performance
warn(warning_msg)
A description of the variables in the EJSCREEN data is available here. A subset of the interesting variables we might examine is provided in the table below
| Variable | Description |
|---|---|
| DSLPM | Diesel particulate matter level in air |
| CANCER | Air toxics cancer risk |
| RESP | Air toxics respiratory hazard index |
| PTRAF | Traffic proximity and volume |
| PWDIS | Indicator for major direct dischargers to water |
| PNPL | Proximity to National Priorities List (NPL) sites |
| PRMP | Proximity to Risk Management Plan (RMP) facilities |
| PTSDF | Proximity to Treatment Storage and Disposal (TSDF) facilities |
| OZONE | Ozone level in air |
| PM25 | PM2.5 level in air |
Once a dataset is selected, we often need to perform more transformations and data operations than can be performed via table operations. That is, we often want to use the spatial information stored in each observation as a way of transforming, subsetting, aggregating, or otherwise manipulating the data.
These kinds of operations that rely on geospatial information are often called geoprocessing operations, and in this notebook we cover a subset of geoprocessing methods:
| geoid | ACSTOTPOP | ACSIPOVBAS | ACSEDUCBAS | ACSTOTHH | ACSTOTHU | MINORPOP | MINORPCT | LOWINCOME | LOWINCPCT | ... | T_PM25_P2 | T_PM25_P6 | AREALAND | AREAWATER | NPL_CNT | TSDF_CNT | Shape_Length | Shape_Area | geometry | year | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 530330001001 | 1265 | 1235 | 1095 | 608 | 608 | 155 | 0.122530 | 136 | 0.110121 | ... | 7%ile | 12%ile | 892826.0 | 904304.0 | 0 | 0 | 8633.745188 | 3.969193e+06 | MULTIPOLYGON (((-122.28977 47.73374, -122.2884... | 2019 |
| 1 | 530330001002 | 1534 | 1527 | 1210 | 758 | 871 | 765 | 0.498696 | 558 | 0.365422 | ... | 54%ile | 54%ile | 288190.0 | 0.0 | 0 | 0 | 3940.705233 | 6.365748e+05 | MULTIPOLYGON (((-122.29654 47.73015, -122.2952... | 2019 |
| 2 | 530330001003 | 1817 | 1817 | 1263 | 724 | 738 | 731 | 0.402312 | 543 | 0.298844 | ... | 44%ile | 28%ile | 370737.0 | 0.0 | 0 | 0 | 3878.874929 | 8.187073e+05 | MULTIPOLYGON (((-122.29321 47.72291, -122.2929... | 2019 |
| 3 | 530330001004 | 2270 | 2270 | 1332 | 1052 | 1134 | 1622 | 0.714537 | 1283 | 0.565198 | ... | 71%ile | 67%ile | 126662.0 | 0.0 | 0 | 0 | 2128.066919 | 2.798096e+05 | MULTIPOLYGON (((-122.29656 47.73198, -122.2965... | 2019 |
| 4 | 530330001005 | 1077 | 1077 | 808 | 637 | 679 | 393 | 0.364903 | 314 | 0.291551 | ... | 41%ile | 41%ile | 230515.0 | 0.0 | 0 | 0 | 3376.927631 | 5.090533e+05 | MULTIPOLYGON (((-122.29642 47.72651, -122.2946... | 2019 |
5 rows × 368 columns
This dataset has 2,483 observations (rows) and 368 attributes (columns)
Index(['geoid', 'ACSTOTPOP', 'ACSIPOVBAS', 'ACSEDUCBAS', 'ACSTOTHH',
'ACSTOTHU', 'MINORPOP', 'MINORPCT', 'LOWINCOME', 'LOWINCPCT',
...
'T_PM25_P2', 'T_PM25_P6', 'AREALAND', 'AREAWATER', 'NPL_CNT',
'TSDF_CNT', 'Shape_Length', 'Shape_Area', 'geometry', 'year'],
dtype='object', length=368)
Two important pieces of information distinguish a GeoDataFrame from a simple aspatial DataFrame: a ‘geometry’ column that defines the shape and of each feature, and a Coordinate Reference System (CRS) that stores metadata about how the shape is encoded.
0 MULTIPOLYGON (((-122.28977 47.73374, -122.2884...
1 MULTIPOLYGON (((-122.29654 47.73015, -122.2952...
2 MULTIPOLYGON (((-122.29321 47.72291, -122.2929...
3 MULTIPOLYGON (((-122.29656 47.73198, -122.2965...
4 MULTIPOLYGON (((-122.29642 47.72651, -122.2946...
...
2478 MULTIPOLYGON (((-122.31386 48.07283, -122.3130...
2479 MULTIPOLYGON (((-122.32737 48.12333, -122.3256...
2480 MULTIPOLYGON (((-122.3687 48.12337, -122.36322...
2481 MULTIPOLYGON (((-122.44294 47.79322, -122.4429...
2482 MULTIPOLYGON (((-122.45861 48.29771, -122.4520...
Name: geometry, Length: 2483, dtype: geometry
Since the Seattle blockgroups are polygons, naturally they are represented as a shapely Polygon (or MultiPolygon, meaning there are multiple shapes that combine to create a single blockgroup) object. This means, essentially, that each polygon is represented as a set of coordinates that define the polygon border. The units of those coordinates are stored in the GeoDataFrame’s Coordinate Reference System attribute crs
<Geographic 2D CRS: EPSG:4326>
Name: WGS 84
Axis Info [ellipsoidal]:
- Lat[north]: Geodetic latitude (degree)
- Lon[east]: Geodetic longitude (degree)
Area of Use:
- name: World.
- bounds: (-180.0, -90.0, 180.0, 90.0)
Datum: World Geodetic System 1984 ensemble
- Ellipsoid: WGS 84
- Prime Meridian: Greenwich
In this case, the blockgroups stored in Latitude/Longitude using the well-known WGS84 datum. Latitude/Longitude is called a ‘geographic coordinate system’ because the coordinates refer to locations on a spheroid, and the data have not been projected onto a flat plane.
Naturally, the CRS defined on the GeoDataFrame governs the behavior of any spatial operation performed against the dataset, like computing the area of each polygon, the area of intersection with another dataset, or the distance between observations
/tmp/ipykernel_17288/554462416.py:1: UserWarning: Geometry is in a geographic CRS. Results from 'area' are likely incorrect. Use 'GeoSeries.to_crs()' to re-project geometries to a projected CRS before this operation.
sea_ejscreen.area
0 0.000215
1 0.000035
2 0.000044
3 0.000015
4 0.000028
...
2478 0.000457
2479 0.002580
2480 0.002256
2481 0.021275
2482 0.001603
Length: 2483, dtype: float64
Note that we get a warning from GeoPandas when trying to compute the are of a polygon stored in a geographic CRS. But we can estimate an appropriate Universal Transverse Mercator (UTM) Zone for the center of the Seattle Metro dataset, then reproject the blockgroups into that system, and recompute the area.
<Projected CRS: EPSG:32610>
Name: WGS 84 / UTM zone 10N
Axis Info [cartesian]:
- E[east]: Easting (metre)
- N[north]: Northing (metre)
Area of Use:
- name: Between 126°W and 120°W, northern hemisphere between equator and 84°N, onshore and offshore. Canada - British Columbia (BC); Northwest Territories (NWT); Nunavut; Yukon. United States (USA) - Alaska (AK).
- bounds: (-126.0, 0.0, -120.0, 84.0)
Coordinate Operation:
- name: UTM zone 10N
- method: Transverse Mercator
Datum: World Geodetic System 1984 ensemble
- Ellipsoid: WGS 84
- Prime Meridian: Greenwich
Seattle falls inside UTM Zone 10 North (apparently), and since UTM is measured in meters, the second area calculation shows the (correct) area of each blockgroup as square kilometers.
# reproject into UTM and convert area in square meters to square kilometers
sea_ejscreen.to_crs(utm_crs).area / 1e60 1.795820
1 0.287980
2 0.370467
3 0.126570
4 0.230347
...
2478 3.781797
2479 21.355873
2480 18.671198
2481 176.442839
2482 13.218388
Length: 2483, dtype: float64
One other difference between a DataFrame and a GeoDataFrame is the plot method has been overloaded to generate a quick map
Geopandas can carry out all standard GIS operations using methods implemented on a GeoDataFrame, for example
By combining these operations along with spatial predicates, we can create queries based on the topological relationships between two sets of geographic units, which is often critical for creating variables of interest.
To demonstrate, we will first collect data from OpenStreetMap (OSM), specifically highways in the Seattle metro. In OSM parlance, this means we’re querying for “highways” with the “motorway” tag (which means “the highest-performance roads within a territory. It should be used only on roads with control of access, or selected roads with limited access depending on the local context and prevailing convention. Those roads are generally referred to as motorways, freeways or expressways in English.”)
This returns a new GeoDataFrame storing each highway as a line feature.
| geometry | highway | ref | fixme | payment:good_to_go | source | name | lit | bus:lanes | hgv | ... | motorcycle:lanes:conditional | sidewalk | hov:lanes:backward | hov:lanes:forward | hazmat | start_date | sidewalk:left | sidewalk:right | bridge:movable | wikidata | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| element | id | |||||||||||||||||||||
| way | 4634293 | LINESTRING (-122.31862 47.64265, -122.3177 47.... | motorway | WA 520 | NaN | NaN | NaN | NaN | NaN | NaN | NaN | ... | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN |
| 4644156 | LINESTRING (-122.32264 47.65701, -122.3226 47.... | motorway | I 5 | NaN | NaN | NaN | Ship Canal Bridge | yes | NaN | designated | ... | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | |
| 4644167 | LINESTRING (-122.32242 47.6467, -122.3224 47.6... | motorway | I 5 | NaN | NaN | NaN | Ship Canal Bridge | yes | NaN | designated | ... | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | |
| 4644173 | LINESTRING (-122.32265 47.6467, -122.32258 47.... | motorway | I 5 Express | NaN | NaN | NaN | Ship Canal Bridge | yes | NaN | NaN | ... | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | |
| 4709507 | LINESTRING (-122.32598 47.73592, -122.32558 47... | motorway | I 5 | NaN | NaN | NaN | NaN | NaN | designated||| | designated | ... | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN | NaN |
5 rows × 104 columns
Notice in the call to features_from_polygon above, we used the unary_union operator on the Seattle tracts dataframe. This effectively combines all the tracts into a single polygon so we are querying anything that intersects any tract, rather than querying intersections with each tract individually. We can do the same thing on the highway GeoDataFrame to see the effect
Now hw_union is a single shapely.Polygon with no attribute information
Let’s assume the role of a public health epidemiologist who is interested in equity issues surrounding exposure to highways and automobile emissions. We may be interested in who lives near the highway and whether the population nearby experiences a heightened exposure to toxic emissions.
One simple question would be, which tracts have a highway run through them? We can formalize that by asking which tracts intersect the highway system.
A more complicated question is, which tracts are within 1.5km of a road? This is ‘complicated’ because it forces us to formalize an ill-defined relationship: the distance between a polygon and the nearest point on a line. What does it mean for the polygon to be ‘within’ 1.5km? Does that mean the whole tract? most of it? any part of it?
If we can define a most suitable distance measure, the technical selection is easy to execute using an intermediate geometry.
gpd.GeoDataFrame(geometry=[road_buffer.union_all()], crs=road_buffer.crs).explore(tiles='CartoDB Positron')<Geographic 2D CRS: EPSG:4326>
Name: WGS 84
Axis Info [ellipsoidal]:
- Lat[north]: Geodetic latitude (degree)
- Lon[east]: Geodetic longitude (degree)
Area of Use:
- name: World.
- bounds: (-180.0, -90.0, 180.0, 90.0)
Datum: World Geodetic System 1984 ensemble
- Ellipsoid: WGS 84
- Prime Meridian: Greenwich
| geoid | ACSTOTPOP | ACSIPOVBAS | ACSEDUCBAS | ACSTOTHH | ACSTOTHU | MINORPOP | MINORPCT | LOWINCOME | LOWINCPCT | ... | T_PM25_P2 | T_PM25_P6 | AREALAND | AREAWATER | NPL_CNT | TSDF_CNT | Shape_Length | Shape_Area | geometry | year |
|---|
0 rows × 368 columns
This gives us back nothing… There is no intersection because the EJSCREEN data is still stored in Lat/Long, but we reprojected the road buffer into UTM
By selecting the tracts that intersect with the interstate buffer, we are codifying the tracts as ‘near the highway’ if any portion of a tract is within 1.5km. This can be an awkard choice when polygons are irregularly shaped or heteogeneously sized (Census tracts are both). This means large tracts get included as ‘near’, even when a small portion of the polygon is within the 1.5km threshold (like the tract on the far Eastern edge).
Alternatively, we might ask, which tracts have their center within 1.5km of a highway? Or more formally, which tracts have their centroids intersect with the 1500m buffer.
If we are happy with that definition of proximity, we can use the spatial selection to create and update a new attribute on the dataframe. Here, we will select the tracts whose centroids are within the threshold distance, then create a new column called “highway_buffer”, set to “inside” (using the indices of the spatial selection to define which rows are being set).
Now ‘highway_buffer’ is a binary variable defining whether a tract is “near” a highway or not. We could have set these values to one and zero, but setting them as a categorical variable means that the geopandas plot method uses a different kind of coloring scheme that matches the data more appropriately.