Latest Contributions by curtvprice

Wade, Parse Path is new at 10.0 and a very nifty tool that avoids you having to get into Calculate Value and python coding like the example I posted to do that simple task. ... View more

Can you point me to some documentation, or examples of the expression syntax similar to that above.  I'm wanting to do something similar but strip off the last 4 characters of %Value%.  So if %Value% = raster.tif, I want to use %Value% plus an expression to get raster.shp You need to get familiar with the basic Python syntax for handling strings. I'd start with the Python tutorial. (All the basic Python string handling is early in the tutorial.)  Esri has some nice python training on the training.esri.com, free and not-free. And, for use in ModelBuilder, the Calculate Value tool reference. There is a great series on the ArcGIS blog on taking full advantage of ModelBuilder's capabilities here: ArcGIS Blog: If you are stuck at "if" (3 parts) Now, to your issue: The safest way to strip off a file extension is to use the Python os module's os.path.splitext: >>> import os >>> os.path.splitext("e:\\work\\image.tif")[0] 'e:\\work\\image' Using Calculate Value - you need a code block to use the os module: Expression (mind the use of "r", quotes and the "%" variable delimeter) f(r"%path_element%") Code Block: def f(path):   import os   return os.path.splitext(path)[0] ... View more

one more (and hopefully last) question - why is it not possible to put a parameter to the MakeRasterLayer_management out_rasterlayer field: for example: rasterPath = arcpy.Describe(files).catalogPath rasterName = "test" arcpy.MakeRasterLayer_management(rasterPath, rasterName) i get this same Execution error 000582) [000582 : Error occurred during execution.] I don't know why it's failing for you. This has always worked for me. In fact I usually do it that way... are you sure that's where your script is failing? 000582 is an extremely generic error. Did you get another error message as well? ... View more

You probably want to use catalogPath instead of name. You also want to strip off any extensions on the input raster name so the .lyr file name will be valid: import os arcpy.env.workspace = targetPath for files in arcpy.ListRasters():     rasterPath = arcpy.Describe(files).catalogPath     arcpy.MakeRasterLayer_management(rasterPath , "lyrRaster")     arcpy.SaveToLayerFile_management("lyrRaster",         os.path.splitext(rasterPath)[0] + ".lyr") ... View more

Seems a simple "behind the scenes" search cursor to pull out the appropriate "VALUE" field values (the "VALUE" values that match the dot notation query) would be what needs to happen... as I am guessing this is how the old dot notation worked with INFO tables. Yes, but the cell value had to be pulled cell by cell (or block by block if you were lucky and your grid was simple). I pushed for the grid.item syntax too because then the field would be a property of the raster, very pythonseque -- but I'm guessing this was difficult to implement. Remember in grid and in 9x they were only (really) supporting one raster format, now we have native read-write which makes some things better for us -- but I'm sure it complicates the development picture. The local operator stuff I was talking about has to do with ALL local operators. From what I've heard from the raster team, Lookup, being a local operator, should not have to create a real raster if it is embedded in a map algebra expression of only local operators. I guess I'm not as wound up about this, the way I see it is the 10.0 map algebra changes are not all bad news -- native read write is nice and leveraging python is great, and I'm all for one syntax replacing three (SOMA, MOMA, Raster calculator) each with its own set of quirks. But I sure wish Lookup supported joined fields and entered a incident with support on that. If grid.item is not feasible, I can live with that, but if so, Lookup needs more work. I put an incident request in on that. (UPDATE: Esri tells me it should be supported, hopefully they can reproduce my problem and we can fix whatever I'm doing wrong...) I don't miss docell at all, but if I need it, workstation (and SOMA nad MOMA, if you're willing to open a 9.3 GP in your python script) still work in Windows 7, so I'm good until retirement 🙂 ... View more

  Too bad it now takes a way longer time to execute now that it has to extract the "CANCOV" and "STNDHGT" fields to seperate grids... When all it actually needs to do is build a cross reference table between the user-specified field value and the "Value" field, which is what the old "dot notation" syntax did. Lookup is a local operator, so I'm not so sure why they are creating a temp raster -- in theory they shouldn't have to -- are you sure it's doing this? MOMA is much faster with this kind of thing because it didn't have to support projection on the fly or multiple formats. I also discovered today that Lookup does not support joined fields -- which is too bad! ... View more

I could reproduce the issue.   I appreciate you checking it out. If you can post or send me the NIM# I'll make sure I get a "vote" in on getting it fixed. An interface approach that makes sense to me and not break what's there already would be to allow the data source to include feature dataset "in-gdb path"  in the argument, i.e. "covername/polygon". If you just provide a feature class name, it would continue to do what it does now and look through all feature classes until it found a match. Seems this problem was created back in 1999 when the ArcGIS developers designed how coverage feature classes are represented in ArcGIS paths. The form "covername\covername_polygon" is more verbose, but would have preserved unique feature class names in the arcinfo workspace. ... View more

Perfect answer. Well, thank you. I want to add that one of the really nice advantages of arcpy is it allows use of intellisense using your IDE or the ArcMap python command line to easily solve these kinds of problems at "coding-time" instead of "run-time". I still have to use arcgisscripting to maintain script tools that support 9.x and 10.x and I really miss the intellisense there! ... View more

The PCs are running the same version of ArcGIS with the same service pack and also the same OS.  Are all tools drawing with this weird style or just Spatial Analyst tools? I'm wondering if Spatial Analyst is installed on the machines that are coming up strange. ... View more

. First, I am unclear as to what type of signal is passed to the script that enables ESRI to terminate it, and second I am not sure how to detect the event and then run a clean up based on this signal. Back then in 2007 (I think this is the post) was a while ago. I think the glue is much better now. I'm pretty sure what's passed now would be arcpy.ExecuteError like any other tool failure. You can trap for that exception class, but you would then want to search the error message strings for error codes from the arcpy.getMessages() array to verify the cancel was what generated the ExecuteError. I'd just try it with your script to find out which particular error code pops up from your cancel, in case it depends on context in your script. For example, if you get error 080522 you would scan through the messages for the text " 080522:". Update: I tried it this morning and it's true, if a tool isn't running when Cancel is pressed, the script process just dies, with no error message or anything saved in the results. That's not good as it looks like ArcGIS is just zapping the subprocess with a kill. I have no advice, sorry, and hope someone (from Esri) can chime in that knows some of the internals here. I believe I might be able to use win32api, but I have not figured it out yet. For example: win32api.SetConsoleCtrlHandler(func, True) I believe this was non-trivial on Windows platforms in the past, but Python 2.6 includes a nifty Popen.kill() method on the subprocess module. ... View more

So, my diplomatic, respectful of Python question is: What am I doing wrong? Is it in the output file command? The error makes it seem it's from the input. Your script is changing arcpy.env.workspace to the output location and your feature classes are not there -- they are in the workspace set when you ran arcpy.listFeatureClasses().  Don't change the workspace and your fc's should be found fine, since you are specifying the full output path, you should be good to go! Or, specify the full paths for the input feature classes: inFC = os.path.join(inWS,fc) ... View more