To Whom is Interestd and Available to look into this!
This is slowing down and threatening to cause RAM problems in making the Washington Connectivity Action Plan for WDFW and WDOT. If someone is able to fix this problem they wil be acknowledged in the project report as well as in LM documentation.
Here is the problem. A linkage priority run:
Note how the linkages at the bottom of the above example get clipped off.
LM used a value of 1000000 ft bounding circles buffer distance, in getting the inputs for LP.
But when I ran again, without this timesaving stepo, the linkages did not get cut. (A few other variables got changed, but they seem unrelated. If need be, paste notes from this weekend in the LM Troubleshooting doc. )
I suspect that there is one step in LP that needs to override the default geoprocessing extent to be the min of inputs to instead be the union of the inputs, or even the extent of the entire project if Unin does not work. Or possibly it is an issue in which null values need to be changed to 0 in one of the calculation steps.
Here is the end of the workflow:
"Calculating Corridor Specific Priority (CSP) for each linkage:
-Calculating CSP
Calculating Blended Priority (BP):
-Clipping NLCC rasters to CWD threshold
-Inverting and normalizing each corridor
-Calculating overall BP"
First fix attempt would be to make sure that all the steps of taking the max and mean and mean of the two layers when "calculating overall BP" are using "union of input extents" rather than (the default?) of intersection of input extents.,
Alternate or second attempt And/or if that is already the case, to change null values to 0 values. Probably in the step "clipping NLCC rasters to CWD threshold"
Recommended first step would be to try to replicate the error using the Linkage Priority test data (Use a bounding circle that is just long enough to include the longest linkage). If that does not work, you can contact me to see if I can share my current data with you.
To Whom is Interestd and Available to look into this!
This is slowing down and threatening to cause RAM problems in making the Washington Connectivity Action Plan for WDFW and WDOT. If someone is able to fix this problem they wil be acknowledged in the project report as well as in LM documentation.
Here is the problem. A linkage priority run:
Note how the linkages at the bottom of the above example get clipped off.
LM used a value of 1000000 ft bounding circles buffer distance, in getting the inputs for LP.
But when I ran again, without this timesaving stepo, the linkages did not get cut. (A few other variables got changed, but they seem unrelated. If need be, paste notes from this weekend in the LM Troubleshooting doc. )
I suspect that there is one step in LP that needs to override the default geoprocessing extent to be the min of inputs to instead be the union of the inputs, or even the extent of the entire project if Unin does not work. Or possibly it is an issue in which null values need to be changed to 0 in one of the calculation steps.
Here is the end of the workflow:
"Calculating Corridor Specific Priority (CSP) for each linkage: -Calculating CSP Calculating Blended Priority (BP): -Clipping NLCC rasters to CWD threshold -Inverting and normalizing each corridor -Calculating overall BP"
First fix attempt would be to make sure that all the steps of taking the max and mean and mean of the two layers when "calculating overall BP" are using "union of input extents" rather than (the default?) of intersection of input extents.,
Alternate or second attempt And/or if that is already the case, to change null values to 0 values. Probably in the step "clipping NLCC rasters to CWD threshold"
Recommended first step would be to try to replicate the error using the Linkage Priority test data (Use a bounding circle that is just long enough to include the longest linkage). If that does not work, you can contact me to see if I can share my current data with you.