In this post, I describe the methodology that I used while performing wind speed variable work on phase 2 of the BOEM aliquot grid project. Note that this work is denoted as “2020” and was the first iteration of the phase 2 wind speed work. This process was significantly different from the work that was later done on the “2017” data. Also note that, since the source data used here was also used on the phase 1 wind speed work, the process described here, with a few minor exceptions, is similar to what was carried out on phase 1.
PLEASE NOTE: As all data sources/end products used/generated in this workflow are deemed public, permission to document was requested and subsequently granted.
Goal, Data Input, and Deliverables
Processing Overview
Source Data Overlap Editing
Since the wind speed source data came in two different formats, with different methodologies for data capture between the two, there was an issue with an overlap at the Oregon/California border. The slight differences in wind speed values, in a given area, between points of close proximity resulted in jagged boundaries being created when the polygons were later reclassified.
While still not perfect, splitting the two data sets along the Oregon/California border resulted in a much more manageable data layer. This was done by simply deleting all Washington/Oregon point data (red) that was situated south of the Exclusive Economic Zone’s (EEZ) Oregon/California border delineation (seen in green in the higher resolution screenshots).
Point Data Merging
Once the source wind speed data was preprocessed, I was able to start the process of standardizing the table. Recall that, since the data came from two sources with differing capture and formatting methodologies, the resulting merged tables were in need of cleanup. It should also be noted that the raw data came in as hourly values for every month (24 hours x 12 months = 288 wind speed value fields). What was needed for further processing was to have 24-hour (daily) as well as 5pm – 9pm (evening) average values for each month and the year overall (26 average wind speed values). This was accomplished using the Merge Rule functionality in the Merge tool’s field mapper. After consolidating the latitude and longitude fields, all unnecessary fields were deleted from the new iteration of the dataset using the Delete Field tool.
EEZ Buffer Creation and Donut Hole Removal
I created a 5km buffered version of the EEZ’s perimeter because this would allow for better wind speed interpolation along the edges of the area of interest (wherever there was existing wind speed data). The problem with the buffer, however, was that it also created 5km buffers around islands. As the buffered EEZ layer was going to later be used as a mask for the wind speed point interpolation, this meant that the resulting interpolation raster would have large holes in it where there were islands. The solution was to run the non-buffered perimeter layer and the 5km buffered layer through the Union tool. The key is to make sure to UNcheck the Gaps Allowed option. This will ensure that there are no holes in the output layer where the islands are situated. After that, it was a simple matter of dissolving the union layer in order to derive a single feature buffer layer.
Aliquot Centroid Creation
Since the source wind speed points were nowhere near coincident with the aliquot centroids, inverse distance weighted (IDW) interpolation rasters were used, in conjunction with the existing source aliquot grid cell centroid coordinates, to derive wind speed data that could be tied to the centroids. To achieve this, a separate centroid layer was created which was then used as the input point feature source, along with the rasters, in the Extract Multi Values to Points tool (discussed further down).
Interpolated Wind Speed Raster Creation
As previously mentioned, the next step was to create the IDW interpolated rasters. 26 rasters were created in total – 24 monthly and 2 annual (24-hour and 5pm – 9pm). In order to be sure to only include wind speed data for the EEZ, the EEZ buffer layer was used as a mask when running the IDW tool. Upon closer inspection of the southernmost portion of the area of interest, it is clear that a portion of the wind speed data is missing. This is because the data was not available in the wind speed source datasets.
Wind Speed Raster Reclassification
The next step was to reclassify the stretched symbology of the rasters which would aid in the proper classification of the vector versions of these layers to be created after this step. This is where things started getting a little tricky!
The values used for the “New” classes (“New values” in the screenshot) were chosen because the tool only accepts integer values in this field. Since the desired classifications needed to be floating-point values, based on the mid-point between the lower and upper limits of the classes, the fields were simply recalculated to floats in the tables for the polygon features that were derived from these reclassified rasters. In the case of the red-boxed example below, the range is 5.5 to 5.999999 (ostensibly 6) so I simply added 5.5 and 6 then multiplied by 10 to remove the decimal point. The class is thus assigned the value 115, which can later be divided by 20, in the vector feature class, to the desired class value of 5.75. Note that the end values of .x99999 were chosen because the source wind speed data values are expressed with this precision. Choosing “End” values at round 0.5 increments would have resulted in source wind speed point values being assigned to the wrong class. The differences could be negligible but in the interested of maintaining the integrity of the data, the higher precision values were chosen for the upper limit.
It should be noted that, whenever rasters are symbolized with unique values, the full width of the color ramp will be used regardless of the lower and upper extremes of the values across the feature class. This posed a problem since the majority of the wind speed datasets had differing lower and upper extremes. What this meant was that the same shade of any color could be used for different class values (depending on what values were in the feature class). In other words, the same shade of dark green would be used regardless of what the lowest class value was in the dataset. This was not acceptable as we wanted there to be consistency in symbology when comparing wind speed for different months. My solution was to create an 8-bit (256 value) proxy raster, in Adobe Photoshop, that could be used to derive a master colormap. This colormap could then be applied to all of the rasters resulting in each class getting the same color regardless of its lowest and highest values. I will document this process in the future. In the meantime, feel free to check out the nifty little Python script I wrote to help divvy up the 256 8-bit values into 40 classes (which corresponds with the 40 classes that would be found in a hypothetical wind speed dataset with a range of 0 to 20 meters/second).
Wind Speed Polygon Creation
After finishing the raster reclassification, the rasters were then converted to vector feature classes using the Raster to Polygon tool. A field was added to contain the final desired average wind speed class value (as discussed in the previous section). Using the field calculator, the new field was calculated to take the feature’s corresponding gridcode value (the raster’s newly assigned value from the previous step) and divide it by 20. This essentially unwraps the little math hoops I had to jump through in the previous step. In the red-boxed example (same one as above), the new value is calculated as 5.75. This gives this particular class a lower limit of 5.5 meters/second and an upper limit of 6.0 meters/second.
Wind Speed Data Extraction To Centroids
As previously mentioned, the source wind speed data points were not coincident with the aliquot centroids. To obtain wind speed data for each aliquot, the Extract Multi Values to Points tools was used. This version of the tool allows for multiple input rasters so I was able to get the wind speed data for all 26 rasters into the centroid layer in one shot.
Calculating The Number Of Months Above 7m/s
With the interpolated wind speed data now tied to the aliquot centroids, my next step was to derive, for each aliquot, the number of months where the average wind speed (24-hour and 5pm – 9pm) was above 7 meters/second. To accomplish this, I wrote a Python script that would run though each line in the table (i.e., each aliquot) and count the number of months that met the criteria. Note that the script stored on GitHub was actually used on the phase 1 work. The algorithm, however, was the same for both pieces (2020 and 2017) of the phase 2 work.
Wind Speed Data To Aliquot Grid Join
Once the summation of “months above 7m/s” was completed, the final task was to join the wind speed data (averages and summation) in the aliquot centroid point feature class to the aliquot polygon feature class. For the final deliverable, all extraneous fields were deleted leaving only the aliquot identifier fields, the 24-hour and 5pm – 9pm annual fields (no monthly data was left in this feature class), and the sum fields for the number of months above 7 meters/second.
Thanks so much for taking the time to read! I had a lot of fun doing this work and I want to thank Joel Osuna-Williams (CGST project manager) and Frank Pendleton (BOEM GIS analyst) for having me on the project.