diff --git a/.nojekyll b/.nojekyll
index a4f93e8..a3a3954 100644
--- a/.nojekyll
+++ b/.nojekyll
@@ -1 +1 @@
-af19fce9
\ No newline at end of file
+ba69cc04
\ No newline at end of file
diff --git a/mod_spatial.html b/mod_spatial.html
index 82114c2..03801dd 100644
--- a/mod_spatial.html
+++ b/mod_spatial.html
@@ -405,6 +405,7 @@
Learning Objectives
Define the difference between the two major types of spatial data
Manipulate spatial data with R
+
Create maps using spatial data
Integrate spatial data with tabular data
@@ -421,22 +422,99 @@
Needed Packages
Types of Spatial Data
-
There are two main types of spatial data: vector and raster. You may have cause to work either or both so we’ll describe both (and the packages they require) in the tabs below.
+
There are two main types of spatial data: vector and raster. Both types (and the packages they require) are described in the tabs below.
Vector data are stored as polygons. Essentially vector data are a set of points and–sometimes–the lines between them that define the edges of a shape. They may store additional data that is retained in a semi-tabular format that relates to the polygon(s) but isn’t directly stored in them.
+
Common vector data types include shape files or GeoJSONs.
+Note that even though we’re only specifying the “.shp” file in this function you must also have the associated files in that same folder. In this case that includes a “.dbf”, “.prj”, and “.shx”, though in other contexts you may have others.
+
+
+
+
+
Once you have read in the shapefile, you can check its structure as you would any other data object. Note that the object has both the ‘data.frame’ class and the ‘sf’ (“simple features”) class. In this case, the shapefile relates to counties in North Carolina and some associated demographic data in those counties.
+
+
# Check structure
+str(nc_poly)
+
+
Classes 'sf' and 'data.frame': 100 obs. of 15 variables:
+ $ AREA : num 0.114 0.061 0.143 0.07 0.153 0.097 0.062 0.091 0.118 0.124 ...
+ $ PERIMETER: num 1.44 1.23 1.63 2.97 2.21 ...
+ $ CNTY_ : num 1825 1827 1828 1831 1832 ...
+ $ CNTY_ID : num 1825 1827 1828 1831 1832 ...
+ $ NAME : chr "Ashe" "Alleghany" "Surry" "Currituck" ...
+ $ FIPS : chr "37009" "37005" "37171" "37053" ...
+ $ FIPSNO : num 37009 37005 37171 37053 37131 ...
+ $ CRESS_ID : int 5 3 86 27 66 46 15 37 93 85 ...
+ $ BIR74 : num 1091 487 3188 508 1421 ...
+ $ SID74 : num 1 0 5 1 9 7 0 0 4 1 ...
+ $ NWBIR74 : num 10 10 208 123 1066 ...
+ $ BIR79 : num 1364 542 3616 830 1606 ...
+ $ SID79 : num 0 3 6 2 3 5 2 2 2 5 ...
+ $ NWBIR79 : num 19 12 260 145 1197 ...
+ $ geometry :sfc_MULTIPOLYGON of length 100; first list element: List of 1
+ ..$ :List of 1
+ .. ..$ : num [1:27, 1:2] -81.5 -81.5 -81.6 -81.6 -81.7 ...
+ ..- attr(*, "class")= chr [1:3] "XY" "MULTIPOLYGON" "sfg"
+ - attr(*, "sf_column")= chr "geometry"
+ - attr(*, "agr")= Factor w/ 3 levels "constant","aggregate",..: NA NA NA NA NA NA NA NA NA NA ...
+ ..- attr(*, "names")= chr [1:14] "AREA" "PERIMETER" "CNTY_" "CNTY_ID" ...
+
+
+
If desired, we could make a simple R base plot-style map. In this case we’ll do it based on just the county areas so that the polygons are filled with a color corresponding to how large the county is.
+
+
# Make a graph
+plot(nc_poly["AREA"], axes = T)
+
+
+
+
+
+
+
-
Data stored as pixels
+
Raster data are stored as values in pixels. The resolution (i.e., size of the pixels) may differ among rasters but in all cases the data are stored at a per-pixel level.
+
Common raster data types include GeoTIFFs (.tif) and NetCDF (.nc) files.
Once you’ve read in the raster file you can check it’s structure as you would any other object but the resulting output is much less informative than for other object classes.
+
+
# Check structure
+str(nc_pixel)
+
+
S4 class 'SpatRaster' [package "terra"]
+
+
+
Regardless, now that we have the raster loaded we can make a simple graph to check out what sort of data is stored in it. In this case, each pixel is 3 arcseconds on each side (~0.0002° latitude/longitude) and contains the elevation (in meters) of that pixel.
+
+
# Make a graph
+terra::plot(nc_pixel)
+
+
+
+
+
+
+
@@ -458,17 +536,116 @@
Coordinate Re
Some people use the analogy of peeling a citrus fruit and flattening the peel to describe the components of a CRS. The datum is the choice between a lemon or a grapefruit (i.e., the shape of the not-quite-spherical object) while the projection is the instructions for taking the complete peel and flattening it.
-
You can check and transform the CRS in any scripted language that allows the loading of spatial data though the specifics do differ between the two types of spatial data we introduced earlier.
+
You can check and transform the CRS in any scripted language that allows the loading of spatial data though the specifics do differ between the types of spatial data we introduced earlier.
For vector data we can check the CRS with other functions from the sf library. It can be a little difficult to parse all of the information that returns but essentially it is most important that the CRS match that of any other spatial data with which we are working.
Once you know the CRS, you can transform the data to another CRS if desired. This is a relatively fast operation for vector data because we’re transforming geometric data rather than potentially millions of pixels.
+In order to transform to a new CRS you’ll need to identify the four-digit EPSG code for the desired CRS.
+
+
+
+
+
Coordinate Reference System:
+ User input: EPSG:3083
+ wkt:
+PROJCRS["NAD83 / Texas Centric Albers Equal Area",
+ BASEGEOGCRS["NAD83",
+ DATUM["North American Datum 1983",
+ ELLIPSOID["GRS 1980",6378137,298.257222101,
+ LENGTHUNIT["metre",1]]],
+ PRIMEM["Greenwich",0,
+ ANGLEUNIT["degree",0.0174532925199433]],
+ ID["EPSG",4269]],
+ CONVERSION["Texas Centric Albers Equal Area",
+ METHOD["Albers Equal Area",
+ ID["EPSG",9822]],
+ PARAMETER["Latitude of false origin",18,
+ ANGLEUNIT["degree",0.0174532925199433],
+ ID["EPSG",8821]],
+ PARAMETER["Longitude of false origin",-100,
+ ANGLEUNIT["degree",0.0174532925199433],
+ ID["EPSG",8822]],
+ PARAMETER["Latitude of 1st standard parallel",27.5,
+ ANGLEUNIT["degree",0.0174532925199433],
+ ID["EPSG",8823]],
+ PARAMETER["Latitude of 2nd standard parallel",35,
+ ANGLEUNIT["degree",0.0174532925199433],
+ ID["EPSG",8824]],
+ PARAMETER["Easting at false origin",1500000,
+ LENGTHUNIT["metre",1],
+ ID["EPSG",8826]],
+ PARAMETER["Northing at false origin",6000000,
+ LENGTHUNIT["metre",1],
+ ID["EPSG",8827]]],
+ CS[Cartesian,2],
+ AXIS["easting (X)",east,
+ ORDER[1],
+ LENGTHUNIT["metre",1]],
+ AXIS["northing (Y)",north,
+ ORDER[2],
+ LENGTHUNIT["metre",1]],
+ USAGE[
+ SCOPE["State-wide spatial data presentation requiring true area measurements."],
+ AREA["United States (USA) - Texas."],
+ BBOX[25.83,-106.66,36.5,-93.5]],
+ ID["EPSG",3083]]
+
+
-
terra::crs
-
terra::project
+
For raster data we can check the CRS with other functions from the terra library. It can be a little difficult to parse all of the information that returns but essentially it is most important that the CRS match that of any other spatial data with which we are working.
+
+
# Check CRS
+terra::crs(nc_pixel)
+
+
[1] "GEOGCRS[\"WGS 84\",\n ENSEMBLE[\"World Geodetic System 1984 ensemble\",\n MEMBER[\"World Geodetic System 1984 (Transit)\"],\n MEMBER[\"World Geodetic System 1984 (G730)\"],\n MEMBER[\"World Geodetic System 1984 (G873)\"],\n MEMBER[\"World Geodetic System 1984 (G1150)\"],\n MEMBER[\"World Geodetic System 1984 (G1674)\"],\n MEMBER[\"World Geodetic System 1984 (G1762)\"],\n MEMBER[\"World Geodetic System 1984 (G2139)\"],\n ELLIPSOID[\"WGS 84\",6378137,298.257223563,\n LENGTHUNIT[\"metre\",1]],\n ENSEMBLEACCURACY[2.0]],\n PRIMEM[\"Greenwich\",0,\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n CS[ellipsoidal,2],\n AXIS[\"geodetic latitude (Lat)\",north,\n ORDER[1],\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n AXIS[\"geodetic longitude (Lon)\",east,\n ORDER[2],\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n USAGE[\n SCOPE[\"Horizontal component of 3D system.\"],\n AREA[\"World.\"],\n BBOX[-90,-180,90,180]],\n ID[\"EPSG\",4326]]"
+
+
+
As with vector data, if desired you can transform the data to another CRS. However, unlike vector data, transforming the CRS of raster data is very computationally intense. If at all possible you should avoid re-projecting rasters. If you must re-project, consider doing so in an environment with greater computing power than a typical laptop. Also, you should export a new raster in your preferred CRS after transforming so that you reduce the likelihood that you need to re-project again later in the lifecylce of your project.
+
In the interests of making this website reasonably quick to re-build, the following code chunk is not actually evaluated but is the correct syntax for this operation.
diff --git a/mod_spatial_files/figure-html/plot-raster-1.png b/mod_spatial_files/figure-html/plot-raster-1.png
new file mode 100644
index 0000000..6c0919e
Binary files /dev/null and b/mod_spatial_files/figure-html/plot-raster-1.png differ
diff --git a/mod_spatial_files/figure-html/plot-vector-1.png b/mod_spatial_files/figure-html/plot-vector-1.png
new file mode 100644
index 0000000..6dd0823
Binary files /dev/null and b/mod_spatial_files/figure-html/plot-vector-1.png differ
diff --git a/search.json b/search.json
index 80bcb77..4fd7a16 100644
--- a/search.json
+++ b/search.json
@@ -402,7 +402,7 @@
"href": "mod_spatial.html#learning-objectives",
"title": "Working with Spatial Data",
"section": "Learning Objectives",
- "text": "Learning Objectives\nAfter completing this topic you will be able to:\n\nDefine the difference between the two major types of spatial data\nManipulate spatial data with R\nIntegrate spatial data with tabular data",
+ "text": "Learning Objectives\nAfter completing this topic you will be able to:\n\nDefine the difference between the two major types of spatial data\nManipulate spatial data with R\nCreate maps using spatial data\nIntegrate spatial data with tabular data",
"crumbs": [
"Bonus Modules",
"Spatial Data"
@@ -424,7 +424,7 @@
"href": "mod_spatial.html#types-of-spatial-data",
"title": "Working with Spatial Data",
"section": "Types of Spatial Data",
- "text": "Types of Spatial Data\nThere are two main types of spatial data: vector and raster. You may have cause to work either or both so we’ll describe both (and the packages they require) in the tabs below.\n\nVector DataRaster Data\n\n\nData stored as polygons / shapes\n\n# Load needed library\nlibrary(sf)\n\n\n\nData stored as pixels\n\n# Load needed library\nlibrary(terra)",
+ "text": "Types of Spatial Data\nThere are two main types of spatial data: vector and raster. Both types (and the packages they require) are described in the tabs below.\n\nVector DataRaster Data\n\n\nVector data are stored as polygons. Essentially vector data are a set of points and–sometimes–the lines between them that define the edges of a shape. They may store additional data that is retained in a semi-tabular format that relates to the polygon(s) but isn’t directly stored in them.\nCommon vector data types include shape files or GeoJSONs.\n\n# Load needed library\nlibrary(sf)\n\n# Read in shapefile\n1nc_poly <- sf::st_read(dsn = file.path(\"data\", \"nc_borders.shp\"))\n\n\n1\n\nNote that even though we’re only specifying the “.shp” file in this function you must also have the associated files in that same folder. In this case that includes a “.dbf”, “.prj”, and “.shx”, though in other contexts you may have others.\n\n\n\n\nOnce you have read in the shapefile, you can check its structure as you would any other data object. Note that the object has both the ‘data.frame’ class and the ‘sf’ (“simple features”) class. In this case, the shapefile relates to counties in North Carolina and some associated demographic data in those counties.\n\n# Check structure\nstr(nc_poly)\n\nClasses 'sf' and 'data.frame': 100 obs. of 15 variables:\n $ AREA : num 0.114 0.061 0.143 0.07 0.153 0.097 0.062 0.091 0.118 0.124 ...\n $ PERIMETER: num 1.44 1.23 1.63 2.97 2.21 ...\n $ CNTY_ : num 1825 1827 1828 1831 1832 ...\n $ CNTY_ID : num 1825 1827 1828 1831 1832 ...\n $ NAME : chr \"Ashe\" \"Alleghany\" \"Surry\" \"Currituck\" ...\n $ FIPS : chr \"37009\" \"37005\" \"37171\" \"37053\" ...\n $ FIPSNO : num 37009 37005 37171 37053 37131 ...\n $ CRESS_ID : int 5 3 86 27 66 46 15 37 93 85 ...\n $ BIR74 : num 1091 487 3188 508 1421 ...\n $ SID74 : num 1 0 5 1 9 7 0 0 4 1 ...\n $ NWBIR74 : num 10 10 208 123 1066 ...\n $ BIR79 : num 1364 542 3616 830 1606 ...\n $ SID79 : num 0 3 6 2 3 5 2 2 2 5 ...\n $ NWBIR79 : num 19 12 260 145 1197 ...\n $ geometry :sfc_MULTIPOLYGON of length 100; first list element: List of 1\n ..$ :List of 1\n .. ..$ : num [1:27, 1:2] -81.5 -81.5 -81.6 -81.6 -81.7 ...\n ..- attr(*, \"class\")= chr [1:3] \"XY\" \"MULTIPOLYGON\" \"sfg\"\n - attr(*, \"sf_column\")= chr \"geometry\"\n - attr(*, \"agr\")= Factor w/ 3 levels \"constant\",\"aggregate\",..: NA NA NA NA NA NA NA NA NA NA ...\n ..- attr(*, \"names\")= chr [1:14] \"AREA\" \"PERIMETER\" \"CNTY_\" \"CNTY_ID\" ...\n\n\nIf desired, we could make a simple R base plot-style map. In this case we’ll do it based on just the county areas so that the polygons are filled with a color corresponding to how large the county is.\n\n# Make a graph\nplot(nc_poly[\"AREA\"], axes = T)\n\n\n\n\n\n\n\n\n\n\nRaster data are stored as values in pixels. The resolution (i.e., size of the pixels) may differ among rasters but in all cases the data are stored at a per-pixel level.\nCommon raster data types include GeoTIFFs (.tif) and NetCDF (.nc) files.\n\n# Load needed library\nlibrary(terra)\n\n# Read in raster\nnc_pixel <- terra::rast(x = file.path(\"data\", \"nc_elevation.tif\"))\n\nOnce you’ve read in the raster file you can check it’s structure as you would any other object but the resulting output is much less informative than for other object classes.\n\n# Check structure\nstr(nc_pixel)\n\nS4 class 'SpatRaster' [package \"terra\"]\n\n\nRegardless, now that we have the raster loaded we can make a simple graph to check out what sort of data is stored in it. In this case, each pixel is 3 arcseconds on each side (~0.0002° latitude/longitude) and contains the elevation (in meters) of that pixel.\n\n# Make a graph\nterra::plot(nc_pixel)",
"crumbs": [
"Bonus Modules",
"Spatial Data"
@@ -435,7 +435,7 @@
"href": "mod_spatial.html#coordinate-reference-systems",
"title": "Working with Spatial Data",
"section": "Coordinate Reference Systems",
- "text": "Coordinate Reference Systems\nA fundamental problem in spatial data is how to project data collected on a nearly spherical planet onto a two-dimensional plane. This has been solved–or at least clarified–by the use of Coordinate Reference Systems (a.k.a. “CRS”). All spatial data have a CRS that is explicitly identified in the data and/or the metadata because the data are not interpretable without knowing which CRS is used.\nThe CRS defines the following information:\n\nDatum – model for shape of the Earth including the starting coordinate pair and angular units that together define any particular point on the planet\n\nNote that there can be global datums that work for any region of the world and local datums that only work for a particular area\n\nProjection – math for the transformation to get from a round planet to a flat map\nAdditional parameters – any other information necessary to support the projection\n\nE.g., the coordinates at the center of the map\n\n\nSome people use the analogy of peeling a citrus fruit and flattening the peel to describe the components of a CRS. The datum is the choice between a lemon or a grapefruit (i.e., the shape of the not-quite-spherical object) while the projection is the instructions for taking the complete peel and flattening it.\nYou can check and transform the CRS in any scripted language that allows the loading of spatial data though the specifics do differ between the two types of spatial data we introduced earlier.\n\nVector CRSRaster CRS\n\n\nsf::st_crs\nsf::st_transform\n\n\nterra::crs\nterra::project",
+ "text": "Coordinate Reference Systems\nA fundamental problem in spatial data is how to project data collected on a nearly spherical planet onto a two-dimensional plane. This has been solved–or at least clarified–by the use of Coordinate Reference Systems (a.k.a. “CRS”). All spatial data have a CRS that is explicitly identified in the data and/or the metadata because the data are not interpretable without knowing which CRS is used.\nThe CRS defines the following information:\n\nDatum – model for shape of the Earth including the starting coordinate pair and angular units that together define any particular point on the planet\n\nNote that there can be global datums that work for any region of the world and local datums that only work for a particular area\n\nProjection – math for the transformation to get from a round planet to a flat map\nAdditional parameters – any other information necessary to support the projection\n\nE.g., the coordinates at the center of the map\n\n\nSome people use the analogy of peeling a citrus fruit and flattening the peel to describe the components of a CRS. The datum is the choice between a lemon or a grapefruit (i.e., the shape of the not-quite-spherical object) while the projection is the instructions for taking the complete peel and flattening it.\nYou can check and transform the CRS in any scripted language that allows the loading of spatial data though the specifics do differ between the types of spatial data we introduced earlier.\n\nVector CRSRaster CRS\n\n\nFor vector data we can check the CRS with other functions from the sf library. It can be a little difficult to parse all of the information that returns but essentially it is most important that the CRS match that of any other spatial data with which we are working.\n\n# Check CRS\nsf::st_crs(x = nc_poly)\n\nCoordinate Reference System:\n User input: WGS 84 \n wkt:\nGEOGCRS[\"WGS 84\",\n DATUM[\"World Geodetic System 1984\",\n ELLIPSOID[\"WGS 84\",6378137,298.257223563,\n LENGTHUNIT[\"metre\",1]]],\n PRIMEM[\"Greenwich\",0,\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n CS[ellipsoidal,2],\n AXIS[\"latitude\",north,\n ORDER[1],\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n AXIS[\"longitude\",east,\n ORDER[2],\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n ID[\"EPSG\",4326]]\n\n\nOnce you know the CRS, you can transform the data to another CRS if desired. This is a relatively fast operation for vector data because we’re transforming geometric data rather than potentially millions of pixels.\n\n# Transform CRS\n1nc_poly_nad83 <- sf::st_transform(x = nc_poly, crs = 3083)\n\n# Re-check CRS\nsf::st_crs(nc_poly_nad83)\n\n\n1\n\nIn order to transform to a new CRS you’ll need to identify the four-digit EPSG code for the desired CRS.\n\n\n\n\nCoordinate Reference System:\n User input: EPSG:3083 \n wkt:\nPROJCRS[\"NAD83 / Texas Centric Albers Equal Area\",\n BASEGEOGCRS[\"NAD83\",\n DATUM[\"North American Datum 1983\",\n ELLIPSOID[\"GRS 1980\",6378137,298.257222101,\n LENGTHUNIT[\"metre\",1]]],\n PRIMEM[\"Greenwich\",0,\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n ID[\"EPSG\",4269]],\n CONVERSION[\"Texas Centric Albers Equal Area\",\n METHOD[\"Albers Equal Area\",\n ID[\"EPSG\",9822]],\n PARAMETER[\"Latitude of false origin\",18,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8821]],\n PARAMETER[\"Longitude of false origin\",-100,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8822]],\n PARAMETER[\"Latitude of 1st standard parallel\",27.5,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8823]],\n PARAMETER[\"Latitude of 2nd standard parallel\",35,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8824]],\n PARAMETER[\"Easting at false origin\",1500000,\n LENGTHUNIT[\"metre\",1],\n ID[\"EPSG\",8826]],\n PARAMETER[\"Northing at false origin\",6000000,\n LENGTHUNIT[\"metre\",1],\n ID[\"EPSG\",8827]]],\n CS[Cartesian,2],\n AXIS[\"easting (X)\",east,\n ORDER[1],\n LENGTHUNIT[\"metre\",1]],\n AXIS[\"northing (Y)\",north,\n ORDER[2],\n LENGTHUNIT[\"metre\",1]],\n USAGE[\n SCOPE[\"State-wide spatial data presentation requiring true area measurements.\"],\n AREA[\"United States (USA) - Texas.\"],\n BBOX[25.83,-106.66,36.5,-93.5]],\n ID[\"EPSG\",3083]]\n\n\n\n\nFor raster data we can check the CRS with other functions from the terra library. It can be a little difficult to parse all of the information that returns but essentially it is most important that the CRS match that of any other spatial data with which we are working.\n\n# Check CRS\nterra::crs(nc_pixel)\n\n[1] \"GEOGCRS[\\\"WGS 84\\\",\\n ENSEMBLE[\\\"World Geodetic System 1984 ensemble\\\",\\n MEMBER[\\\"World Geodetic System 1984 (Transit)\\\"],\\n MEMBER[\\\"World Geodetic System 1984 (G730)\\\"],\\n MEMBER[\\\"World Geodetic System 1984 (G873)\\\"],\\n MEMBER[\\\"World Geodetic System 1984 (G1150)\\\"],\\n MEMBER[\\\"World Geodetic System 1984 (G1674)\\\"],\\n MEMBER[\\\"World Geodetic System 1984 (G1762)\\\"],\\n MEMBER[\\\"World Geodetic System 1984 (G2139)\\\"],\\n ELLIPSOID[\\\"WGS 84\\\",6378137,298.257223563,\\n LENGTHUNIT[\\\"metre\\\",1]],\\n ENSEMBLEACCURACY[2.0]],\\n PRIMEM[\\\"Greenwich\\\",0,\\n ANGLEUNIT[\\\"degree\\\",0.0174532925199433]],\\n CS[ellipsoidal,2],\\n AXIS[\\\"geodetic latitude (Lat)\\\",north,\\n ORDER[1],\\n ANGLEUNIT[\\\"degree\\\",0.0174532925199433]],\\n AXIS[\\\"geodetic longitude (Lon)\\\",east,\\n ORDER[2],\\n ANGLEUNIT[\\\"degree\\\",0.0174532925199433]],\\n USAGE[\\n SCOPE[\\\"Horizontal component of 3D system.\\\"],\\n AREA[\\\"World.\\\"],\\n BBOX[-90,-180,90,180]],\\n ID[\\\"EPSG\\\",4326]]\"\n\n\nAs with vector data, if desired you can transform the data to another CRS. However, unlike vector data, transforming the CRS of raster data is very computationally intense. If at all possible you should avoid re-projecting rasters. If you must re-project, consider doing so in an environment with greater computing power than a typical laptop. Also, you should export a new raster in your preferred CRS after transforming so that you reduce the likelihood that you need to re-project again later in the lifecylce of your project.\nIn the interests of making this website reasonably quick to re-build, the following code chunk is not actually evaluated but is the correct syntax for this operation.\n\n# Transform CRS\nnc_pixel_nad83 <- terra::project(x = nc_pixel, y = \"epsg:3083\")\n\n# Re-check CRS\nterra::crs(nc_pixel_nad83)",
"crumbs": [
"Bonus Modules",
"Spatial Data"
diff --git a/sitemap.xml b/sitemap.xml
index 5042f46..c4eb9a6 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,106 +2,106 @@
https://lter.github.io/ssecr/mod_wrangle.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_project-mgmt.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_credit.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_findings.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_reports.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/policy_attendance.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/index.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_spatial.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/CONTRIBUTING.html
- 2024-06-28T19:11:55.002Z
+ 2024-06-28T19:52:25.286Zhttps://lter.github.io/ssecr/mod_reproducibility.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_facilitation.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_version-control.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_stats.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/proj_milestones.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_thinking.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/policy_pronouns.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_data-viz.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/instructors.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/policy_conduct.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_data-disc.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_template.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_interactivity.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/policy_ai.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/policy_usability.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_team-sci.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Zhttps://lter.github.io/ssecr/mod_next-steps.html
- 2024-06-28T19:11:55.042Z
+ 2024-06-28T19:52:25.326Z
