Latest Contributions by curtvprice

Our workaround to save a little time is to have two scale bars in our styleset, one for the rake with tics up, one for tics down. This saves some time, but it is still a pain, since we need to do this for every published map and figure! ... View more

One way you can approach this with your users is to set up a map template for them to use on startup. The available extensions are stored map templates (.mxt's in 931, .mxd's in 10.0) As for license level (ArcView/ArcEditor/ArcInfo) this is set using desktop administrator, so it isn't session-specific. A quick workaround you can do is set up a bat script that overrides the Desktop Administrator using environment settings. 24633 – HowTo: Change the ArcGIS Desktop seat type for Citrix or restricted permissions environments http://resources.arcgis.com/content/kbase?fa=articleShow&d=24633 14424 – HowTo: Add the ESRI_LICENSE_FILE or ARCGIS_LICENSE_FILE system variable http://resources.arcgis.com/content/kbase?fa=articleShow&d=14424 17970 – FAQ: Why doesn’t the ArcGIS Desktop Administrator allow switching of software types or thelicense manager? http://resources.arcgis.com/content/kbase?fa=articleShow&d=17970 ... View more

Hi all, I'm trying to use Map Algebra/Raster Calculator on some tiff files, all of which are identical in properties but for cell values.  I keep getting an unidentified, unexpected error.  Am I wrong and tiff files don't work in raster calculator?  I converted 2 of them to GRID and tried a simple operation and no luck.  TIFF files work best when the values are limited to 8 bits (0-255). Beyond that bit range sometimes different software treats the values slightly differently which can lead to value conversion issues. I recommend examining the grids and see what the values in the grid version of the files are -- look at the raster statistics, and the raster table (if integer) and also maybe poke at the grids with the identify tool. Hopefully that will help figure out what's going on. Arc 9.3.1 converts the TIFFs to grids behind the scenes before any map algebra is run. The behind the scenes conversion (using defaults) may be failing for some reason. The second issue is georeferencing and coordinate systems this are sometimes specified slightly differently by different TIFF generating software. Since you say the TIFFs are identical except for the values, it sounds like this is less likely to be your issue. ... View more

Both rasters are single band. Both have the same geo (wgs 1984) and projection (albers conical equal area). They have also the same cellsize. Both are imagine format. However one is continious 32bit and the other is discrete 8 bits. Is that a problem? Hm....what can i do? At 9.3.1, raster analysis happens only with grid data sets. Behind the scenes the raster data sets are converted to grids (in your scratch workspace or a folder, in temp, if your scratch workspace is a gdb). My experience is you can sometimes have better luck with analysis if you convert the inputs to ESRI grid format. (In your case I'd define the raster coordinate system after the conversion just to be sure they are defined the same.) In 10.0 the tools work natively so you are less depending on a behind-the-scenes conversion to work correctly. If you are using 10.0 I'd still try the grid format as grid and raster gdb are the "native" formats for raster tools and are likely to work the best and fastest. ... View more

Seems to me the best approach would be calculate aspect and slope, and then build a map algebra expression (using basic sin/cos trigonometry) to separate the slope in to X and Y components using the aspect. I would be very careful as to which coordinate system you use so the X and Y will "make sense" (for example so "north" will be "up"). Does this help? ... View more

Hi - I have a raster showing locations of beaches along a reservoir that is currently all classified with a single integer value. I need to assign elevation values to my beach zones from a much more extensive underlying DEM. You didn't say which version of ArcGIS you're using, but this kind of think is easily done using map algebra in its various incarnations, for example, if your beach areas are value 1, Con(BeachRas == 1, DemRas) will create a raster that is nodata everwhere but on the beaches, and in the beach areas you will have elevation values. ... View more

1) If you don't have a good reason to do otherwise, the file geodatabase (.gdb) is a much better choice than .mdb, which although includes much of the same functionality, is more limited and many quirks compared to the file geodatabase. 2) You may want to set the XY domain by creating the feature class before you load the data. You can control the maximum coordinates by altering the resolution (which is the coordinates used -- different than the XY tolerance used for geoprocessing) Here's the online help page on this topic http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//003n0000001z000000.htm 3) Are you sure you are working in projected coordinates? -400 to 400 doesn't sound like a projection I'm familiar with... ... View more

That is a clever approach when the data are in a point layer.  Has ESRI now implemented IDW for raster data?  I hadn't heard. Not to my knowledge, but you could always convert your input cells to point features. A third approach is to run euclidean allocation from an integer raster that can be joined to a table with the  floating-point values: a) eucallocation b) join tables c) use the Lookup tool to create a new raster from the floating-point values in the joined table. Note, if you're filling in "seams" in a floating-point grid, to prevent abrupt boundary faults IDW may be a better tool than euclidean allocation (or its more complex friend, the Nibble tool). An approach i've used for this is: 1) convert nodata holes to zones: HoleRas = Con(IsNull(InRas),1) 2) Expand by a couple of cells HoleBufRas = Expand(HoleRas,2,[1]) 3) Tear out the hole: RingRas = Con(IsNull(HoleRas == 0),HoleBufRas) 4) Convert this raster to points, set the mask to HoldBufRas 5) merge the IDW results with your input ... View more

Hi All, I am having a problem with using a variable as the output cell size for the Feature to Raster tool in Model Builder.  I have tried using both a raster layer as the variable, as well as a cell size variable defined as a parameter for the model.  So far the only way I can get my output raster to have the correct cell size is to hard code it into the tool dialogue, which I am trying to avoid.  I have tried about every possible thing I can think of including changing the environment settings and nothing is working.  Please help! Daniel You should be able to set the cell size in the environment of the model or of the tool in the model. Note that environment settings take priority as follows: Script > Tool > Model > Application So, for example, if you set a cell size in the ArcMap environment ("Application") and inside your model you right clicked on the tool and set a different cell size there, that takes priority. However, if you set the cell size for the feature to raster tool with a variable, that should be the same as typing it into a dialog - and that will take precedence over the environment. The best way to check this is to look at the dialog while the model runs - this will show you exactly what arguments the tool is recognizing. BTW, You may want to try the newer tools (polygon to raster etc) as they provide more control over the conversion process. ... View more

We recently published a toolbox that does just this you may want to check out. Unfortunately these were developed on 9.3.1, and most of the tools do not work at 10.0 yet -- but I'm working on it! National Water-Quality Assessment (NAWQA) Area-Characterization Toolbox http://pubs.usgs.gov/of/2010/1268/ UPDATE: more current version National Water-Quality Assessment (NAWQA) Area-Characterization Toolbox v2.1 https://www.arcgis.com/home/item.html?id=29707fb7f1664538871c65d7e1d9612e  ... View more

Have you looked at your processing environment (set in the SA toolboar - not the geoprocessing settings, which are totally independent of the toolbar). I recommend doing this the new way, from the toolbox (in 10.x the toolbar functions like this are gone -- you have to use the tool to do zonal statistics). There are two main reasons to do this the new way (toolbox) even if you are still at 9.3.1: 1 - the GP environment is better (includes things like the Snap Raster) 2 - You can use the toolbox Results tab (Geoprocessing -> Results in Arc 10) to rerun it when things go wrong. ... View more

Another approach is to use the IDW interpolator, using the options to only allow one point to be used to estimate the output value. ... View more

Here's what works in Raster Calculator: focalsum(Not(IsNull([IndicatorRaster])),RECTANGLE,7,7) In MapAlgebra, I get a 'Not is not a valid operator' error.  Clearly the parser doesn't like that, but here's a workaround: the rule for boolean is zero is false, anything else is true. In your case, IsNull converts NoData cells to 1, and other cells to 0. So the following map algebra is functionally equivalent: focalsum(IsNull([IndicatorRaster]) eq 0,RECTANGLE,7,7) ... View more