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

MTL - NAVD88 Parameter

Started by Jonathan S. Clough, January 24, 2011, 02:02:19 PM

Previous topic - Next topic

Jonathan S. Clough

It has become clear to me that the documentation is not particularly clear with regards to this parameter.  This is the MTL elevation (relative to some vertical datum) minus the NAVD88 elevation (relative to that same vertical datum).

In other words, if you have a NOAA gage such as http://tidesandcurrents.noaa.gov/data_menu.shtml?unit=0&format=Apply+Change&stn=8452660+Newport,+RI&type=Datums

And you see the following lines:

MTL           1.148  Mean Tide Level
NAVD          1.199  North American Vertical Datum

In this case, the parameter would be 1.148 - 1.199 or negative 0.051  (-0.051).

To get the correct sign (+-) that SLAMM expects using VDATUM, convert from MTL to NAVD in units of meters.



jmkassak

Thank you again, Jonathan, for working to help us clarify this parameter.  I now have a quick follow-up question to ensure that we are using this parameter appropriately. 

We are using a salt elevation of 0.12 meters NAVD88.  We need to apply the conversion factor in order to translate this parameter into the Salt Elevation relative to MTL, which is what the model requests as an input.  Our instinct says that we should be subtracting the conversion factor (in this case, -0.205) from the NAVD salt elevation to arrive at the value that SLAMM is looking for.  So, 0.12 m - (-0.205) = 0.325.

Do you agree with this application of the conversion factor?

Thanks!
Jen

Jonathan S. Clough

Yes, that is correct.  The salt elevation is 0.12 meters above NAVD88.  NAVD88 is 0.205 meters above MSL on the NOAA gage "yardstick".  Therefore the salt elevation is 0.325 meters above MSL.

http://tidesandcurrents.noaa.gov/data_menu.shtml?unit=0&format=Apply+Change&stn=8721456+Titusville,+Indian+River,+FL&type=Datums

Cheers -- J

Dean

I've been trying to get this to work correctly for a few days now, but am in need of assistance. I understand what Jonathan posted, but am unclear on exactly what SLAMM is expecting for the VDATUM [input] file.  Can someone please elaborate?

Is it expecting a ascii txt file of correction values? For example, if NAVD88 = 1.806 and MTL datum = 1.596, then the correction factor, i.e. NAVDcorr. = -0.21. This indicates that a point with elevation of 0.5m in NAVD88, let's say, will become

eq. 1         0.5 - (-0.21) = 0.77m in the MTL datum

For the VDATUM software, I've read elsewhere on this forum comments that indicated loading the NAVD88 elevation raster (in XYZ format), but choosing for the input datum, MTL, and the output datum, NAVD88.  The output VDATUM file then will have values (using the above example point) of:

eq. 2         0.5 - 0.21 = 0.29m

From here, I'm lost as to what to do next. Have I misunderstood the input datums for the VDATUM software (it does seem counter intuitive). I think a simple explanation of what SLAMM is actually looking for or doing with the "VDATUM file" will help me greatly.

If SLAMM is looking for a grid of spatially explicit correction values, then I would want to follow up with the above example by subtracting the NAVD88 elevation raster from the VADTUM output in ArcMap, right? Or does SLAMM do this for me? I put the VDATUM output grid into SLAMM but am getting highly erroneous values under the Set Map Attributes map. It appears SLAMM is taking my input elevation grid and subtracting the VDATUM input grid. If this is so, my assumption of SLAMM "wanting" an NAVD88corr grid (i.e., using my example, a spatially variable grid around my site level correction factor of -0.21m).

Thanks in advance for comments. I've been struggling to understand just what SLAMM "wants" as input for the VDATUM file.

Cheers,
Dean

jmkassak

Hi Dean,

I cannot answer your question, unfortunately, but definitely have similar questions.  Regarding your question about the VDATUM input and outputs, we were similarly confused.  Since we are inputing an XYZ elevation raster, it seemed to us that counter to what has been suggested on the forum (MTL as input and NAVD as output) we are inputing NAVD and requesting MTL as the output.   The only explanation we had for the suggestion of using MTL as the input and NAVD as the output is that others might have been simply putting into VDATUM one MTL value (i.e. one point) and using VDATUM to give them NAVD so they could calculate the correction factor for this point.  The same does not seem to apply if you are actually inputting an elevation raster, but I'm anxious to hear what the moderators have to say....

Jen

Jonathan S. Clough

#5
OK, I'll try to answer in more detail soon.  Basically SLAMM needs a spatial map of the MTL-NAVD88 parameter as described above.  You will not be able to get this directly from VDATUM but will need to do some of your own GIS processing.

The use of VDATUM should not change the sign of the correction factor.  

Your equation 2 would be incorrect if I'm reading that correctly...

Evan Larson

#6
As Jonathan noted, the VDatum correction input file needs to be in the same format as other input files for SLAMM.  SLAMM then reads in the correction values from the raster on a cell-by-cell basis according to equation one in Dean's post.

You must then convert this into a raster using some sort of processing techniquie but we do not currently support this process.

Dean

#7
Great! Thanks for sharing those, Evan. I'll look into them.

After reading Jonathan's confirmation of my assumption about SLAMM wanting a raster of correction values (which is intuitive, but not spelled out in the documentation), I followed through on it and was successful. In other words (for others), I used MTL as the input datum and NAVD88 as the output datum in the VDATUM software (though this is counter-intuitive). This gave me a txt file labeled with the NAVD88 prefix (if output folder is same as input in VDATUM) which is a bit misleading, but useful for generating the grid of correction values.  I then subtracted these values from my original raster, which gives a spatial grid of correction values for input to SLAMM.

So in short, my equation 2 product above is what I get as an output from VDATUM, but then in Arc I do:

eq. 3  vdatum output - vdatum input = navd88 correction [all in raster format]
        or to use my example
        0.29m - 0.5m = -0.21 which is one example point.

I don't claim expert status, but I've attached my workflow as a text file, which isn't generalized, but I hope useful to others. There are some quirks, like the ASCII to XYZ script I downloaded from Arcscripts inverts the raster data on the Y axis, but the Flip tool takes care of that. Then on import, my 3D multipoint file snaps the grid off by one cell (ie 3m), so I use the shift tool to realign. I'm pretty sure this is working correctly, as all seems perfectly reasonable. BUT, please do let me know if you see mistakes.

-Dean

Jonathan S. Clough

#8
Dean, I'm not enough of an ESRI guy to understand your workflow.  However, I have a question about your text.

You get the output from VDATUM.  Then you "subtract these values" from the original raster.  Is your original raster initialized with zeros?

There is a new map of MTL-NAVD88 corrections available in the latest version of SLAMM that I can share to you so that you can QA that your map is being read properly into SLAMM.

Just FYI, if the MTL-NAVD88 raster has "no-data" SLAMM reverts to the MTL correction within the relevant site (or subsite) record...

Cheers -- J

Dean

#9
Jonathan,

Yes, my original raster is initialized with zeros, if by "initialized" you mean the relevant areas (such as open water) have zeros instead of no data. As you point out, the only problem then is all the space that vdatum doesn't account for in upland areas.

I'm looking into an interpolation technique that will resolve that matter. I'm also checking out Evan's post with the VDATUM2RASTER executable.

That would be great if you'd share an MTL-NAVD88 raster with me. I'd like to QA this work. This makes sense though not that I see the raster of correction values.

Thanks for your help!
Dean

Jonathan S. Clough

I hope you received the new version that I sent you that enables you to map the MTL-NAVD88 spatial map to provide QA/QC for this set of spatial parameters.

Dean

Yep! Thanks for sharing. I've got the NAVD88 to MTL grid worked out. I appreciate your help. I'm looking forward to running the new version.

Dean