 So, our next talk is about geographic data. It's Abram. So, please. Hello, Abram. Hello, Simon. So, where are you streaming from? Yes. So, from where are you streaming from? Yes, I think so. Ah, I understand. Okay. I'm from Venezuela. Sorry. Okay, okay. Great. So, you are talking about wildfire modeling and you are using some interesting modules like Geopandas, G-Map, etc. So, please start your presentation. Okay. Thanks. Hello. It is a pleasure to be here at the Python conference. My talk will be about wildfire modeling in Yosemite National Park. At the bottom of this slide are my Twitter social media and a link to the Github repository where you can access the entire code of this talk. The agenda will be the following. First, I will be showing you how to get data for wildfire modeling. Next, I will explain you how to import data for wildfire modeling purposes. Third, I will go through how to simulate wildfire events. And finally, I'll discuss some conclusions. Well, why do we model wildfires? Well, we use computational science to perform numerical simulations in order to understand and predict five behaviors. Wildfire modeling has many applications. First, we use this technique to protect firefighter cues during fire events. Second, by modeling wildfire, it is possible to reduce building damages and loss of lives. And third, wildfire modeling allows us to protect ecosystem, hydrogeological basins, natural areas, and so on. Well, getting data for wildfire simulation could be a daunting activity because data are not readily available or not publicly available. Sometimes data are sparse or are spread across multiple sources. So if we ought to collect our own data, it could be a very expensive activity. So in this talk, I will present an approach to readily gather and analyze data for wildfire modeling purposes. Our development environment is mainly based on Python and combined the use of Google Earth Engine or GEE, GeoPandas, GEMap, and Grass GIs. That is a powerful geographical information software. Everything within a Jupyter notebook to model wildfire events in Yosemite National Park located in the United States. Specifically in California State. Fire simulations are performed in three areas as you can see in the figure during the summer season in 2020, from June through September. The initial special dataset we need is the following. The polygon of the National Park. Data about moisture content of that vegetation. Wind direction, wind speed, datasets. Information about canopy variation of vegetation through an enhanced vegetation index or EVI. Landsat 8 and high resolution images as a base map for map visualizations. And a fuel model defined by the U.S. Forest Service. To obtain the Protected Area polygon, first we call the World Database on Protected Area picture collection using the Python API or Google Earth Engine. Next, we extract the Yosemite National Park polygon. We then convert this data into a geodata frame and save it as a chip file in our working directory. The procedure to obtain dead fuel moisture, wind speed, and wind direction is pretty similar. We need first to call the GreenMet image collection and filter by date. GreenMet is a meteorological data, a special datasets. Next, we select a specific data and calculate the mode. The resulting image is clipped to a polygon previously created and after that we create random points to sample the image using the min. Finally, the resulting feature plus feature collection is transformed into a geodata base. Geodata frame and saved as a chip file into a working directory. To get the enhanced vegetation image or EVI, we call the Landsat 8 collection EVI composite from Google Earth Engine. We then filter this image collection by date and bounds using the Yosemite polygon. Next, we calculate a min image and filter it using a polygon previously created. And lastly, the clipped image is ported to our Google Drive and from there we download it to our working directory. As I mentioned previously, to run our file simulation, we need a fuel defined by the US Forest Service. In this case, we use the 13 Anderson 5 behavior fuel model. This model has 13 classes of fuel which vary in load, distribution and particle size. We download this model using the graphic using interface of the LandFile program website. Important data for wildfire modeling is a two-step process. First, we set up our development environment to use grass GIs into our Jupyter notebook. Second, we import the database, the data obtained through Google Earth Engine to grass GIs software. When setting up grass GIs in Jupyter notebook, we use Python to initialize grass GIs. First, we create a grass GIs runtime environment by passing in a variable the directory where grass GIs is located and tie it to the Python grass directory. Then we import the required grass GIs Python packages. Let's explain briefly the grass GIs data structure. Grass data are stored in a directory referred as database. We can think that grass GIs database is a briefcase containing books. Within this database, the projects are organized by project areas stored in subdirectories called locations. Each location is defined by its coordinate system, map projection and geographical boundaries. So we can think that a location is a book. Each location has many map sets, thus a map set is a location sub-directories. We can think that a map set is a book chapter or section. And finally, inside each map set there are maps, thus we can think maps are book sheets. This is an example of grass GIs data format. We can think a database with three locations. In the first location, we have three map sets. For the second map set, we have three various maps. So there are raster maps, vector maps, 3D maps and temporal maps. So we use grass GIs using interface to create our location and map set as you can see in the figure. We then use grass GIs Python function to initialize the grass GIs session. We pass the folder name where our data are stored and the name of the location and map set. We execute grass GIs functionality through modules. Grass GIs has over 350 modules to visualize your special data and manipulate raster and vector data. Modules respect the naming convention shown in the table on the slide. For example, for raster modules, we use the prefix R. For vector modules, we use the prefix B, etc. Importing data into grass GIs using Python is straightforward. We simply use the rank command function that allows us to execute a module synchronously. The syntax is the following. First, we pass the grass GIs Python function. Next, we call the grass GIs module. In this case, we are using a vector module for import vector. That's why it has the prefix V. Next, after that, we set the name and path of the data set to be imported. Finally, we set the name of the output. In the figure below, we set the name we can see the command used to import various data sets. As I mentioned previously, we simulate Wi-Fi events in three areas in Yosemite National Park. The first area is located in the south of the park. Area 2 is located in the center west of the park. And the third area is located in the center east of Yosemite National Park. For each area, we pose the following question. For Area 1, we want to know if our simulated file has the same spread as a past file event called southforce.occord in 2017. For Area 2, we want to determine how our file simulation behaves in a small area on a ridge top, where vegetation is surrounding by bare soil. For Area 3, we want to ascertain how our file simulation behaves in large areas surrounded by mountains in a valley and during a long time, 32 hours. So, to answer the question first, we derive new data from the importing data for each study area. Second, we model five events for each area. And third, we visualize Wi-Fi propagation in each area. Modeling Wi-Fi events is a two-step process. First, we execute the grass-eyes R-Ross module that generates rate-to-spread raster maps. Second, we run the grass-r-r-spread module that simulates analytically inisotopy spread. This module generates a raster map of cumulative time of spread. In this context, inisotopy means variable conditions in different directions. As we assume windy and topographical sharp conditions, our R-Ross module needs the following inputs. A raster map containing the one hour file fuel module. It is a very rough estimate of the average module content of the forest floor below the surface. A raster map of fuel model. A raster map of a leaf-like fuel module. Raster maps are containing wind direction and wind speed. And topographical raster maps like slope, elevation, and aspect. Aspect is a compass direction that the slope faces. So, we use the previously importing data to calculate missing R-Ross input data. For example, in the table in the slide, we use the enhanced vegetation in this to calculate the live fuel module. We also use the digital elevation model to calculate the slope and aspect data sets. As the missing R-Ross input data are calculated for each study area, we simply write a Python function to compute new data. In this code snippet, we use a grass-EI module to calculate the slope and aspect data set from the digital elevation model. We also use a grass-EI module to generate raster data set of fuel module, wind speed, and wind direction from point data using the inverse distance interpolation technique. Note that we import shortcut from PyGRAC to deal with raster grass modules. In this case, we use this shortcut to run the grass-EI map call function module to uncalculate the live fuel module from the EVI or enhanced vegetation in this using a linear function or a linear equation. The output of the R-Ross are the following. A raster map containing base rate of spread, a raster map containing direction of maximum rate of spread, a raster map containing maximum rate of spread, and a raster map containing maximum sporing distance. In our scenario, sporing distance is a distance covered by burning embers during wildfires, as you can see in the figure on the slide. In this code snippet, we can see the inputs and outputs of the R-Ross modules. For the R-spread module, the inputs are the following. All the outputs of the R-Ross module are raster maps of the starting source. In the next slide, I will explain what is that. A raster map containing wind speed and a raster map of the one-hour deal of dead fuel moisture content. The R-spread module generates a raster map of the cumulative time when spread. For the R-spread module, the starting source is a point where the fire begins. Imagine we draw a lit match or cigarette in the middle of the dry forest. So we can think this is a starting source. To set this starting source, we create a point vector map from a test file containing coordinates of the starting point. Then we simply convert into a raster map this vector map. In this code snippet, we can see the inputs and outputs of the R-spread module. To generate a raster map of the cumulative time of spread using the grass-lead module, we compute spread iteratively. In this example, we divide our nine-hour simulation in three iterations. So our time lab is three hours. The first iteration starts at zero hours and ends at three hours. We do not set the initial time because by default it's zero. The second iteration starts at three hours and ends at six hours. So we set the initial time to three hours. The last iteration starts at six hours and ends at nine hours. Thus, we set the initial time to six hours. Time is in minutes. Also note that the output of the first iteration is the starting source of the second iteration. And the output of the second iteration is the starting source of the third iteration. Well, having executed the R-Ros and R-Spread modules, we can now visualize our results. In this case, we use various grass-lead commands to create three or four frames. Each frame contains the rate of spread raster for each iteration, a vector indicating the source of the simulation, a color infrared composite of the Landsat image or the high-resolution image, and the corresponding title, Legend, Scale, and North Arrow. This code snippet shows how we set the frame, the color infrared composite image, the rate of spread, the starting source of the file simulation, the math title, the legend, the North Arrow, and the bar scale. On the slide, you can see the result of the file simulation in the first area. We perform a 12-hour simulation. We divide the time spike by three, so each iteration takes four hours. Remember that through the simulation, we generate cumulative time on spread. We observe that our file spread is heading towards the style for file perimeter, that is a pass-file event. Note that when the rate of spread reaches 12 hours, the simulated file takes approximately a half of the pass-file polygon. On the slide, we have the result of the file simulation in Area 2. An high-hour simulation is performed. In this case, we divide the time spike by three, so each iteration takes three hours. We see that our file spread is constrained by the presence of bare soil among vegetation patches. In the figure, light blue patches are bare soils while reddish patches represent vegetated areas. Finally, on the slide, you can see the result of the file simulation in the third area. In this case, a 32-hour simulation is executed. We divide the time span by four, so each iteration takes eight hours. For this simulation, we have a figure showing an animated sequence of the iterations. We observe that our file spreads out toward the Yosemite Valley, generating a mega-fire. Note how our simulation avoids no vegetated areas or, in this case, light patches. In conclusion, it is possible to integrate grassy eyes, Google Earth Engine, and Jupyter Notebook in a unique development environment using Python. The result of the file simulation in the first study area could be used as an indicator of the modeling accuracy, because we can simulate wildfires in areas affected by patchfire events to compare simulated fires versus real fires. The results of the file simulation in study area two and three suggest that the modeling faster outputs do not overlap non-vegetating areas. In our notebook for the interpolation module, we use default parameters. Well, it could be very interesting to try out different interpolation parameters and evaluate how they affect simulation outputs. Finally, on this slide, you can see some reference. I would like to acknowledge my EuroPython mentor, Alexandre Maniaes-Savio, for his valuable suggestion, and also to Mario Goulic's Institute in Argentina for giving me the opportunity to do the workshop on special data processing and analysis using grassy eyes software. Thank you for your attention. Thank you very much for your talk. There are some questions. Let me start with the first one. So you initialized grass keys manually, is there a way to automate this and you do it without the GUI? Well, generally, people use grassy eyes through the graphic user interface, but grassy eyes can be also used through live commands. In this case, in my talk, I presented an approach to use grassy eyes using a Jupyter notebook. But grassy eyes should be, as I mentioned previously, or as I mentioned in the repository, grassy eyes should be installed locally to run my notebook. But many people are trying to use grassy eyes or are investigating how to use grassy eyes in the cloud. Okay, so we have a next question. Does the model need to be calibrated? If so, which parameters are usually calibrated in wildfire models? What statistics do you use to describe model uncertainty? Well, I use the five-behavior model produced by the US Forest Service. So I simply download the data I use in the notebook. For modeling, the R-Ross module and RSPrem module have various parameters. In the notebook, I use the default parameter. So it could be very interesting to try different parameters according to the area that someone is studying. Okay, at the moment there are no more questions. So thank you very much again for your talk. Now we are coming to the end of the session and next will be the lightning talks in the Optiver room.