M4 - Flood Analysis

 This week involves coastal flood analysis. Both of the below maps look at damage from severe storms or storm surge. The first of which looks directly at pre and post Hurricane Sandy elevation data from 2012 in New Jersey. That analysis utilizes change detection to show where damage areas are, where debris accumulation or shoreline accretion is taking place. The second map is of Naples Florida and is solely based on if there was a 1 meter storm surge what properties would be impacted. The crux is that two different elevation models are being compared to take the analysis a step further. All of this is helping to better understand coastal flood assessments, and how elevation models can be used to delineate coastal flood zones. Numerous raster analysis and modifications were undertaken to process the various LiDAR and DEM data. Followed by attribute table manipulation to determine some accuracy statistics between the two mentioned elevation models which will be discussed more below. 

The map above is essentially a hot and cold heat map, where hot is areas of high negative change. This means for example, a location where a building previously stood which is now gone. The opposite of this is the blue areas which indicate a positive change in that location. This for example could indicate areas where debris has accumulated, or sand has piled up. The information on the map also discusses some of how it came to be, but in simple terms it is the combining of a before raster with a post raster, specifically isolating the elevation change.

Now onto the storm surge map. 

 

The map above looks at a comparison of USGS DEM derived from traditional photogrammetry against one using a higher-resolution LiDAR dataset. Each dataset was transformed to only show areas where it predicts a 1 meter surge impact. The LiDAR layer is over the USGS layer, but both have areas where the other is not a factor. Because of the scale of the Naples and Marcos Island scene I wanted to provide a better look at how the two data layers are overlapping or not, so I provided an equally sized inset of Naples. There you can see representative examples of each of the impact types. From those buildings not impacted, to those only represented on one DEM dataset, to those represented on both datasets. In this case the most true representation of buildings impacted would be those that are Red for "both" and those that are blue, for LiDAR only. The red and blue together would be the most likely to be impacted. The orange USGS only, would likely not be impacted as its dataset was more coarse when analyzed. 

These are some excellent tools to determine flooded areas from elevation data, and impacted facilities. Thank you. 

v/r

Brandon 

M3 - Visibility Analysis and ArcGIS Online

    This week took us to ESRI direct, utilizing ArcGIS Online and 4 different ESRI hosted training sessions. The theme? Visibility analysis. This week carries forward with our look at LiDAR last week, by continuing to use some similar products, working with elevation layers and overlapping features of varying heights, shapes, sizes, make up types (points, lines, polygons) to work with different portrayals of 3D information. The modules themselves were:  

• Introduction to 3D Visualization 
• Performing Line of Sight Analysis 
• Performing Viewshed Analysis in ArcGIS Pro
• Sharing 3D Content Using Scene Layer Packages 

    These modules all served to highlight how helpful 3D data and information presentation or visuals can be in identifying patterns not seen in 2D. They aid in providing new perspective of vertical content, and provides an extra sense of realism with the ability to navigate and explore in a 3D manipulable environment. 

    One of the key takeaways was in understanding the difference between a local scene and a global seen. They both typically revolve around the scale of information you are working with, but more explicitly in how they convey real-world perspective vs real-world context. One key difference being if the curvature of the earth is a factor in your information presentation or not. 

    We continued to work with LAS data, DEM's or other forms of elevation layers, but also with Z-values which provide the third dimension for points, lines, and polygons. 

    For points, you could add a height extrusion, such as showing how tall trees are, or lamp posts. For lines, you could establish a standard height above ground for a fence line, or make a particularly uniform elevation boundary. Polygons with Z information gain new dimensions as the shapes are shown. From a square or circle in the 2D to a full 3D building structure. 

    Other analyses can then be done with a fully extruded 3D scene. Line of sight and viewshed analysis was a big part of this weeks training. These revolved around constructing sight lines, then building lines of sight. Whats the difference you ask? Constructing sight lines involves an observation point with known elevation and a target point with known elevation and generating a line between the two. Then, the line of sight utility is used to determine if there are any obstacles from the observer to the target. Buildings, terrain changes, trees or foliage features, etc can all block line of sight. A viewshed takes this a step further in being able to establish what is in view based on what elevation and field of view parameters.

    To take it a step further and apply it to the real world, look at the news this week, there are all sorts of graphics being modeled and analyzed after former President Trump was shot at. Building models, sight line distances, camera vantage points, obstruction analysis. All going on in the real world this week is the exact substance of this module. 

    Regardless of the ongoing real world applications, this module was culminated in creating a shareable scene layer package. An example of the type of deliverable generated for this is below. 

    Overall, these are all hugely relevant skills for GIS applications. They allow you to explore your data more in depth and provide much more immersive presentations. Onto the next week. 

V/r

Brandon

M2 - Biomass Density Analysis

This is the first of two weeks working with Light Detection and Ranging (LiDAR). This week we are working with data acquired from the Virginia Geographic Information Network (VGIN). A LiDAR point cloud was acquired for one of the park and valley areas in the Shenandoah National Park.

With the singular point cloud several different products and transformations were made to derive the biomass density map below. The point cloud itself (seen in the second image) is a 3d feature layer as height is involved with each point in the cloud. The primary transformation involved deriving ground and elevation data to generate a Digital Elevation Model (DEM), and a Digital Surface Model (DSM).

Interestingly, there is quite a sequence of tool use to generate these deliverables.
- LAS to Multipoint > Point to Raster > Is Null > Con > Plus > Float > Divide

Note that this sequence is either transforming the data type, as in the LAS to point or point to raster. Or it is an adjustment to the cell values in the case of the remainder of the string. The Divide tool is different as it is a combination of the ground and surface data which provides for our final output below. 

The biomass density map above shows the cumulative height by pixel for the entire scene. The DSM and DEM scenes have been averaged together to give each cell a 0 – 1 value. This allows the higher values to show denser vegetation and the lower values to show less height or less dense areas. This is helpful to forresters because it can indicate areas of highest / densest brush. From the image here you can see that these areas follow the contours of the valley in the north / north east portion of the scene. The scene can also highlight the difference between lower scrub compared to the high trees, areas where plains may be compared to tree thickets. 

As described in the map above you can see the LiDAR point cloud which was then used to transform into the raster based DEM on the left. While all of the images above are the exact same area, they are transformations or translations of this point cloud. 

This was an interesting lab with significant tool usage, but it is overall interesting to see how it can be transformed from raw data to a useable product. Thank you.

v/r

Brandon

M1 - Crime Analysis

    Have you ever wanted to be a Crime Stopper? While you might not reach that milestone with this module, but you can certainly become a better crime analyzer! Analyzing crime through spatial correlation and heat mapping is the name of the game in this module. 

    The overall goals of the module involved gaining familiarity with GIS analysis tools and processes that can help in crime analysis. These allow us to convey and illustrate crime rates, and help derive spatial patterns based on socio-economic characteristics. The same data set was used in three different processes to derive the outputs below. 

    Specifically, a grid cell analysis, kernel density analysis, and Anselin Local Moran's I analysis were all performed with 2017 homicide data for the greater Chicago area. The below are not fully finished maps that would otherwise incorporate our traditional map elements. This would include an actual title, legend, scalebar,  north arrow, and other potentially enhancing information. They are designed to showcase the same data in three different ways. They all highlight spatial clustering for the homicide data, or where the data suggest the highest rates or prevalence occurred in the subject year. A brief rundown of each is below.

Grid Cell Method:

    Happily, the ½ mile by ½ mile grid feature was provided for the study area. This grid was spatially joined with the homicide point feature for 2017. From there, only grids that actually had a homicide occurrence were desired, so they were selected by attribute.

    Of those cells with homicides, this study called for focusing on the top 20%, which resulted in 62 individual cells. That exported feature class was then dissolved to a singular feature. This was for visual presentation, not statistical relevance. 

Kernel Density Method:

    The Kernel Density tool takes a point feature class and transforms it to a raster output using a “magnitude-per-unit area calculation. For this specific tool, I utilized an output cell size of 100 sq feet, and a search radius of 2,630 sq ft or approximately ½ mile, the output of which generates density based image.

    From there, the mean value (2.76) is established, and to highlight the most dense areas I used three times the mean (6.71). These then, were the most homicide prone regions of Chicago for that year, 2017. From there, the image was reclassified using this breakdown into 2 classes, below 3 times the mean, and above. That output was then transformed via the raster to polygon tool. Because the output had 2 values, we only wanted the one that represented above three times the mean. A select by attributes process was used to gain only those areas above three times the mean, and exported as a standalone feature for display. 

Local Moran’s I:

    This process utilizes a normalization of the census tract housing data combined with the homicide data. As in previous processes, a spatial join was performed with the homicide feature and the census tracts. From there, a new data field was created to calculate the number of homicides per 1000 households.

    The Anselin Local Moran’s I tool, was then used to identify statistically significant clustering and outliers. Specifically, we want to identify areas with a high homicide rate in close proximity to other areas with a high homicide rate (HH areas). As opposed to other combinations that are high / low, low / low, low / high, respectively. Once the High/High areas were identified, they were selected using a SQL query, and exported to their own feature class. This class is then likewise dissolved into a single feature. 

    Overall, the provided instructions ensured that there weren't too many issues during the processing of this module. some of the most time consuming parts were in comparing the tables and validating the fields for the various joins that were used. Then selecting the correct inputs for the various SQL queries and attribute selection actions. It is quite interesting how the same data can be aggregated and presented in multiple different ways to draw different conclusions. Thank you.

v/r

Brandon

Intro to GIS Applications

 

Hello everyone! 

Welcome to the start of another course, GIS Applications, Masters edition. As a recap, I am Brandon Deusenberry and It's great to work alongside a strong group of budding GIS professionals as we tackle a new set of skill challenges. 

For the basics, I am early still early in the Masters Program, with a projected graduation of Fall '26. It cant get here soon enough! I am a full time active duty Air Force member. This July is my 21st anniversary in the service. It absolutely does not feel like it has been that long. I am a full motion video, remote sensing camera operator by trade. But nowadays my work time is more dedicated to leading and mentoring the enlisted members in my charge. I have a family with 4 crazy boys, each a different challenge, but all awesome. 

Below is a link to my story map, which has both a bit about my history and some places I have been, but also some of our recent summertime adventures. Between full time work, family time, and school, I don't have as much free time as I would like. But I still try to get together with my DnD group, and or play video games with friends where able. 

Hopefully, about the time I am done with the Master's program, I will be wrapping up my military career. From there I will combine both worlds' skills and move forward into a new one. While I can zone out and enjoy working on the technical aspects of GIS, I think I would much prefer a position that lets me help organize and lead a team of GIS professionals. But we will see what happens. 

This intro also calls for some adjectives that I think describe me, so here are those:
silly, sarcastic, gruff, calm, thoughtful, useful

But I'll let you work with me and figure out some of your own, or if those are accurate. 

My Story Map: 
https://arcg.is/00vnWC0

Mod 6 - Geometry Processing

 Greetings all,

And just like that, this half-semester is about over. Welcome to module 6, working with geometry processes. The goals here are to explore the geometry objects associated with point, line, polygon, single and multipart features. The end deliverable and goal of the module was to create a search cursor which iterates over a river based shapefile. It then writes the associated vertex location information into a text file. It does this by utilizing a nested for loop. 

Below is a pseudo code representation of the process: 

Start

            Import Modules
                        arcpy, fileinput, string, OS, env

            Define workspace.

            Create SearchCursor for “OID”, “SHAPE@”, “NAME” within desired feature class.

            Create or Identify text file for writing results too.

            Utilize for loop to iterate through each row in cursor

                        Define VertexID for sequential vertices processing

            Utilize nested for loop to iterate through each point in row.

                        getPart() to iterate through each object.

                        Add +1 to previous point in row to continue iteration..

            Write SearchCursor output to the text file.

            Close text file.

            Delete Row

            Delete Cursor

End

The above shows the flow of the script. Note it doesnt include things like print statements designed to highlight script process. Another thing it doesnt do well is show the nested nature of the for loops. However, this is overcome with the flowchart below. 

The nested loops are more prominent above, and highlight the majority of the script processing. Aside from those loops this script is more simplistic than some of the previous, really incorporating only 3 tasks. Create a Text file, iterate over a shape file for the name, ID, and vertices information, and output it. Here is a sampler of the final output. 

For the above result we can see that the object had 25 individual features with varying amounts of vertices. But the goal was to open, write, and export that information to a shape file. Lastly, we have a snippet from the corresponding text file. 

For as simple as the process was, there are several different components to it. Its definitely amazing how far the processing and understanding of it has come in a few short weeks. Thank you much, and good luck in the next class.

v/r

Brandon

M5 - Spatial Processes

 Greetings all,

The scripting is getting more complex. The tools and functions being used are getting more involved. This week works with cursors, lists, and dictionaries. Specifically, using a search cursor to find particular information from a feature and then outputting that information for us to view. It is, of course, more involved than that simple sentence conveys. Multiple substeps are utilizing the principles we have built over the past five weeks. 

At its heart, this script is a series of 'for' loops that iterate over some shapefiles, then search through a particular one to pull county, city and population data. Many of the subtasks associated are incorporated into the flow chart below. The flowchart is broken into 5 different parts, with part 3 through 5 being the meat of the assignment. I likely didn't have to subdivide parts 1 and 2, but they were distinct enough to me to do so. I think part 1, environment establishment should be default in most flow charts, and what you do after that is distinct, you wont always be establishing a new file geodatabase as is the case here. Regardless, multiple things could have been incorporated or further subdivided. 

I particularly like to keep a linear flow in my chart where able. There is not any branching logic in this script. All tasks are performed subsequently to another. However, the 3 'for' loops are shown with their accompanying substeps in a square-ish loop of iterable items. It is implied that the loop will execute for each item and then continue along the linear path. 

The two images below are the culminated outputs for the different parts of the script diagramed above.

Note there are two and a half columns of named and described cities which are county seats. These outputs have been condensed into the two images above rather than kept in their original long-length format. Ultimately, as the flow chart shows, a File Geodatabase is created, then numerous features are copied into it, then a search for county seats ran on a particular feature, and finally, a dictionary is populated from those county seats. 

There were a number of scripting challenges, particularly with gathering the appropriate input data for the dictionary and selecting the right variables for the search cursor. But they were ultimately overcome. 

Thank you,

Brandon