October 01, 2020, 01:35:20 AM

News:

Due to SPAM attacks, new members must be approved before posting.  Please email jclough@warrenpinnacle.com when registering and your account will be approved.


Changing Habitat from Input to "Initial Condition"

Started by jmkassak, November 12, 2010, 12:41:13 AM

previous topic - next topic
Go Down

jmkassak

I am running SLAMM in a large estuary using 2004 LULC data (converted to SLAMM categories) and circa 2006 LiDAR data (5 ft x 5 ft resolution).  We are running the model on a 10 m square resolution, and have resampled the LiDAR data using bilinear interpolation to get to that resolution.  We have run the model for 4 subsites and in each case the habitat conditions in T=0 (the input) are drastically different from what is being modeled for 2004 as the "initial" condition.  We're seeing things like an over 800% increase in mangroves, and conversion of large extents of irregularly flooded marsh being converted to regularly flooded marsh (there was no regularly flooded marsh identified in the input data), to name a few.

Just as a test, we ran one of the subsites with the Pre-processor on and it yielded a T=0 and 2004 initial condition that are nearly identical.  However, even with the resampling that we did, I wouldn't think we should be running the pre-processor since we have Lidar data.

What process is SLAMM going through from the input to the initial condition that could cause the extent of change that we are seeing?  My one thought is that it might have something to do with a unique tidal regime in the estuary (which I will ask about in detail in another post) which causes the elevation ranges of wetland habitats to be quite different from what SLAMM assumes.  In other words, perhaps at T=0 it is seeing habitat types at elevations it does not "agree" with and is revising them according to its assumptions about correct ranges? 

Any thoughts? 

Thanks!
Jen

jmkassak

Just to add another thought as I'm continuing to look at this issue.  The fact that the pre-processor eliminated the problem seems to potentially indicate that the issue IS being caused by SLAMM not liking the elevation ranges where it is finding our habitat types.  Because isn't the pre-processor revising our elevation data such that the elevation for a particular habitat type would be reassigned to the anticipated range of elevation for that habitat type?

Evan Larson

I should clarify that the initial condition is the input wetland data and the time zero is the input wetland data after elevation boundary processing.  The model has certain assumptions about wetland elevation boundaries and the time zero reflects these assumptions, changing a land type if it falls below the assumed lower boundary. 

With the preprocessor turned on, wetland elevations are forced to fit these boundaries, creating rising planes (ramps) that face the offshore direction.  Preprocessing should only be used if your elevation data is extremely poor (like 20 foot contour USGS topographic data).

You can customize these elevation boundaries so they fit the habitat you're modeling.  To do this, perform an elevation analysis in Set Map Attributes.  For the land categories that are changing the most in time zero, the elevation analysis probably reveals that the 5th percentile is much different (lower) than the minimum half tide unit (min HTU).  Try lowering the minimum elevation of the land categories and see if that changes the time zero results.

Evan

jmkassak

Eric,

This is very helpful, thank you.  It wasn't clear from the documentation how much "work" SLAMM was doing between the initial state entry and Time = 0 (thanks for clarifying the terminology there.)  It seems as though our suspicion was correct and SLAMM does not "like" where our habitats are falling elevation-wise.  We had run the Analysis and were in the process of figuring out what more appropriate ranges might be.  Related to that process, I'm wondering if there are any limitations to how flexible SLAMM is with these assignments.  Put another way, are there limits to what it will tolerate for ranges of specific habitat types because of how the background analysis is being run and presumably some order of succession it has hard-wired? 

Thanks!
Jen

Jonathan S. Clough

Yes, the time-zero results are a result of significant portions of your wetland habitats falling outside the range that SLAMM assumes that they will be located.  If we use the "pre-processor" SLAMM is forcing the elevations of these habitats into the conceptual model so it is no surprise that there is then no change at "time-zero."

The SLAMM model is quite flexible with regards to adjusting this range but that doesn't mean that these adjustments should always be made.  For example, there can be problems with the parameterization of tide ranges or the MTL to NAVD88 correction that, if fixed, would significantly improve the relationship of your data vs. the conceptual model.  To modify the conceptual model instead of fixing those parameterization problems would not be ideal.

Also, due to horizontal and vertical LiDAR and land-cover uncertainty, there will always be some cells converting at time-zero when you are using LiDAR data.  I hope to institute an interface that will allow you to view the distributions of wetland elevations for each wetland type soon.

There are furthermore some assignments that simply should not be made.  For example, allowing dry land elevations to extend to near or below mean tide level would be folly. 

Finally, as you note, the SLAMM flow-chart model of transitions from one class to another is not currently editable.  Therefore you should be sparing in any changes to the SLAMM conceptual model and note any changes that you do make in the documentation of your model application. 

Some valid reasons for changes in conceptual model are:


  • Tidal fresh marsh and tidal swamps extend well below the salt elevation and the lower boundary is a function of fresh water flow.  These categories generally require adjustment.

  • Extremely microtidal regimes can cause problem with the "salt-marsh elevation as a function of tide range" concept. Moving to units of meters may be warranted.  Wind tides become very important in these systems as well.

  • In macrotidal regimes, salt marshes often extend slightly below mean tide level.



I'm sure there are more...

-- Jonathan

jmkassak

Hi Jonathan,

I am still in the process of trying to determine the sources of the problems that I'm seeing with our wetlands/elevation data not complying with SLAMM's conceptual model and as a result, significant conversions happening between initial input and T=0.  Recently I've been focusing on simply ensuring that our wetlands are all categorized correctly (we are not using NWI data) and making sure the parameterization is correct before I start editing any elevation ranges.

In looking at our GIS maps more closely I noticed an issue I cannot figure out.  As I've mentioned previously, large swaths of initial state salt marsh (we are calling all salt marsh "irregularly flooded" right now) are converting to mangrove in year 0.  I would have guessed this was due to the salt marsh elevation being lower than what SLAMM would have expected (i.e., lower than 0.5 HTU) and thus making the conversion to mangroves immediately.  However, as I click around the map to see elevations in this area they appear to be comfortably within SLAMM's range for irregularly flooded marsh (0.5 HTU - Salt elevation).

For example, I'm in an area where the elevation (NAVd88) is between about -0.07 m and 0.08 m NAVD88.  If my HTU value is 0.025 m, and my NAVD correction is 0.205, according to my calculations, the range for irregularly flooded salt marsh in NAVD 88 would be -0.19 m to 0.12 m (the salt elevation).  If the area of irreg. flooded salt marsh is comfortably within the range, why would it be converting to mangrove right away?  Could there be other causes for this problem that I should be considering?

Thank you!
Jen

Jonathan S. Clough

(For the record, this appeared to be a problem with the sign of the MTL - NAVD88 correction which was not adequately documented.)

Go Up