Latest Contributions by ClaytonCrawford

How large are the tins? If the sum total of nodes is a few million nodes or less than make one large tin. If you have the source data use it to build the tin. If all you have are the tins you can run the GP tools TinNode and TinLine to decompose them back into features and then use them to make the unified tin. If you have more data than can/should be used to build one tin consider using the terrain dataset. Clayton ... View more

So, you want to remove existing tin nodes (lidar points) from within a given distance of your surveyed point shots before inserting those point shots? Are point shots that comprise a single cross section closely and/or relatively evenly spaced? Are they closely spaced relative to the distance between cross sections? Are they ordered along the line from beginning to end or at least distinguishable (e..g., using some form of attribution or placed in separate files) from points that belong to other cross sections? Are cross sections relatively straight in XY? Would it be beneficial to turn those points into lines and insert them as breaklines? ... View more

Viewshed uses a raster specific algorithm so it can't directly support TINs/terrains. These data types need to be converted to rasters before they can be used by viewshed. We could have viewshed perform the conversion behind the scenes but we decided it would be in the user's best interest to perform this conversion explicitly and not overload the tool. Regards, Clayton ... View more

Sorry, a viewshed enhancement to include multipatches is not happening in 10. We'll have to consider it in a later release. Regards, Clayton ... View more

Sorry, I don't know of another way to do it. It's good to raise the issue because our 'solids' guys need to review the attribute transfer with tools like Intersect3D. It's hard because there can be n number of input shapes that overlap and are responsible for outputting a single shape. Regards, Clayton ... View more

Something doesn't seem right if each CAD face ends up as a separate feature/row in the geodatabase. Maybe it has to do with how the CAD entity is modeled or how the CAD data was imported/loaded into the geodatabase. I would try to figure that out first. Can you describe how the data is modeled in CAD and how it was imported/loaded int the geodatabase? Regards, Clayton ... View more

If your multipatches are closed we can calculate volume. Try the 3D Analyst Add Z Information tool. Regards, Clayton Crawford ESRI Software Products ... View more

Try buffering the lines, just a little, to make polygons. Extrude them to get closed multipatches (note - depending on the data used there's another known issue in beta 2 that these are not alwaays closed). Closed multipatches can then be used with the 'solid' set operators. Regards Clayton Crawford ESRI Software Products ... View more

Sorry, the error message is misleading. Up through beta 2 the tool does not support extruded lines. Support for extruded lines has been added at pre-release. Please check again when pre-release becomes available. Thanks for the report. Regards, Clayton Crawford ESRI Software Products ... View more

Was background processing enabled for GP when executing TerrainToRaster? There is a serious performance hit if that's the case - at least with beta 2 and probably beta 1. You may want to try another (smaller) example and see if you notice a difference when turning it off. In general, terrain related GP tools are not ready for prime time when it comes to background processing. We're hoping to have this addressed by pre-release. I'm curious about some of the data you're using and the terrain schema definition. Send me an e-mail if you have the time to describe this in more detail -> ccrawford @ esri dot com Regards, Clayton ... View more

Thanks for the report. We're glad you've seen improvement in robustness. Are you using linear or natural neighbor interpolation during rasterization? Regards, Clayton Crawford ESRI Software Products ... View more

What we found, and fixed for beta 2, was a problem related to deselecting the kind of graphic made by LOS (grouped with 3D geometry). Use the GP LOS tool as a workaround. Please re-test with beta 2 which will be available soon. Thanks for the report, Clayton ... View more

Thank you! ... View more

Wentao, Thanks for the questions and feedback. Making a DEM: The different pyramid filter options affect how data gets thinned and generalized. They do not affect the full resolution data. If you are only building terrains in order to create rasters using the full resolution data (TerrainToRaster pyramid resolution level set to 0.0) then it doesn't matter if you use windowsize or z-tolerance or what pyramid resolutions were specified when defining the terrain. Going on this assumption, I recommend using the windowsize filter since it's faster. You can also build the terrain using a much larger windowsize than 2 (e.g., 50), it will be faster. If, on the other hand, you want to rasterize using a thinned pyramid level instead of the full resolution level then you need to start thinking about pyramid type and pyramid level resolutions. If you choose to use windowsize, and might rasterize on a thinned pyramid level, or view the terrain at different display scales, and your lidar is bare earth, then I think the ZMean option is a good one to use. If you have first return lidar then I recommend ZMax. You can build a 1 meter DEM with a terrain made from any windowsize. The question is, what pyramid level are you performing the rasterization on? If your lidar is sampled at 1 meter, and you want to make a 1 meter DEM, then it really doesn't matter what pyramid type you use or the pyramid resolution definitions because when you run TerrainToRaster you ought to rasterize using the full resolution data by specifying pyramid resolution level = 0.0. I would not recommend building the 1-meter DEM using a coarser resolution pyramid level. On the other hand, if you wanted to make a 2-meter DEM from 1-meter lidar points, than rasterizing based on a 2-meter windowsize is reasonable. It will run faster, not just because of the larger cellsize, but also because you're processing a thinned point set. If your terrain's tilesize is always 447 it means you're always saying the point spacing is 1. The tilesize we use depends on the point spacing you declare. So, does all your lidar have a 1 meter nominal point spacing? If so, then this is fine. Out of memory The 'out of memory' error you got when building the terrain likely related to data density. The first thing to check is the point spacing used to define the terrain. Is it correct? What is the nominal point spacing of the lidar and is that the value used to define the terrain? Another consideration is breaklines. If you have very densely sampled breaklines these should influence your point spacing estimate. Are some areas of your terrain sampled more densely than others? If you're building a terrain from data that has different sample densities then you should specify the point spacing of the densest data when defining the terrain. For example, if an urban core is sampled at twice the density of the rest of the data used to build the terrain, specify the point spacing of the urban core. The terrain's tile system needs to be based off the densest data. If you think your data is of relatively constant density I suggest testing that to make sure. Do this using PointToRaster with your lidar multipoint feature class. Specify an output cellsize that's 4x the point spacing of your lidar. Use the COUNT option as the cell assignment type. Note that the value field doesn't matter when using the COUNT option. If your lidar has a 1-meter point spacing, and you COUNT on a 4 meter cellsize, then you would expect to see, on average, a value of 16 in the resulting raster cells. If this isn't the case, if there's a significantly larger count somewhere, this could explain the problem. Regards, Clayton ... View more

Wentao, There is no way to speed up TerrainToRaster while keeping extent, cellsize, interpolation method, and terrain pyramid resolution the same. The 9.3.1sp1 workaround for the out of memory problem may actually slow things down a bit but there's no way around that. You can speed up the terrain build process significantly using a windowsize pyramid filter rather than z-tolerance. This isn't going to be detrimental when using TerrainToRaster if you're rasterizing the full resolution data (i.e., pyramid resolution=0). The Natural Neighbors tool is limited by TIN. The answer to support larger datasets is terrain. I realize the terrain build process adds time but if you use the windowsize pyramid filter, and define just one pyramid level that has a large window, the build process is pretty fast. Regards, Clayton ... View more