nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is the Contour Line with the Zero value attribute in the Surface Contour tool's output the first contour elevation e.g. 5 Ft. or is it a base line i.e = to zero elevation?

jlabate55

Hi,

Can someone tell me if in the contour layer output of the Surface Contour tool (being run on a terrain) - is the line with the attribute zero in the Contour Field (output file) literally equal to a zero elevation? Or is the line with the attribute zero in the Contour Field the first contour in your interval, for example the 5 ft. line in a contour file with 5 ft. intervals?.

I am uncertain if I should consider this "0 contour" a shoreline and the "1 Contour" the the first (3Ft) contour in my interval or is the line with the 0 value in the Contour Field actually the first elevation contour - the 3 ft. line.

I don't see an input in the surface contour tool that actually creates / populates an elevation value field for the line segment. Am I missing something there?

When I spot check elevations on the terrain with the output contours laid over it - it appears (in some areas) the zero attribute contour line is the shoreline, but it does not align very well with a high resolution, well referenced aerial image and the 12 ft contour a little higher up does agree with a contour layer from another source. Simply can't afford to mislabel these lines.

Thanks,

Jim

Find more posts tagged with

Accepted answers

IanMurray

I'm at my other GIS job today and do have 3D analyst.

There is a parameter when you run the tool where you can control precision of the output Contour Field. That should fix the truncation issue that it is currently outputting

All comments

IanMurray

When I use the Contour Tool (Spatial Analyst) it creates the field Contour populated with the elevation of each contour. None of mine are near a shore line, but the minimum value is ~1350. I believe the values in your field are the actual elevation values of the contour.

In Surface Contour, there is a parameter to which you can assign the contour value to a field name, I believe if you don't name a field name for it to create then it makes the "Contour" field and populates it with the contour elevation.

Also shorelines are highly variable depending on time of day in aerial imagery due to tides, so it would be expected for there to be some margin of error with the contours lining up with the "shoreline"

jlabate55

Hi Ian,

Thanks for response. Yes, I assumed that the Contour Field (optional) input would just name the field and that the attribute values for the line segments would be the elevation value, but it's not.

My terrain's unit of measure is meters and I want a a 3 ft. contour interval so I just plug .9144 into the Contour Interval input. That part is fine - I do get a 3 ft. contour interval output.

The problem is the Contour field values in the output are not elevation values such as 3, 6, 9 etc. but are more like an index 0, 1, 2, 3.

This is why there is confusion as to what is the definition of the of the zero value: does. Is it = 0 elevation or is it actually the 3ft. contour (with zero being the first number in an index)?

The fact that there is not great alignment with an image is not my real concern. It's when i go back and use the identify tool on the terrain itself and compare that spot check to what the value of a nearby contour from the output that I'm interpreting a certain way - i.e. the 0 value equals the 3 ft. line - that I start to feel as if I'm looking at my contours as being 3 feet ahead of themselves in the interval.

Again, there would be no ambiguity if the "Contour" field had elevation values, but it doesn't - they a re just a sequential index. Simply renaming the field in the tools input yields the same index-like output.

What do you or anyone else think I'm missing here?

Again to recap, I'm getting more of an index in the Contour field - not specific elevation values - and I'm unsure about where my contour interval starts - or what the definition of the zero line is.

Best,

Jim

IanMurray

I wonder if the issue is that you made your contour interval to be .914. While it is technically 3ft, it will still populate the attribute table contour values based on the contour interval(.914). So depending on how many significant digits are showing, it might show a 0 for the contour elevation, even if it is 0.914(m) or 3ft. For 6ft it might show 1 based on the number of significant digits showing for the field. If your contour field is still storing elevation in meters, I'd make a new field and then multiply your first contour field by 3.28084 to have it storing the values in feet in the new field.

Mind posting a screenshot of the attribute table?

jlabate55

I added a field and multiplied the contour field by 3.28084 but the result is just as if I multiplied and index field by 3.28084. In other words the Contour field value is really just 1 or zero - the table is not displaying .9144 as 0.

So you are saying if I put my contour interval in meters say 3 meters I would get values of 3, 6, 9 etc in the contour field - only in the wrong units from what I need?

Again, I feel confident I am getting a 3 foot contour interval - that the output is producing that - I just don't know for certain what the 0 value stands for - the first contour in the interval e.g. the 3ft. line - or a zero elevation baseline - meaning the lines classed 1 in my contour field are the 3 foot line.

I've attached a screen grab. Thanks for help. Will have to continue tomorrow.

Much appreciated.

Jim Contour Field Issues.JPG

ThomasWhitfield

Just a stupid observation, but isn't zero still zero in both meters and feet?

JeffreyStevens

Of course, But are you suggesting meters and feet are the same just because they have 0 in common?

IanMurray

Yes, but what should have been .914 meter contours(aka 3ft but the table was storing it as meters but as an integer via truncation) made it an elevation of 0 in the attribute table. So while some contours with a table elevation of 0 were truly 0 elevation, others were 3ft but were given a value of 0(due to the tool parameters when first ran). Once the correct precision was applied during the running of the tool, there were true decimal meter elevation values in the table which could then be turned into feet.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.