Latest Contributions by EricRice

Hi Kent, I used this and it works.  You don't have to run the tool ASCII to Raster.  ASCII files that are formated like this are already recognized by the software as raster datasets. Regards, Eric ... View more

Dustin, Why bother to run ASCII to Raster in the first place?  An ASCII file formatted like the one Tarun outlined, should already be recognized as a raster dataset.  That tool is a legacy tool and was only needed for the days when we couldn't read ASCII files representing raster data as actual raster datasets.  All you probably have to do is build statistics on the .asc file, define the projection, and it will render as raster data in ArcMap.  To confirm this you can run the Raster to ASCII tool to output an .asc file.  Then hit Add Data and browse to where the file is on disk.  In the Add Data dialog your .asc file should already have a raster dataset icon. If you don't want the data in that format, just use the Copy Raster tool to change the format. Regards, Eric ... View more

So if I specify that the max Z-tolerance is 0.1, shouldn't I expect that the max difference in elevation at any given point between the DEM and the TIN is 0.1 feet? Hi Joe, The answer to that question is no.  What you should expect though, is that at the cell center the value of the input raster and output TIN will have similar values that are within the z tolerance. I used the default behavior (1/10 the z range of the DEM), which for me is over 300 ft and my TIN and raster values are nearly identical. For example, my TIN is 1477.044 and my DEM is 1477 (its an integer DEM).  Another area I spot checked had the TIN at 1545.104 and the DEM at 1545. Raster To TIN first generates a  candidate TIN using sufficient input raster points (cell centers) to  fully cover the perimeter of the raster surface. It then incrementally  improves the TIN surface until it meets the specified Z tolerance. It  does so by adding more cell centers on an as-needed basis during an  iterative process.  It will not arbitrarily add more points to "improve" the surface given the input. If you are using Identify to compare the raster and TIN, but not clicking on the cell center then you should not expect the values to be within the tolerance.  To check, you can go to the symbology tab of the TIN and click Add on the left side.  You want to add the renderer at the bottom called, "Nodes with the same symbol".  These nodes should align perfectly with the raster cell centers. Turn off the elevation renderer on the TIN so only the nodes are displaying. Overlay the nodes on top of the DEM and zoom in pretty far, until you begin to see individual pixels.  Using Identify, click on the point to compare the two surfaces.  Please let us know if you still see erratic  results.  You should also click in between nodes to see how the triangle faces are arriving at their interpolated values and note the values of the raster in between the nodes. Best Regards, Eric ... View more

Hi Anna, You can do this with Zonal Statistics as Table.  You just need to make a model that uses the Iterate Feature Selection iterator so that each of the overlapping polygons is passed into the zonal tool individually.  You'll get an output table with 1 record for each polygon, then you run Merge to put the rows all back into one table.  Then you join back to the polygons using the Zone Field you specified in Zonal Statistics as Table.  Technically, you need two models.  One that does the iterations on Zonal and collects all the values (the tables), and one that does Merge.  You only want to execute Merge once, so this will be your main model, and the iterating model will be the sub-model.  Please review the section called, "Advanced use of model iterators", within the help topic, Integrating a model within a model. Best Regards, Eric ... View more

Leigh, I'm sorry, but that is not what you want to do.  You may be able to visualize your TIN by setting a vertical exaggeration to a small number, but the validity of your surface is compromised from the beginning because you built it using data in a GCS.   Delaunay triangulations are not valid when constructed using angular coordinates from geographic coordinate systems.  A TIN should be constructed from data in feet, meters, not decimal degrees. What is a TIN surface? Please project your point data into something that uses meters (since your z is in meters), like UTM, Albers, etc... Then reconstruct your TIN.  When x,y,z are all in meters you don't have to worry about z factor.  It will be 1.  If the surface is flat relative to its extent, you can use vertical exaggeration to show more relief. Perhaps a value of 2.5 or something. About Vertical Exaggeration Best Regards, Eric ... View more

Mike, Hillshade is black and white.  Shaded Relief is a colored hillshade basically. Eric ... View more

Multiplying the data by 10 or 1000 is legitimate to do, but it's easier to just add 0.5 to your raster prior to running the INT tool. This ensures you get proper rounding (regardless of percent slope/degree slope). The INT tool doesn't do any rounding. It simply truncates the values to the right of the decimal. ... View more

Hi Harry, Very interesting.  I did some testing this morning with Tiff and FGDB rasters along with FGDB points in the Sample tool.  I output my table back to FGDB and to DBF.  I even put rasters of different resolutions into the tool to force resampling behind the scenes (GRID creation) and in all cases I got the correct field names.  The only exception was going to DBF which truncated my longer raster name since DBF has field name length limits.  I continued testing in ArcGIS 10.1 (internal still) and got the same results as 10.0 sp3.  Perhaps you could submit a incident to Esri Support, supply your data and workflow, and we can try to reproduce.  I consider your result a defect. Best Regards, Eric ... View more

The issue is with the construction of the lines or data - not sure. Maybe it would be best if we spoke? Some of the lines that look like single lines are indeed 2 or more lines that are only millimeters apart. Intersect and Feature to Line have an XY tolerance settings. I may need to play some more with those settings. Are you supposed to have nearly coincident line work only mm's apart? I inspected my intersection points (created from Feature to Line result) for one area and found that the points do not align with the original line work from Points to Line result. Its almost 4cm shifted indicating the tolerance settings are key. Note, Intersect is giving the expected output given what I've thrown at it so far. Regards, Eric ... View more

If you fix your .csv file then you will not encounter this at all after you planarize the lines. ... View more

Per Nathan, "I definitely agree it would useful, but didn't make 9.4 dev. Sorry."   ArcGIS 9.4 eventually was renamed ArcGIS 10.  Since you are using ArcGIS 10, there is no option to view a previous extent.  ArcScene 10.1 Beta does not have this available either.  I'm not sure if it is planned for the final 10.1 release. Regards, Eric ... View more

It sounds like you need to apply the Shaded Relief Function instead of the Hillshade Function on your mosaic dataset. -Eric ... View more

Hi Kyle, Take your lines, and input them into the Feature to Lines tool. Take that output and intersect it with itself. The result is much better than splitting the lines by vertices. Feature to Line will essentially planarize the lines and remove overlapping lines. Because of this you will still have some undesirable points of intersection as noted in the screenshot (the points left of the grid pattern). It should be a lot easier to clean these up compared to your previous result. Regards, Eric ... View more

Greetings, You can only convert integer rasters into polygons.  Slope is typically 32 bit floating point data unless its already been reclassified.  The first bullet in the Raster to Polygon documentation indicates the input must be a valid integer raster dataset. Regards, Eric ... View more