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.

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Nava

#1
Thanks Marco, its very helpful.

I can get the total numbers pretty close if I use more decimals on my calculation converting pixel count to acres. And I think the bigger differences I was finding have to to with an offset of GIS layers used in a raster calculation- I'll fix that and see if it gets better. But either way its good for me to understand how SLAMM calculates area vs GIS, so thanks!

Nava.
#2
Hi,

I have been analyzing our SLAMM out put data two ways: 1) using the SLAMM output data tables (and converting ha to ac), and 2) using GIS (calculating ac and ha by converting pixel counts in attribute tables based on pixel size). The GIS analysis is necessary for post-processing some information, like which lands are already conserved, or tracking specific changes in SLAMM classes (e.g. how much area converted from RFM to TF).

I've noticed a significant difference in acreages between the two methods. For example, at time 0 there is a difference of 5 acres in my study area (of about 7,000 acres). But looking at total tidal wetland acreage by 2100, one simulation has a difference of 85 acres. I find these differences even when I'm not aggregating classes (i.e. when comparing the acreages of a single class, like RFM).

Have you encountered this before? Do you have any thoughts on what might be causing these differences?
I would like to continue to use both data sets, as the one from SLAMM reports on all the time steps (which would take a long time to do in GIS).

Thanks,
Nava.
#3
OK, thank you.
#4
Do you also recommend using a high autocorrelation coefficient? What guidlines can I use to choose this value?
#5
Thanks!
#6
This is helpful. We are working with recent LiDAR, so that should help, but we do also have a lot of the types of places where error may be higher than average (e.g. marsh and steep slopes).

In the SLAMM interface, when you go to specify the DEM uncertainty parameter, it seems to be briefly running or calculating something before it shows the "map". But I don't think it is anything specific to my data. If I understand correctly I would need to enter my own RMSE from LiDAR metadata. Is that right?
#7
When running an uncertainty analysis, are there any down sides to including the DEM uncertainty as a parameter? Is there strong criticism of uncertainty model results that don't include it?
#8
Using SLAMM / Re: Historic trend
March 11, 2015, 03:22:42 PM
Thanks Jonathan, this is very helpful!
#9
Using SLAMM / Re: Historic trend
February 27, 2015, 02:11:00 PM
As a follow-up, it turns out that our local SLR projections already account for the subsidence in our study area. So what we are thinking of doing to solve this problem is to input 1.7 mm as the historic trend, so that SLAMM doesn't make any adjustments for local subsidence. Then, we would make our own adjustment to our DEM to bring it to the same date as our NWI data (using our recent, local SLR trend), so that SLAMM wouldn't use the 1.7 mm there (because if the dates are the same it presumably wouldn't make any adjustment). Does this seem like a reasonable approach? Is the historic trend used in any other parts of the model that we should worry about?  Thanks for any input!
#10
Using SLAMM / Historic trend
February 27, 2015, 01:52:15 PM
If I understand correctly, the historic trend is used both to estimate local subsidence/uplift (the difference between global and local SLR) and to reconcile the DEM to the NWI photo date. The global trend is measured over 100 years (1900-2000), while the difference between my DEM and NWI photo is only 6 years, and much more recent. So the local SLR measured over the time 1900-2000 is much lower than that measure for the period between the NWI and DEM dates (something like 2.8 vs 6.8 mm/yr). How would you advise choosing just one historic trend number (or is there a way to specify more than one, for each specific use)?
#11
Using SLAMM / Re: wetland type progression
August 06, 2014, 09:41:54 AM
Thanks Jonathan, this is very helpful. We are still trying to figure out the best way to make SLAMM work in the Hudson Estuary.
#12
Using SLAMM / wetland type progression
July 29, 2014, 11:33:21 AM
In running SLAMM with somewhat customized wetland categories (for the Hudson River), we are seeing a progression where cells don't convert to a couple of our categories (tidal swamp and vegetated tidal flat). We are thinking this could be because of elevation range overlap that each of these categories have with other categories. Does this make sense? Any other possible reasons?
#13
Using SLAMM / Re: variable tide range
July 02, 2014, 02:32:13 PM
It seems the problem I was having with seeing the map (and thus being able to draw my subsites) was just due to the zoom- when I played with that a bit I could see my map. Thought I'd post that in case someone else finds it useful. Thanks.
#14
Using SLAMM / Re: variable tide range
July 01, 2014, 03:01:35 PM
That's what I would like to do also, but I don't see a map (and the Define Boundary button doesn't function) unless I run the simulation. What am I missing?
Thanks for your help!
#15
Using SLAMM / Re: variable tide range
July 01, 2014, 09:16:06 AM
As a followup, can subsites and their boundaries only be defined in the Set Map Attributes section (not by importing a polygon data set), and after SLAMM has first run the simulation without subsites? I only see the map, on which I can draw the polygons, after I've run the simulation without subsites.
Thanks.