Closed jdduh closed 5 years ago
Yes, that seems to be the solution. We might want to change the cartographic design (to show areas outside the AOI) so that the location of the auto-site is easier to be verified.
Not sure what we're trying to accomplish here. Using ArcMap I recalculated the Euclidean distance raster using aoib_v as the mask and extent. Then I used the 'extract by mask' tool using aoi_v to only get the distance values inside the aoi. This gave me the exact same result as just running the Euclidean distance tool using aoi_v to begin with. Would I only see a difference if the represented area were spatially arranged in a certain way? If so, is it possible to get a sample AOI so I can verify that our solution works?
When creating an AOI with a huge DEM buffer distance (for example 2 km), the SNOTEL and snow course sites within the buffer distance were included in the AOI. During Site Scenarios analysis, the represented buffer distance was set to, say, 1 km, and as a result some SNOTEL/SC sites' represented areas are outside the AOI but could actually represent the snow pack data. The Auto Pseudo site tool should find a site within the AOI but also consider the represented areas that are completely outside the AOI. The best way to test the Auto Pseudo Site tool is on an AOI created with a large DEM buffer distance (and that there are some SNOWTEL/SC sites in the buffer zone but not close to the AOI).
The results of multiple criteria are not intersected, but unioned in the proximity rule. See the image below for an example. The search should occur in areas that are within 300 meters of streams AND within 300 meters of the forest services roads. However, the tool finds a solution that is within 300 meters of a stream OR within 300 meters of a road. Please also check the Location rule if it's the same.
The proximity rule was using the Merge tool instead of the Intersect tool to combine the layers. I changed this and it now appears to be working correctly. The Location tool works with rasters and uses a completely different methodology to combine the layers but I checked to make sure it is working correctly. Let me know if you would like me to post a new add-in.
Thanks! Please build a new addin for 10.5 (and 10.7).
I posted a new BAGIS add-in to Basins FTP. After updating the 'Specific Version' property on all the ESRI libraries to 'No', I think we can use the same addin for both 10.5 and 10.7. It should work better on 10.6 than previous versions too. I tested it on my RDP computer that is running 10.7.1 and found no issues.
Please let me know if this addin works well for you on 10.7 and I will take a look at BAGIS-P to make sure it runs on 10.7. I've already checked the libraries for BAGIS-H and think it should be good.
ArcMap 10.7 keeps shutting down when browsing for files after a new addin is installed. After removing the default template file at C:\Users\jduh\AppData\Roaming\ESRI\Desktop10.7\ArcMap\Templates. ArcGIS 10.7 works normally until the next time an addin is installed. This is just for the record.
This release seems to work on 10.7 just fine. I have yet to test it on 10.5.
Interesting. I have not experienced that issue on the remote access computer after installing the addin. Maybe check with ESRI support? Do you uninstall the old add-in and restart before installing the new one? I will work on BAGIS-P when time allows.
ArcGIS corrected itself this time. The issue disappeared before I had a chance to delete the template.mxt file. My 10.7 had this issue since day one. I wasn't paying attention to what triggered it at first. But it seems updating the BAGIS addin caused the problem to reoccur.
I wonder if something to corrupted because earlier versions of the BAGIS addin weren't compatible with 10.7.1? If this new one works, that is good.
Has there been an update to the Precipitation Distribution chart shown on slide 4? This chart is in the BAGIS manual but when I produce the charts using BAGIS, the top axis is now named 'Area-Elevation, Precipitation and Site Distribution' and displays the % contribution by elevation zone rather than the inches of precipitation.
I propose modifying the UI to only work one scenario at a time. Then we can add a tool that allows users to compare 2 scenarios. We may want to do some restructuring of how the metadata is stored but it would make the UI cleaner and the tool(s) more powerful.
Algorithm for a single site: a. Would we have a single polygon for each non-represented area/range? How to handle non-contiguous areas? b. Understand the multiple ring buffer tool and how to use a negative # for the distance to get inner buffers. Don't understand how you would use the Euclidean distance tool with this. Why not just get the centroid of the innermost buffer?
For multiple sites: How do you divide the non-represented polygon to create multiple scenarios with the multi-ring buffer? It would seem you would get the same answer every time.
Does the BAGIS maps process keep the additive precipitation layer that it used to create preczone?