Latest Contributions by ChrisSnyder

Large Address Aware: On a second look maybe there is another flag you can set just for Python that would make it so... Looked to me like it just wasn't linked to the global flag... That said, i don't have my stuff set up for it, but just have heard of others using it, so I was curious what others had experienced. I've never really seen exact ESRI-specific "how to" instructions for making all things ESRI GIS large address aware. Among other things, I would find the addded memory limits very usefull for the in_memory workspace as well as numpy-array type things. ... View more

Large Address Aware: I just assumed it was, but... for 32-bit version of Python 2.x (3.x too?), I guess not! http://bugs.python.org/issue1449496 Looks like Jason S. from ESRI has tried hard to make it so, but... The non-ESRI people in the forum link said something to the effect of "why don't you just have your wrapper program (aka ArcGIS) be large address aware". So maybe when run via ArcWhatever, Python would "act large adress awary"?? Dunno... "ArcGIS will go to 64-bit GP environment (not the entire application just the Geoprocessing environment) I was told that at the ESRI UC 2011 by an ESRI employee" Wow! I had "heard" that only Server was gouing to be native 64 bit, but whatever... The geoprocessing stuff is the only thing I really care about where I think gobs of memeory would actually do soemthing cool, so.... Cool! ... View more

I received Memory Error after the total footprint of all four processes had grown to about 4 GB Questions: 1) Are these individual processes that are uniquely discernable in the task manager? (example: 4 individual python.exe (or ???) processes?) Or a single instance? 2) If the latter,  I assume you are using the large address aware setting to get near 4GB (and a 64-bit OS, correct)? If so, have you noticed any drawbacks from using it? ... View more

How about the expant tool: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z00000036000000.htm It's basically a buffer tool for rasters. Then you could use some map algebra (the con function) to figure out the areas in you raster that overlap the expanded areas. ... View more

If it helps, here is a code snipit. Sorry I know it's pretty cryptic. If you only have a single input table, then the MakeFeatureLayer (or makeTableView) tool would be most appropriate. The added complexity of MakeQueryTable is only "worth it" if you are relating/joining multiple tables. The code below joins two tables to an input FC table and then outputs a feature layer that is the spatial result of the tabular queries. queryExp = "question_1_fma_summary.RMU_ID = rmu_polyid.RMU_ID AND rmu_polyid.RMU_POLYID = rmus_we_care_about.RMU_POLYID AND\ rmus_we_care_about.MM_POL_LBL = 'marginal' AND (\ (rmus_we_care_about.HCPUNIT_NM in ('S-COAST','COLUMBIA') AND question_1_fma_summary.COMPSOLD_DATE >= 20000101) OR\ (rmus_we_care_about.HCPUNIT_NM = 'STRAITS' AND question_1_fma_summary.COMPSOLD_DATE >= 20010501) OR\ (rmus_we_care_about.HCPUNIT_NM = 'OESF' AND question_1_fma_summary.COMPSOLD_DATE >= 20020501) OR\ (rmus_we_care_about.HCPUNIT_NM = 'N-PUGET' AND question_1_fma_summary.COMPSOLD_DATE >= 20011101))" gp.MakeQueryTable_management(question1FmaSummaryTbl + ";" + rmuPolyIdTbl + ";" + rmusWeCareAboutFC, featureLayerFL, "ADD_VIRTUAL_KEY_FIELD", "", "", queryExp) ... View more

Guess there's only one sure way to tell, but�?�  Do you guys have any ideas on how memory usage is doled out and/or recycled for multiprocess or parallel python? In days of yore many of us were forced to create separate processes (a separate python .exe) using spawnv or subprocess. Primarily, this was simply because the gp object (or arcpy) had some really bad memory leak problems, and any gp-enabled application (python.exe) would gradually run out of memory when running tools in a loop. As an added bonus, you could write additional code to �??manage�?� the separate processes as a psudo-paralle process. These gp/arcpy memory leak issues have been improved greatly, but are still a significant problem for �??heavy duty�?� geoprocesing�?� Anyway, I am curious if pp or multiprocess can somehow avoid these memory leak issues. In the pp example, I see that you hand the parallel process the same arcpy object that is instantiated in main. Do all the child processes use (and assumingly add to the memory consumption of) the same arcpy instance? In the mutiprocess I example, since I don�??t see such as explicit code as in the pp example, I assume the child processes by default just simply have access to all the global variables in main? I am theorizing that pp and/or multiprocessing will still suffer from gradual and catastrophic gp/arcpy memory consumption, but I can�??t wait to try some stuff out for myself. Thanks a million for putting these examples up!!! ... View more

Not sure what the problem was, but MakeQueryTable is more suited to complex queries involving multiple tables. ... View more

A speedier work around might be to buffer your point a bit and then use the buffer extent as the analysis extent to make an in_memory copy (CopyFeatures tool) of your SDE data, and then do a SelectByLocation on the smaller and local in_memory dataset. That way you are sort of making the SelectByLocation tool honor the analysis extent environment, which it would not normally do. BTW: Any features that overlap with the analysis extent will be copied with the CopyFeatures tool. I sure wish the SelectByLocation tool and the cursors methods honored the analysis extent... ... View more

When run in a loop, the Watershed SA tool will also randomly fail if the input "pour points" are in vector format. If you 1st convert the points to a GRID, the process become stable. ... View more

In v9.3 or v10? BTW: The new v10 Map Algebra and I don't get along... If was doing this process in v93 Python it would look something like this (code not verified): #assumes that the extent of littleRaster fits entirely within extent bigRaster bigRaster = r"C:\big" littleRaster = r"C:\little" gp.extent = bigRaster #Note: no need to set the snap raster if we are just using the extent of bigRaster somaExp = "con(isnull(" + littleRaster + "), -9999, " + littleRaster + ")" #recode NoData to -9999, otherwise keep the original values littleRasterNew = r"C:\little_new" gp.SingleOutputMapAlgebra_sa(somaExp, littleRasterNew) comboRaster = r"C:\combo" somaExp = "combine(" + bigRaster + "," + littleRasterNew + ")" gp.SingleOutputMapAlgebra_sa(somaExp, comboRaster) ... View more

How about: cur=arcpy.UpdateCursor("parsolak.shp") for row in cur:    if row.PARCEL_NO in ("", " ", None): #covers blank, one blank space, or Null       row.PARCEL_NO = "R-O-W"    cur.updateRow(row) del row,cur The PARCEL_NO field is a text field, correct? ... View more

It's for a different purpose, but this Python code: http://forums.arcgis.com/threads/8579-Adding-Together-Rasters?p=26307&viewfull=1#post26307 Has a part of it that does the extent normalization/con() routine that I am describing above. Take a look at the section of code that has the comment "#Process: Now build some new grids that have the max extent" ... View more

Right.... Combine works like intersect - and you want a union. The way I do this is to expand the extent of the original input rasters - that is make new rasters - where the null area outside the original extent gets reclassed to some recognizable value like -9999. That way you are still doing what basically amounts to an intersect, but have simply normalized the extents of the input rasters. I generally use the Analysis Extent & SnapRaster Environment settings in conjunction with the Con() tool to do that. Once the extents are all the same, then you shouldn't have any problems. ... View more

You hit it on the head: The Combine tool: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z0000007r000000.htm Note that this tool will "integerize" any inputs that are floating point, so if you need to preserve precision in the floating point data, do someting like int(MyFloatGrid * 1000) first and then in the output combine tool just divide the field by 1000 to get your original float value back. Also, note that the tool performs MUCH faster if all the input rasters and the output raster are all in GRID format (as opposed to all inputs and outputs datasets being FGDB fomat). ... View more

I will plead ignorance here, but why is it that for me a standard 90m USGS DEM for WA State consistently takes 30 seconds to run a Fill command in GRID format while the same raster in FGDB format takes 90 seconds? This users conclusion: FGDB is still, for whatever reason, sometimes significantly slower than GRID. I am left to theorize that for some tools there is still some extra processing overhead happening when the input/output is in a FGDB (or other non-GRID) format. However, granted, noted, and appreciated that most of the SA tools perform at par or sometimes faster when used with FGDB format (when compared with GRID format). Just curious here, but why aren't all SA the tools faster with FGDB format? Is the algorithm code somehow tailored to specific data formats? ... View more