Latest Contributions by curtvprice

  Could you clarify where and how [validation] code gets applied? No, tool validation before your main script runs (that's the idea!) - the code is edited in the script tool properties/validation tab. If you have made the jump to Python toolboxes, the tool validation class is in a separate area of your code. (I still like doing it the old way -- less work!) ... View more

I put a [noparse] [/noparse] around your code above so it would display correctly. The tool only supports a single value raster input. Have you tried Zonal Statistics As Table? If you use that tool, you could join the twelve output tables using the Join Field tool. Hope this helps. ... View more

Ally, Integer rasters [post=297376]don't always have the attribute table built[/post] depending on the range and number of values. This was true in 9.3 and it is still true. You may need to run the Build Raster Attribute Table tool to get one. (If there is one there already, no harm done.) ... View more

We have had problems with this too -- for regular users -- here's the NIM we have logged: [#NIM066910  A script run from Task Scheduler with the setting "run whether user is logged on or not" fails to initialize ArcPy when the license is single-use. ]  No workaround identified for version 10.1. At 10.0, a workaround was to have a concurrent license available for arcpy to load. Glad to hear this may be finally fixed at 10.2; it's a real show-stopper of a bug. I will definitely test it first time I get a chance. ... View more

Such a button would only become active when the validation was successful (along with the OK button). ... View more

Hi Jamal. Raster attribute tables are not automatically built for integer rasters in some situations, for example, your case of having many integer values of large magnitude. You may have to run the Build Raster Attribute Table tool. If the table is there already, it won't hurt anything. One more thing: you may need to go into the raster layer's symbology tab to modify the renderer to display the integer values in the legend. For grids, a raster attribute table is built by default for any integer grid that results from an expression if the range of values in the raster is less than 100,000 or if the number of unique values in the raster is fewer than 500. If the range is less than 100,000, the number of unique values in the raster can be as large as 100,000. If the range is greater than 100,000, a raster attribute table will still be built if the number of unique values is fewer than 500. If the range of values is greater than 100,000 and the number of unique values is greater than 500, a raster attribute table is not automatically built. Desktop 10.1 Help: Raster attribute tables ... View more

I fixed the link above. Don't like it that the post number changed -- I thought those were permanent links! ... View more

   The best workaround I found in that environment was to compute flow accumulations for constant direction grids (and unit weights): $$ColMap is the flow accumulation of a grid filled with 1's and $$RowMap is the flow accumulation of a grid filled with 4's.    I did an implementation of this idea in arcpy map algebra here: arcpy map algebra $$ROWMAP, $$COLMAP​ ... View more

Sorry.  I forgot there are several iterator choices.  Yes, it is a feature selection iterator that would iterate selections based on your owner name values. Desktop 10.1 Help: Iterate Feature Selection ModelBuilder @ 10.x has become a very useful tool for personal workflows like this! ... View more

Hi Peter! Yes, that's a big raster: 34651 * 24934 * 4. / ( 1024 ** 3) > 3.2 GB uncompressed. The fact that the tools are not failing is a great credit to Esri's GP team. (Well done, folks!) I've used the Flow Accumulation tool within Arc Hydro, the Flow Accumulation tool within the Spatial Analyst Extension; Hydrology Toolbox as well as tried running it from Python hoping for better processing time. In 10.x, the same actual raster tools run, whether you initiate it from a tool, model or Python, or even ArcObjects "Op" interfaces. (Although this takes away some options from 9.x, I'm happy to be free of the complications-- although if desperate you can still get to MOMA - with its many limitations -- through arcpy.gp.) So I don't expect any improvement there. The Flow Accumulation algorithm that is being used seems to be hard coded in that it doesn't use any more than 2 GB memory when processing the Flow Direction GRID to generate the Flow Accumulation GRID. This has to do with that the tools are developed and usually run in 32-bit, so you are limited with how much direct-access memory can be addressed at one time. Two things I suggest trying (using a small test area!!): 1) If you have 10.1 SP1 installed, and are running Win7-64, try running the tool using x64 Background Geoprocessing. (Or more directly by running your script from 64-bit Python/arcpy.) It's possible the Flow Accumulation tool has been modified in 64 bit to use more RAM. 2) Test using other raster data types and see if the performance varies. Since GIS processing is often I/O dependent, different datatypes sometimes work better with different tools, due to how the process interacts with the particular data structure. Candidates I'd compare first would be grid, file gdb, .img, and .tif. (For example, I have heard that Flow Direction is quite zippy for .tif output.) For best performance (you just be doing a lot of thrashing between memory and disk) you may be forced to tile your processing into basins (by building watersheds from your flow direction raster). The NHDPlus folks have taken this approach when hydro-processing DEMs for the continental U.S. Hope this is helpful. I'd look further into the NHDPlus docs to see if anything in their approach can help you. ... View more

Hi Peter! Yes, that's a big raster: 34651 * 24934 * 4. / ( 1024 ** 3) > 3.2 GB uncompressed. The fact that the tools are not failing is a great credit to Esri's GP team. (Well done, folks!) I've used the Flow Accumulation tool within Arc Hydro, the Flow Accumulation tool within the Spatial Analyst Extension; Hydrology Toolbox as well as tried running it from Python hoping for better processing time. In 10.x, the same actual raster tools run, whether you initiate it from a tool, model or Python, or even ArcObjects "Op" interfaces. (Although this takes away some options from 9.x, I'm happy to be free of the complications-- although if desperate you can still get to MOMA - with its many limitations -- through arcpy.gp.) So I don't expect any improvement there. The Flow Accumulation algorithm that is being used seems to be hard coded in that it doesn't use any more than 2 GB memory when processing the Flow Direction GRID to generate the Flow Accumulation GRID. This has to do with that the tools are developed and usually run in 32-bit, so you are limited with how much direct-access memory can be addressed at one time. Two things I suggest trying (using a small test area!!): 1) If you have 10.1 SP1 installed, and are running Win7-64, try running the tool using x64 Background Geoprocessing. (Or more directly by running your script from 64-bit Python/arcpy.) It's possible the Flow Accumulation tool has been modified in 64 bit to use more RAM. 2) Test using other raster data types and see if the performance varies. Since GIS processing is often I/O dependent, different datatypes sometimes work better with different tools, due to how the process interacts with the particular data structure. Candidates I'd compare first would be grid, file gdb, .img, and .tif. (For example, I have heard that Flow Direction is quite zippy for .tif output.) For best performance (you just be doing a lot of thrashing between memory and disk) you may be forced to tile your processing into basins (by building watersheds from your flow direction raster). The NHDPlus folks have taken this approach when hydro-processing DEMs for the continental U.S. Hope this is helpful. I'd look further into the NHDPlus docs to see if anything in their approach can help you. ... View more