Latest Contributions by ChrisSnyder

‎03-08-2013

Another option: Use this tool (http://arcscripts.esri.com/details.asp?dbid=16700) or a similar methodology to "flatten" the overlapping polygons and use the optional lookup table in a cursor to traverse/analyze the overlapping regions. After flatteneing, you could rasterize the flattened output and use the lookup table with the raster (or the original polygons). I've been contacted by a few people over the years that use this tool for fire stuff - for example: http://www.google.com/url?sa=t&rct=j&q=superregionpoly&source=web&cd=6&ved=0CFgQFjAF&url=http%3A%2F%2Frepository.lib.ncsu.edu%2Fdr%2Fbitstream%2F1840.4%2F4125%2F1%2FKetchieChris%2Bfinal.pdf&ei=Rxw6Ue2ZOoWNygHowYBo&usg=AFQjCNGg226JbsuLyKe-KaPKWm33boc2pQ&bvm=bv.43287494,d.aWc

‎03-07-2013

Since it's a year value, it may be "cleaner" to ensure your FIRE_YEAR field is an integer value, but I think a text value "should" work as well. Maybe I'm missing something, but I'm not sure what combining the same attribute from the same raster will accomplish. Are these two different rasters? Combine(Lookup("testy_fire_1988","FIRE_YEAR"),Lookup("testy_fire_1988","FIRE_YEAR")) Normally the Combine tool is used to basically intersect two or more different rasters. The output is a single raster composed of at least three fields: one field for the VALUE of the new raster, one for the original VALUE of the 1st input raster, and another for the origional VALUE of the 2nd input raster.

‎03-06-2013

I've never used Iron Python, but that may be a likely reason things are going wrong for you. For what it's worth, my PATH variables/values: PATH = c:\oracle\product\11.2.0\client_1\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Python27\ArcGISx6410.1 It's interesting to note that my PATH (but only after I edited it to include a ref to C:\Python27\ArcGISx6410.1) is the ONLY envr system varaiable that makes reference to anything Python. I assume everything else is handled in the registry... My machine is only a few months old, and has only had ArcGIS v10.1 and Python2.7 installed on it (no other older versions). My other machine (that is several years old and had several versions of ArcGIS /Python on it) has tons of refernces to Python in the system envr variables. Hmmm...

‎03-05-2013

That error message (ImportError: DLL load failed: %1 is not a valid Win32 application) sounds familiar: http://forums.arcgis.com/threads/78704-Python-subprocess-module-and-64-bit-background-geoprocessing-in-v10.1?p=276831&viewfull=1#post276831 I fixed my issue (which may be a bit different from yours) by permanently including a 'PATH' envr variable pointing to the 64-bit Python directory (Note that PATH does not include a ref to the 32-bit version directory). My Python window in ArcMap loads arcpy (32-bit) just fine... but I never noticed that it didn't.

‎03-05-2013

To get the extent xmin bound of the entire layer: arcpy.Describe("Layer").extent.XMin To get the extent xmin bound of each feature in the layer: searchRows = arcpy.da.SearchCursor("layer",["OID@","SHAPE@"]) for searchRow in searchRows: oidValue = searchRow[0] xminExt = searchRow[1].extent.XMin print "OID = " + str(oidValue) + " has an xmin extent of " + str(xminExt)

‎02-28-2013

Hi Luke, Your code: env=os.environ.copy() env['PATH']='%s;%s;%s' %('C:\\Python27\\ArcGISx6410.1',env['WINDIR'],env['WINDIR']+'\\system32') proc=subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE,env=env) worked great.... I specifically traced the problem to a lack of PATH = 'C:\\Python27\\ArcGISx6410.1'. I went ahead and appended 'C:\Python27\ArcGISx6410.1' to my system envr PATH variable permanently, and so now no need to pass a custom env definition to the subprocess. Not sure why just changing PYTHONPATH wasn't sufficient, but I guess there must be some envr variable hierarchy in there. Anyway, my arcpy subprocess scripts are grooving again - this time in 64 bit arcpy land. Thanks a million!

‎02-28-2013

As far as I know, you can't directly perform linear regression (or other types of regression) in ArcGIS. You would have to: 1. Code the regression it yourself in Python or some other language that ArcGIS will interface directly with. 2. Use R or Excel, and then apply the derived equation using a Python cursor or some other data automation technique to put the new points in teh proper location. What is the phenomenon you are trying to predict? If you gave more background on the topic, you might get more/better feedback. For example, is it expected that the the future point locations will always be to the east of the previous point? Can you expect the rate of change to increase (get faster) or decrease (get slower) over time?

‎02-27-2013

I have a script that relys on the 'subprocess' module to basically run seperate instances of arcpy as a parallel process. After installing the 'ArcGIS_BackgroundGP_for_Desktop_101sp1.exe' 64-bit geoprocessing package I have both the 32-bit and 64-bit versions of Python 2.7 on my machine. Both versions of python will import and play with arcpy just fine. However, when I attempt to launch a subprocess of arcpy with a 64 bit version of Python, the subprocess script fails upon attempting to import arcpy with the following error: C:\Python27\ArcGISx6410.1 Python Traceback Info: File "\\snarf\am\div_lm\ds\gis\projects\lidar_hydro_all \lidar_hydro_child_v101.py", line 7, in <module> import arcpy Python Error Info: <type 'exceptions.ImportError'>: DLL load failed: %1 is not a valid Win32 application. The subprocess call is to the 64bit version of Python, and I have verified that this is the exe that is launching under subprocess. The subprocess call I am making is: subprocess.Popen(['C:\\Python27\\ArcGISx6410.1\\python.exe', '\\\\snarf\\am\\div_lm\\ds\\gis\\projects\\lidar_hydro_all\\lidar_hydro_child_v101.py', 'C:\\csny490\\lidar_stream_build_new', '16'], shell=False) Funny thing is that the 'lidar_hydro_child_v101.py' script (the import arcpy part) runs just fine stand alone in 64-bit and/or 32-bit Python, but just not when called as a subprocess. My feeling is that for 'some reason' even though I am running the script from 64-bit python and launching the subprocesses as 64-bit python, when arcpy is being imported in the 64-bit python.exe subprocess, arcpy thinks that it is in 32-bit land still... Trying to fix things, I added a PYTHONPATH environment variable (which curiously didn't previously exist) that points to 'C:\Python27\ArcGISx6410.1', but that didn't do the trick... I haven't uninstalled the 32-bit version of Python, but that's my next step... Any other ideas?

‎02-22-2013

Decided to finally install and test out the new 64 bit geoprocessing upgrade for 10.1 SP1. Works like a charm (except for the whole 32-bit exceptions thing, but that's okay and understandable... I never liked PGDB anyway!). Note the RAM usage in the attached screenshot (~27 GB max in use). So I can now have my huge Python dictionaries and eat arcpy too. I bet this was Jason S.' idea - thanks for implementing :). [ATTACH=CONFIG]22090[/ATTACH]

‎02-05-2013

Yes, I could submit some repro data... but more importantly I just want to raise the issue that there is likely a more of a systemic issue going on here though that doesn't involve just a single tool.... I belive the the 'NoData' horizontal banding issue is likely a symptom of some change that was made to the SA tools back in v10.0. I have seen the same basic issue with RegionGroup, Eulcidean Allocation, and now ExtractMultiValuesToPoints. Seems that it's only a problem when running 'largerish' datasets. My fix idea for the day (tiling the ExtractMultiValuesToPoints job into tiles) worked - and it's faster that running the whole thing at once doe to large areas of NoData pixels in my input rasters... So I guess it's a win-win sort of. My worry is that there may be a bunch of other SA tools that may be exhibiting the 'NoData' horizontal banding issue - I just have yet to notice them.

‎02-05-2013

In v10.1 SP1 I found that the 'ExtractMultiValuesToPoints' tool, when exucuted on "large" datasets sproatically assigns NULL values in weird horizontal stripped patterns - very reminicent of the issues that had been reported here with RegionGroup and other SA tools. Funny, because I had started using the ExtractMultiValuesToPoints tool instead of the Sample tool due to a bug with Sample (Sample tool bombs on large datasets - which looks to be fixed in v10.1 SP2). My immediate work around is to.... break the analysis up into samller pieces (tiles).

‎02-04-2013

Like Kim was saying... use the win32com module to give Python access to your form: from win32com.client import Dispatch strDbName = 'my_database.mdb' objAccess = Dispatch("Access.Application") objAccess.Visible = False objAccess.OpenCurrentDatabase(strDbName) objDB = objAccess.CurrentDb() objAccess.OpenForm('my_form') You should be able to drill down even farther to the actual form objects... for example, interactively populate the form's lat/long info. It works just like VBA once you have a COM hook into the objAccess.

‎01-31-2013

Create a rectangular FC with the same extent (or larger) as the water FC (you can use this tool to do that: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00170000003q000000) . Erase (use the erase tool) the water FC from the rectangular one. Use the MultipartToSinglepart tool if you want all the islands as individual polygons. You can use this same process to go from land to water.

‎01-23-2013

Are you using cursors? If so, be sure to delete your cursor objects: #in v9.3 and v10.0 try: searchRows = gp/arcpy.SearchCursor(blah, blah) for searchRow in searchRows: blah del searchRow, searchRows except: del searchRow, searchRows In v10.1 you can use the with statement with the new .da cursors to ensure release of locks: http://resources.arcgis.com/en/help/main/10.1/index.html#//018w00000011000000

‎01-19-2013

I have a script tool (not an add-in) that gets raw interactive point input from users using a parameter with a 'featureset' data type. Technically it works, but with one pretty major performance issue: When users start up the tool, there is a longish delay (3 seconds or so) as ArcGIS auto-creates .gdb file in my TEMP directory in which to store the user-defined points (called something like C:\Temp\arcC593\gp273D19A103704209BEA5FF7DAA478784.gdb). Every time the tools is run, a different .gdb file is created, and tool start up time gets longer and longer with each new scratch .gdb in the TEMP directory. After 10 runs start up time is around 10 seconds. Is there any way to get the featureset to point to an in_memory featureclass instead? I've tried everything (env variables, etc) I can think of... I would be happy if I could even get it to point at the guaranteed Scratch.gdb! I thought featuresets were supposed to be a 'lightweight' representation that exists in RAM, but the script tool implementation of creating user-defined interactive featuresets seems to be as heavy and clumsy as an elephant on a pogo stick. Am I missing something?

Online Status	Offline
Date Last Visited	‎08-30-2024 12:25 AM

My Ideas

Latest Contributions by ChrisSnyder

Re: Lookup function in v10.0 Map Algebra: implementing dot notation in v10.0?

Re: Lookup function in v10.0 Map Algebra: implementing dot notation in v10.0?

Re: Problem importing arcpy in ArcMap console -- 64 bit DLL conflict

Re: Problem importing arcpy in ArcMap console -- 64 bit DLL conflict

Re: Row.shape and .extent

Re: Python subprocess module and 64 bit background geoprocessing in v10.1

Re: point prediction

Python subprocess module and 64 bit background geoprocessing in v10.1

Re: Large Dictionary Compression?

Re: Problem running Region Group tool

Re: Problem running Region Group tool

Re: How to create a form

Re: Create land polygons from water polygon layer

Re: ArcSDE/Oracle connection management from Python

Force script tool featureset default location to use in_memory workspace?

Re: How to determine number of records using arcpy...

Re: how to install pywin32 for ArcGIS Pro 3.x

Re: Trouble installing Pythonwin in Pro 3.3.1

Re: Adding html link to AddMesage

Re: Python Copy_management throws exception "ERROR...