Fetching AOI name from the master list

[jdduh]

This issue is of the lowest priority.

This is related to one discussion in #11, which says "Change document titles. Replace stationName from pourpoint layer with nwccname from master_aoi_list.csv stored on AGOL. Use the station triplet from the pourpoint layer to look up the record in the .csv file (same link as retrieving annual runoff value). This is a different .csv from the runoff .csv. Replace spaces with underscores before using. Map and chart titles need to use this value too."

During a recent test on an atypical AOI, the BATCH tool retrieves the stationName of the "closest" point from the master list. We should set the search radius (for example 500 meters) so that only "matched" (instead of the closest) points are used to set the AOI name and report title. For AOI that doesn't have a match, we can put "N/A" in several data fields on the summary page.

Here is a list of these N/A data fields.

0. Filename: 00000001_XX_XXXX_Watershed-Report.pdf. The 01 is a counter to prevent output with the same file name.
1. Map title: Watershed Characteristics Report AOI not associated with a station
2. Streamgage station: N/A
3. Streamgage station name: N/A
4. Dealineated drainage area: unknown square miles (question: did we get the area from the pourpoint featureclass? If yes, then set the value to unknown.)
5. Annual runoff ratio: unknown

[lbross]

Summarizing the logic that we currently use to set the nwccName:

1. Query the local pourpoint layer for stationTriplet and stationName
2. If stationTriplet is null, use the awdb_id to query the gauge station webservice (usgs_id) to retrieve the stationTriplet
3. If the stationTriplet is STILL null, use the near tool to find the closest gauge station to the local pourpoint and the stationTriplet on the pourpoint layer to that value
4. Use the stationTriplet to query for the nwccName

Are you suggesting that we not execute step 3 and use the N/A data fields if the awdb_id is not found in the gauge station webservice? I'm not sure where we would set a search radius in the current logic unless you still want to execute step 3, but only within a 500 meter radius?

[jdduh]

Step 3. Set a search radius of 500 meters in the near tool. I'm not sure what the result is if there is no feature within the search radius. If there is no feature within the search radius, then set the station information to N/A.

[jdduh]

I have published a new feature service that is to replace the Master AOI List temporarily before we have published the awdb active forecast station webservice, per https://github.com/PSU-CSAR/awdb-retrieve/issues/5.

Please check that this webservice (Master FCST List Feature Service (https://services.arcgis.com/SXbDpmb7xQkk44JV/arcgis/rest/services/Master_FCST_List_Feature_Service/FeatureServer) has all the attribute information needed for BAGIS Pro.

The key difference between the Master AOI and Master FCST lists is that the latter contains only NWCC active forecast points. Not all active USGS stations are active forecast points.

The original Master AOI List created wrong results for the stationtriplet retrieving method documented in this issue. The AOI pourpoints could match a nearby non-(active)-forecast station that is closer to the pourpoint then the actual forecast station. We need a tool to update the the AOIs that got the wrong station triplet IDs. There are around 50 AOIs having this issue.

[lbross]

The new Master FCST List Feature Service seems to be fine. This url is configured in the batch tool settings. I changed it on the server. Then I deleted my local batch_tool_settings.json so that it could be replaced by the updated one. You can do the same if you want to try.

I'm unsure of the best way to update the AOIs that have this issue. The safest way would be to rerun the batch tool for all of them because there isn't any easy way to pick out the affected pieces. But you can't just rerun the batch tool because the local pourpoint layer will have the incorrect station triplet and station name. And you also want to force step 2 to fail because the gauge station webservice could return an inactive stationTriplet using the awdb_id, right? So you'd want to null out all 3 of those fields before trying to run the tool again (stationTriplet, stationName, awdb_id), right?

Writing a tool that will do this in batch mode is not an inconsequential task, but I will think on it if this is what needs to happen.

Also, it will be a while before the awdb active forecast station webservice is available. This is in Python so it will take some time for me to figure it out.

[jdduh]

I'm thinking a tool that overrides the station data without generating the basin analysis reports. The tool also generates a log file listing the old station data and the new station data. This allows us to catch the AOIs (and their reports) that are attributed to the wrong stations. We have identified 49 AOIs that have reports, but are none-active forecast stations and speculate that the batch tool retrieved the wrong station data for these AOIs. These reports need to be regenerated.

[jdduh]

The tool just updates the station data, very similar to the rename folder tool that you created.

[lbross]

Most of the time is in creating a UI and updating the status as it moves along. If you are okay with something like the rename folder tool where it executes and writes the status to a log, that would take much less time. Thank you for explaining the requirements in more detail.

[lbross]

I am working on this. I am adding it as a button to the batch pdf tool rather than to the Migrate to FGDB tool because I need the list of valid AOIs rather than Weasel AOIs. Do we also want to change the existing logic that looks up the station triplet when an AOI is set? Step 2 above queries the gauge station webservice if we have an awdb_id but not a station triplet. If I understand the situation correctly, the gauge station webservice could have non-forecast stations in it. I notice that the new Master FCST List Feature Service has the awdb_id as a field. I wonder if we should be querying that rather than the gauge station web service? If the awdb_id isn't found on that service, then we would fallback to the near tool.

[lbross]

I'm not writing the updated values to the pourpoint feature class, but I'm attaching a sample log to let you know what I have so far. This log is generated in the maps_publish subfolder of the selected parent folder, just like the other logs. Is there any risk to potentially writing these properties to the pourpoint feature class where the values may not match the geography? This would be the case if the pourpoint for the original AOI is no longer an active forecast point. forecast_station_log.txt

[jdduh]

The master FCST list contains only active forecast points that NWCC needs. This list defines the scope of our projects. New active forecast location could be added, but were never from an existing USGS station. That means any new FCST points won't be in our original static Master AOI List. We have 6 such active forecast points that are not in the Master AOI List so far.

The FCST list was provided by NWCC. All the attribute fields after the fcstName were added by me. Their values were either assigned arbitrarily, e.g., winter_start_month (value = 11), winter_end_month (value = 3), nwccname (value = fcstName) or transferred from Master AOI List. There are 6 new FCST with Null values for most of the remaining attribute fields. These new FCSTs don't have awdb_id values. That's why Beau suggested that we should still get station information from active_USGS_Stations. I will try to patch the awdb_id data of the 6 FCSTs into the FCST master list. We currently don't have AOIs of these 6 FCSTs.

I prefer that the log file can be opened in Excel (or ArcGIS Pro) as a comma-delimited file (i.e., .csv). It's OK to have several leading lines as long as the remaining data are in .csv format. Here is a list of my preferred fields.

• Date
• Time
• Complete AOI file path (to include AOI name)
• Old stationTriplet value
• New stationTriplet value
• A flag indicating if the stationTriplet value is altered (e.g., Yes/no, or 0/1)

[jdduh]

Yes, please make this tool a high priority. The tool also enables us to generate the attributes needed for the geojson tool for the AOIs that don't already have their reports generated. There are around 70 California active forecast stations that don't need reports. NWCC still needs their AOI boundaries.

[lbross]

Here are some questions for the new forecast point tool that need clarification:

1. Our current processing updates the stationName, stationTriplet, and awdb_id at the same time when it makes a change. Do you want the tool to update all 3 fields getting its data from the AOI Master List? These fields will be updated on the pourpoint feature class.
2. If the original pourpoint is not a forecast point, the stationName, stationTriplet, and awdb_id could be different from the values associated with that point on the usgs feature service, is this okay?
3. It sounds like you want one CSV line in a log for each AOI with the values you indicated. We also need a place to write error and debug messages that won't fit into that CSV format. Should this be a second log? It would look similar to the log I sent you earlier. Otherwise it will be hard to read in a folder with many AOIs.

[jdduh]

1. Yes, please updates the stationName, stationTriplet, and awdb_id at the same time when it makes a change using the information from the FCST Master List.
2. If an existing AOI is not associated with an active forecast station, then the tool just reports the current stationName/Triplet/awdb_ID, and writes the same values to the new stationName/Triplet/awdb_ID. This AOI probably will get thrown away (or archived) when I cross-reference the log file with the Master FCST list.
3. How about replacing the flag column with a "Remark" column?

• Date
• Time
• Complete AOI file path (to include AOI name)
• Old stationTriplet value
• New stationTriplet value [Replace this with the Remark column] - A flag indicating if the stationTriplet value is altered (e.g., Yes/no, or 0/1)
• Remark: see below for some possible values:

1. Updated-Match: a record in the Master FCST List is found with a match, the station data is different from the original one
2. Updated-Near: a record in the Master FCST List is found by NEAR, the station data is different from the original one
3. No change-Match: a record in the Master FCST List is found with a match, the station data is the same as the original one
4. No change-NEAR: a record in the Master FCST List is found by NEAR, the station data is the same as the original one
5. Not A Forecast: cannot match a record in the Master list, no need to update the station data
6. Error Message(s): Put error message(s) here. As long as the log file can catch the error message, it doesn't matter if the error message(s) is the Remark column.
7. Unknown Error (other errors that are not recognized by the ErrorHandler)

[jdduh]

Just a quick note on awdb_id. It seems that awdb_id is replaced by stationTriplet in AWDB. If we decide to continue using it as a key, then awdb_id's value is equal to the first part of the stationTriplet.

[lbross]

For the 'Updated-Match' case, what field(s) are we matching on? Just station triplet? Now that we have the NEAR tool working reliably, it may simplify things not to search on awdb_id as a backup. It's an extra step that sounds like it may be obsolete. We can still update that field in the pourpoint class if we find it. Continuing working through the algorithm. I'm trying to think of a case that would meet the No change-NEAR criteria. If a basin fails to meet the MATCH criteria how could it meet the NEAR criteria and not have any changes?

[lbross]

I've gotten as far as I can on this request without additional input from @jdduh. My implementation skips the step of looking up the awdb in the FCST master list if the station triplet doesn't match. UPDATED_MATCH: Not implemented. Per my note from yesterday, I'm not sure when this would apply UPDATED_NEAR: Implemented and tested NO_CHANGE_MATCH: Implemented and tested NO_CHANGE_NEAR: Not implemented. I'm not sure when this would apply. If there is no change, it should have matched the station triplet and the immediately above condition would apply NOT_A_FORECAST: Implemented but not tested. If there is an example of a non-forecast AOI on CS3, I can test it.

I'm attaching a copy of the updated .csv log. I write a "start" line for each AOI because I'm concerned that if there were an exception, there would be nothing in the log for that AOI and it would be easy to miss. With this approach, there should always be a start line and the status line you requested. forecast_station_log.csv

[jdduh]

NWCC cautioned us about the NEAR method when I first described it to them. When the AOIs were created, some of the pourpoint locations had to be put away from the locations of the gauge stations so that they can be snapped to the flowaccumulation layer. The attribute key matching method is more reliable. We should develop our tools based on the key (now that we have one, i.e., stationtriplet). I came up with the different remark values based on logics, not actual cases that I am aware of. It's possible that the information in our original master AOI list was wrong or was updated. We can still see some unusual forecasts' stationtriplet values (e.g., the "awdb_id" part is non-numerical). It's very likely that these values will get updated in the future. Eventually the master FCST list will be updated routinely (see https://github.com/PSU-CSAR/awdb-retrieve/issues/5). Our tools need to have some error handling capabilities to detect the change of key values.

[jdduh]

"Continuing working through the algorithm. I'm trying to think of a case that would meet the No change-NEAR criteria. If a basin fails to meet the MATCH criteria how could it meet the NEAR criteria and not have any changes?"

You are right. The NOT_A_FORECAST would pick up these AOIs. Try these AOIs. They should be NOT_A_FORECAST. Let me know if you need more of these.

\GreatBasin\Sevier\oak_ck_nr_oak_city_10232010 \GreatBasin\Truckee\galena_ck_nr_steamboat_10232010 \GreatBasin\Franklin\franklin_ck_nr_arthur_10232010 \Snake_River\HUC1706\EF_Wallowa_R_nr_Joseph_11272010

[lbross]

Thank you for the test AOIs. I'm attaching the .csv output for the Sevier, Truckee, and Franklin basins. The Snake_River basin on CS3 hasn't been upgraded to FGDB. I believe the tool is working as desired. Again a summary of the desired states and their development/testing statuses. UPDATED_MATCH: Not implemented; Do you want to update the stationName and awdb_id if the feature class entries don't match these fields? The match is always on the stationTriplet. UPDATED_NEAR: Implemented and tested NO_CHANGE_MATCH: Implemented and tested NOT_A_FORECAST: Implemented and tested Let me know if you'd like me to post a new copy of the addIn for you to try.

[jdduh]

Thanks! I'd like to have a new copy of the addin.

[lbross]

The new addIn is posted on the basins FTP site. 2 mistakes that I made when testing:

1. Delete the batch_tool_settings.json file from the client computer before running the tool. If you don't do this, you will still be pointed at the master aoi list and won't get the desired results.
2. Make sure to click the 'Update Forecast Station' button instead of the 'Run' button. The 'Run' button will kick off the long-running batch report tool.

I have also updated the logic that retrieves the station data when an AOI is set to use the forecast points service instead of the master AOI list. And I stripped out the logic that used the AWDB id so all tools that set the station triplet should work the same way.

[jdduh]

Thanks! I just come up with another request related to the pourpoint attributes. You probably can implement it quickly... Request 1: Can you duplicate the attributes added to the pourpoint and add them to the aoi_v featureclass? The 'Update Forecast Station' tool can use whatever information written to the pourpoint to update the aoi_v attribute table.

Request 2: NWCC needs a featureclass that contains all the AOI boundaries of their forecast points. We need to merge the individual aoi_v polygons into one featureclass. It would be very useful that the aoi_v layer has the IDs (stationtriplet). The merge was done manually. I really hope that we have a tool to go through the directories and merge the individual aoi_v layers.

[lbross]

Request 1: No problem Request 2: Is this actually a request for a new tool :-) We could add a step to the 'Update Forecast Station' tool that merges all of the aoi_v files that it finds under the parent folder that are valid forecast points into a feature class. We can keep a list of the valid forecast aois as we loop through querying/updating the forecast station data. We could include the parent folder name in merged feature class name to keep it unique, ie: Snake_River_aoi_v. The final step of merging the merged basin aois would be manual but I don't know how else you can do it with the file structure varying. This could also be a standalone shapefile if that's easier? Or we need to decide on an FGDB name.

[jdduh]

The tool can "dump" all the aoi_v into one shapefile sitting in a "root" folder. There is no need to put just the active forecast aoi_v. It's relatively easy to use the stationtriplet to select none-forecast aoi_v polygons and remove them from the merged file. We can name the output as merged_aoi_polygons. The only concern for saving the output as a shapefile is that shapefile has a limit on the length (10 char) of field names. stationtriplet will be truncated to stationtri. If saving output as a featureclass is easier, then we can ask the user to find an output FGBD and provide a name of the featureclass on the GUI.

[lbross]

I'd like to put the shapefile output in the maps_publish folder in the "root" folder. This is where we put most output from the batch tool like the logs. Are you expecting the stationtriplet to be null for non-forecast aoi_v polygons? This is not guaranteed with the current implementation. With the NOT_A_FORECAST path we don't update the station data. This means that if a previously active forecast station is obsoleted, it could still have a stationtriplet. It would not be that hard to only merge the forecast point AOIs and the output might be smaller. I'm hoping to avoid adding additional UI components (like selecting an output FGDB) to the batch tool UI because we are running out of room.

[jdduh]

Saving the merged file in the maps_publish folder sounds good. At some point, we might need to consolidate all the small utility "tools" in one place.

It seems that there is no extensive extra work to merge only active forecast AOIs. Please merge only active forecast AOI polygons.

[lbross]

I'm running into trouble executing the merge because the array of field names on aoi_v is different depending on when the AOI was created. This means I'll need to look into how to do field mapping which is a pain. I've managed to avoid it thus far, but I'm not sure how I can in this case. What fields would you like to have on the final merged_aoi_polygons.shp. Here is are my suggestions:

1. AOINAME ?
2. awdb_id
3. basin
4. stationtriplet
5. stationname

[lbross]

I decided to use the append tool instead of the merge tool for this task. I got the merge tool working (kind of) with a field map, but it didn't populate some of the fields for the first feature class. I don't know why. The current implementation copies the first feature class to the merged feature class and then appends the remaining feature class to the initial one. It seems to work well even without a field map. I'm not sure how robust it will be if the aoi_v feature classes have radically different attribute table schemas. Because of Pro changing the field names in a shape file, I assemble the merged feature classes in a temporary database, export the merged classes to a shapefile (merged_aoi_polygons.shp), and delete the temporary database. If you want to use the merged feature class directly from the fgdb, we could leave it there and skip the last couple of steps. I know you're busy with the server, but let me know when you'd like a new version of the addIn.

[jdduh]

I prefer the output in a FGDB. It maintains the full field names. The most important attribute is the stationtriplet. I can get the other attributes from the master list. The most difficult tasks in creating the merged output is to find these 600+ aoi feature class and merge them manually.

[lbross]

So that's another thing about going to the effort to write out the field mappings for the merge tool, it seems to include ALL of the fields whether or not they are in the mappings. The current implementation includes all of the standard fields for aoi_v. I have a feeling that an aoi_v that is created using the "from a shapefile" method may not have all the same fields and could potentially cause a problem. I removed the code that transferred the merged feature class to a shapefile. The merged feature class will be in the maps_publish\merge.gdb folder of the parent directory. If the merge succeeds, the messageBox that pops up at the end will include the path to the merged feature class. If it fails, chances are it is one or more of the aoi_v feature classes with an unexpected schema. Again, let me know when you are ready for the addIn ...

[jdduh]

Sounds good. We don't have any AOIs in our current collection that were created from a shapefile. We might be able to check if there is any abnormal AOI from the merged AOI featureclass. Please publish the addin.

[lbross]

The new addIn is waiting for you on basins. I just tested on the Sevier basin on CS3 and things looked good. No special instructions other than to remember to push the correct button. 'Update Forecast Station'

[jdduh]

Installed the new addin, but the Batch PDF Export dialog won't open. The menu item was enabled. After clicking on it, it became disabled, but no dialog window showed up.

[lbross]

The good news is that I am able to replicate this problem. The bad news is that I have no idea how to fix it. None of my debug tools are able to catch the exception yet. It must have something to do with the changes I made to the dockable window. I'll keep you posted.

[lbross]

This was a strange problem. Something in the batch tool dockable window classes got corrupted. I tried making changes to the code, but nothing helped. To fix this I had to create a new dockable window with a different name and copy all of the code from the corrupted classes to these new ones. I tested it and it appears to be okay again. There is a new version of the addIn on the basins FTP server.

[jdduh]

Seems to be working. I forget to delete the batch_tool_settings.json and have to run it again after the current process is done.

[jdduh]

The AOI merge section is not working. The output FGDB was created and the first aoi_v is in the output featureclass. No other aoi_v was appended to the output. The logfile's last two lines are:

03/02/23,18:29:05,K:\NWCC\2023_NWCC_ActiveForecast_AOIs,,,Forecast station updates complete!! 03/02/23,18:29:58,K:\NWCC\2023_NWCC_ActiveForecast_AOIs,,,An error occurred while merging the aoi_v files!

According to the log file, out of the 525 AOIs, 477 has the correct stationtriplet values (i.e., No change-Match), 2 were updated with the NEAR method, and the rest (46) are not forecast stations. I need to look into individual AOIs to see if these non-forecast AOIs are indeed non-forecasts. 46 is too many!

[jdduh]

PS. It took the program about 9 minutes to go through all these 525 AOIs.

[lbross]

I will need remote access to this directory to troubleshoot the appending. Unfortunately this tool does not generate detailed error messages. I will change it this morning to append one AOI at a time instead of all at the same time. It will be slower, but this way we can see exactly which AOIs failed. This may also be a case of trying to do too many AOIs at the same time. I tested the tool with 6-7 aois max.

Let me know if you uncovered any problems with correctly identifying forecast stations when looking into the individual AOIs.

Edit: I just posted a new version of the addIn to Basins with these changes:

1. Append the aoi_v files 1 by 1 vs in a batch. If an append fails, the program moves on to the next aoi_v and writes an error to the log. This should allow us to more easily identify problematic aois.
2. Add a fileMapping object for awdb_id, stationTriplet, and stationName. Hopefully this will make the append more robust.

[jdduh]

I will test the new addin. I can put a copy of all the processed AOIs on CS3 D: drive if that helps. Let me know.

[jdduh]

The logfile indicates the process was completed 2 hours ago, but ArcGIS Pro still uses 14% CPU capacity and is not very responsive to user input. I was able to add the merged featureclass. The merge seems to be working, but I cannot open the attribute table (nor query the attribute by the mouse). Something doesn't feel right.

03/06/23,15:13:23,K:\NWCC\2023_NWCC_ActiveForecast_AOIs,,,Forecast station updates complete!!

[jdduh]

I reviewed the not_a_forecast AOIs. All but one are not associated with an active forecast stations. The one that didn't get a match is beacuse we moved the pourpoint 1.5 KM away from the station so that the final AOI boundary is correct. This station is next to a dam. Here are my followup questions/requests.

1. What is the NEAR search distance?
2. When we rerun the batch tool, will the NEAR algorithm disassociates the said AOI from the station due to that the pourpoint is too far away from the station? Or if we update the correct stationtriplet value in the pourpoint's attribute table, the batch tool will recognize the station through the attribute match?

The Update Forecast Station Data tool helps us to identify the AOIs that are not from active forecast stations. I will remove (archive) these AOIs so that they are excluded from future processing. I'm thinking disable the "attribute match" part of the Update Forecast Station Data tool so that the tool only performs NEAR search. Could the stationtriplet values of the AOIs be wrong? Or all the stationtriplet values were all derived through NEAR search originally? By disabling the attribute match, we can check the consistency between the attribute and the geographic location (i.e., through NEAR search) of the pourpoint points.

[jdduh]

I can perform the NEAR check using the NEAR tool if we have a merged pourpoint featureclass...

[lbross]

The 'Update Forecast Station Data' tool updates all of the forecast stations before it merges the aoi_v polygons. The log entry you saw was for the first half of the process, so it's likely that the append/merge was still underway and perhaps stalled. Pro wasn't configured to write a log entry to indicate that the append/merge process is complete. I just added one so that will be in the next release. A key is to determine if there is a particular aoi_v that is problematic. Currently Pro writes an entry to the Geoprocessing history screen when each append completes/fails. You could look at that to see if a particular aoi_v has been running for too long. The aoi_v files are processed in the order that you see them in the grid, if that is helpful. I could add log entries before/after each aoi_v is appended to determine where things are stalling. Let me know if you would like me to do this. This could also be a case of the feature class just getting too big/complex. 1) Many of the aoi_v's will have multiple features due to dangles. We could buffer those so we get one feature per AOI. 2) We could simplify the polygons before merging them. I'm unclear if this file will be used for analysis or for representation (map). At this point I'm not sure if the tool is failing because of a particular AOI (AOIs) or if it's the complexity of the merged feature class. Let me know what you'd like to try next. I'll post a separate entry on the 'not_a_forecast AOIs'.

[lbross]

1. The NEAR search distance is 500 meters but this is configurable. I duplicated this from the search distance we used originally to associate AOIs with a gauge station.
2. If said AOI has a stationTriplet that is on the master forecast list the batch tool will recognize the station through the attribute match, the NEAR tool will NOT run, and no update will occur.

It's possible that the stationTriplet values of the AOIs could be wrong. Previous processing assigned them based on an awdb_id lookup. If that failed, the NEAR tool was used but it didn't originally have the 500 meter limit. We could disable the attribute match and that would change the answer to question #2 above. It would probably be faster than you trying to work with the NEAR tool. But let me know if it is a temporary vs permanent disabling because that would change how I do it.

[jdduh]

The merge.gdb was last updated on 10 pm last night. It took almost 7 hours for the merge to complete. The result looks correct. Thanks for the additional information. The disabling attribute match would be temporary. Maybe create a checkbox that allows users to disable it on demand? There is no other additional request related to the Update Forecast Station Data tool. I assume that the attribute match uses the stationtriplet value stored in the pourpoint point featureclass. I can update the information on both the aoi_v and pourpoint featureclasses for the active forecast AOI that didn't get a match.

[jdduh]

Can you also make the merge section optional? You can shorten the AOI list panel if you need more space for GUI.

[lbross]

The attribute match DOES use the stationtriplet value stored in the pourpoint point featureclass. If you update the stationtriplet on the pourpoint and it doesn't match what is in aoi_v, aoi_v will be updated to match pourpoint. This is assuming that attribute match is NOT disabled so the process doesn't overwrite your changes to the pourpoint class. I will make 2 changes to the 'Update Forecast Station Data' tool.

1. Add a checkbox to apply the NEAR tool on every AOI regardless of whether it finds a match on the master list (unchecked by default)
2. Add a checkbox to merge the aoi_v polygons (checked by default; polygons will be merged)

I'm glad the merge finally completed!

EDIT: Just posted a new add-in with these changes to basins

[jdduh]

Got the new addin and ran it with the "Always look up station triplet with NEAR" checkbox checked. There were 671 AOIs. 9 still have the "No change-Match" remarks (see the partial log entries below). 88 are "Not A Forecast". The rest are "Updated-Near." There is only one AOI's stationtriplet value got updated by Update-Near. I have removed all the AOIs that are Not A Forecast based on the previous log file. The AOIs in this batch should be all Active Forecasts (unless their original "matched" stationtriplet values were wrong). The Not A Forecast AOIs should be those whose pourpoints are more than 500 meters away from the stations. Everything looks fine except for the 9 No change-Match. How can there be matched stationtriplet values when the tool looks up stationtriplet with only NEAR? Just curious. The image below shows the active station and the pourpoint of 06016000:MT:USGS. The distance between the two points is about 70 meters.

03/09/23,19:02:34,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Arkansas_pueblo_reservoir_inflow_12062011,,,Starting forecast station update 03/09/23,19:02:36,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Arkansas_pueblo_reservoir_inflow_12062011,07099400:CO:USGS,,No change-Match 03/09/23,19:02:36,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Arkansas_rayado_ck_nr_cimarron_12062011,,,Starting forecast station update 03/09/23,19:02:39,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Arkansas_rayado_ck_nr_cimarron_12062011,07208500:NM:USGS,07208500:NM:USGS,Updated-Near 03/09/23,19:02:39,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Arkansas_trinidad_lake_inflow_12062011,,,Starting forecast station update 03/09/23,19:04:41,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Arkansas_trinidad_lake_inflow_12062011,07124500:CO:USGS,, No change-Match 03/09/23,19:04:41,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Arkansas_vermejo_r_nr_dawson_12062011,,,Starting forecast station update 03/09/23,19:05:46,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Arkansas_vermejo_r_nr_dawson_12062011,07203000:NM:USGS,07203000:NM:USGS,Updated-Near 03/09/23,19:05:46,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Beaverhead_beaverhead_r_at_barretts_10302010,,,Starting forecast station update 03/09/23,19:06:47,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Beaverhead_beaverhead_r_at_barretts_10302010,06016000:MT:USGS,,No change-Match 03/09/23,19:06:47,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Beaverhead_big_hole_r_at_wisdom_10302010,,,Starting forecast station update 03/09/23,19:06:50,K:\NWCC\2023_NWCC_ActiveForecast_AOIs\Beaverhead_big_hole_r_at_wisdom_10302010,06024450:MT:USGS,06024450:MT:USGS,Updated-Near

[lbross]

I checked the code and if it matches, we don't reset the message but we do still run the NEAR tool and update. I suspect that the NEAR tool isn't finding the forecast point for these 9, but I don't know why. I'm going to look for the beaverhead example on CS3, but if you have time to copy it over, that would help. I don't need them all, just the ones that you don't think are working correctly. Or maybe just 1 or 2 to find the problem.

EDIT: I updated the logic to fix the problem where the MATCH message is not reset. I also found some glitches in the algorithm if the 3 fields did not exist in the pourpoint class prior to the tool running. The absence of these fields caused unpredictable results with the AOIs on CS3. I fixed the bugs I found and posted a new version of the AddIn to basins. You may want to rerun the forecast point update for all the basins. It's pretty quick and given what I ran into this morning, I don't have confidence in the previous results :-(