Latest Contributions by ChrisSnyder

‎08-29-2011

Hmmm... are ALL your input datasets in the same projection and cell allignment?

‎08-29-2011

I also couldn't get the fieldInfo() methods to work... For example: >>> fc = r"C:\csny490\test.gdb\haul_routes_lt_flat_l_1_3" >>> arcpy.MakeFeatureLayer_management(fc,"fl") >>> dsc = arcpy.Describe("fl") >>> dsc.FieldInfo.exportToString () u'OBJECTID OBJECTID VISIBLE NONE;Shape Shape VISIBLE NONE;FacilityID FacilityID VISIBLE NONE;ALTERNATIVE ALTERNATIVE VISIBLE NONE;DECADE DECADE VISIBLE NONE;SPATIAL_ID SPATIAL_ID VISIBLE NONE;MBF MBF VISIBLE NONE;Shape_Length Shape_Length VISIBLE NONE' >>> dsc.FieldInfo.setFieldName(3, "ALT") #This should rename ALTERANTIVE to ALT >>> dsc.FieldInfo.setVisible(4, "HIDDEN") #This should make DECADE to HIDDEN >>> dsc.FieldInfo.exportToString () u'OBJECTID OBJECTID VISIBLE NONE;Shape Shape VISIBLE NONE;FacilityID FacilityID VISIBLE NONE;ALTERNATIVE ALTERNATIVE VISIBLE NONE;DECADE DECADE VISIBLE NONE;SPATIAL_ID SPATIAL_ID VISIBLE NONE;MBF MBF VISIBLE NONE;Shape_Length Shape_Length VISIBLE NONE' >>> arcpy.CopyFeatures_management("fl",r"C:\csny490\test.gdb\test333") <Result 'C:\\csny490\\test.gdb\\test333'> The changes I made to the feature layer were also not reflected when I exported it out to a FeatureClass (test333). Hmmm... I must be missing something here too. I'll bet it still works if you build a proper text sting and feed it into the MakeFeatureLayer tool.

‎08-29-2011

I also couldn't get the fieldInfo() methods to work... For example: >>> fc = r"C:\csny490\test.gdb\haul_routes_lt_flat_l_1_3" >>> arcpy.MakeFeatureLayer_management(fc,"fl") >>> dsc = arcpy.Describe("fl") >>> dsc.FieldInfo.exportToString () u'OBJECTID OBJECTID VISIBLE NONE;Shape Shape VISIBLE NONE;FacilityID FacilityID VISIBLE NONE;ALTERNATIVE ALTERNATIVE VISIBLE NONE;DECADE DECADE VISIBLE NONE;SPATIAL_ID SPATIAL_ID VISIBLE NONE;MBF MBF VISIBLE NONE;Shape_Length Shape_Length VISIBLE NONE' >>> dsc.FieldInfo.setFieldName(3, "ALT") #This should rename ALTERANTIVE to ALT >>> dsc.FieldInfo.setVisible(4, "HIDDEN") #This should make DECADE to HIDDEN >>> dsc.FieldInfo.exportToString () u'OBJECTID OBJECTID VISIBLE NONE;Shape Shape VISIBLE NONE;FacilityID FacilityID VISIBLE NONE;ALTERNATIVE ALTERNATIVE VISIBLE NONE;DECADE DECADE VISIBLE NONE;SPATIAL_ID SPATIAL_ID VISIBLE NONE;MBF MBF VISIBLE NONE;Shape_Length Shape_Length VISIBLE NONE' >>> arcpy.CopyFeatures_management("fl",r"C:\csny490\test.gdb\test333") <Result 'C:\\csny490\\test.gdb\\test333'> The changes I made to the feature layer were also not reflected when I exported it out to a FeatureClass (test333). Hmmm... I must be missing something here too. I'll bet it still works if you build a proper text sting and feed it into the MakeFeatureLayer tool.

‎08-27-2011

Chris, The output of Snap Pour Point is a raster. You input your point features, specify a radius, and it will move the 'feature' to the highest value cell of the flow accumulation grid within the radius. It's similar to what your doing but easier. It also virtually guarantee's you won't hit that occasional issue you mention. Watersheds that are single pixels or just a few is basically 99.9% an extent setting issue. If someone is using pour points, the way to verify the extent is the problem is to take the resulting (wrong) watershed raster and display the nodata pixels as some color. You'll find the extent of the watershed raster is limited by the geographic extent of the pour points and is not equal in extent to the DEM, flow direction, or flow accumulation rasters. This issue can be avoided by running the Snap Pour Point tool and specifying output extent = Flow Dir, Accumulation, or DEM. Snap Raster should always be set. Regards, Eric Not arguing that SnapPourPoint isn't effective at eliminating the problem I mentioned, but that particular tool is problematic when you don't want your input pour point to move at all (when using SnapPourPoint they generally move downstream up to the distance specified in the radius distance parameter, which in my case is not desirable at all). In my experience, I can have ~1000 points (derived from in-field GPS surveys) that are manually moved so that they are dead center on a flow accumulation raster (flowacc > 100 pixels or something). I know, because I snapped the points myself to a point version of my "stream" raster. For whatever reason, a small percentage of the points fail to yield the correct watershed even though they are spot on the flowacc > 100 raster. It is as if the points are somehow interpreted to be in one of the neighboring eight pixels even though they aren't. My work around is to convert each point to its own separate grid (ensuring the flowacc raster is set as the snapraster), and then run the Watershed tool using the grid version of the point as input. When I add the extra point-to-raster conversion step, all ~1000 points yield the correct results.

‎08-26-2011

Sounds like in "backend" processing methodology: yes, in outcome: no.

‎08-26-2011

I have learned to always convert the watershed "pour points" (or "pour areas") to a raster. BTW: Make sure you use the flowaccum grid as the snapraster. I noticed when running the watershed tool in a loop via Python that sometimes (even when the point seemed to be right on the center of the pixel), the tool occasionally failed to give the correct watershed delineation - as if the point was somehow interpreted to be in a neighboring pixel even though it wasn't... Anyway adding an extra step to convert the point to a raster solved the issue completely.

‎08-26-2011

In arcpy there is a seperate sub-module for doing Spatial Analyst stuff... Try this: arcpy.sa.ReclassByASCIIFile(blah, blah) Other than different licensing requirements, I don't belive there is a differnce between these tools - I could be wrong though.

‎08-25-2011

Don't know about the bug (or the bug fix), but as a work around, simply making a copy of the table using one of the ESRI tools such as CopyRows or TableToTable would auto create an OBJECTID field in output table.

‎08-25-2011

Even if you put the entire validation code in a try/except?

‎08-25-2011

Cool - looking forward to seeing those... BTW: WOW! Looks like you can now finally process Spatial Analyst tools in parallel now in v10/arcpy. Regardless it took me a year to realize it, that little discovery this morning made my day (probably my year actually!). Never noticed that (***very important to me***) tidbit in any of the "what's new in v10" documents... Man, I would have totally gone to arcpy right away (like a fly to sh*%!) had I noticed that sooner!!! Anyway - whoohoo! 🙂

‎08-25-2011

BTW: Jason, do you/ESRI have any multiprocessing/subprocess/parallelpython examples using arcpy/gp? More examples, the better... I've seen only a handfull of examples for multiprocessing with arcypy (well actually only one). Also, Do you personally (so as not to confuse it with your employer) have any recomendations about the "best" method use for parallel processing in Python using ESRI objects??? I'm trying to modernize my parallel scripts that use the (antiquated?) os.spawnv, and am seeing a lot of different options such as parallel python, multiprocessing, subprocess, etc. Any recomendations?

‎08-25-2011

...docume-what? multiprocessing.set_executable() A million thanks Jason!!!

‎08-24-2011

Yes, forking with python is pretty interesting... I though the comment in the f{o,u}rking script on line 174-177 was kinda fishy: # # _python_exe is the assumed path to the python executable. # People embedding Python want to modify it. #

‎08-24-2011

I finally had a good reason to start writing an arcpy script that uses the multiprocessing module (new in v2.6). Great! I start coding following this example: http://pythongisandstuff.wordpress.com/2011/07/11/using-arcpy-with-multiprocessing-%E2%80%93-part-3/ When I run my script it throws this weird error when it gets to the multiprocessing part: A new PythonWin window pops up with an error "Could not load the file from C:\Python26\ArcGIS10.0\Lib\site-packages\pythonwin" Oh crap... I go to a coworkers machine and try to run my script.... Same error!!! After a long while I deduce that for whatever reason the mutiprocessing module can't find python.exe anymore. I debug it untill I finally get to the problem: line 179 in the "forking.py" script (C:\Python26\ArcGIS10.0\Lib\multiprocessing\Forking.py). Here is that code: if sys.executable.lower().endswith('pythonservice.exe'): _python_exe = os.path.join(sys.exec_prefix, 'python.exe') else: _python_exe = sys.executable Problem is that the executable I am using DOES NOT end with "pythonservice.exe" (cause I am using PythonWin.exe!), so it reverts to using whatever the sys.executable variable points to (which is pythonwin.exe). Ah ah! So, of course when I hardcode the offending lines of code to be: if sys.executable.lower().endswith('pythonservice.exe'): _python_exe = os.path.join(sys.exec_prefix, 'python.exe') else: _python_exe = os.path.join(sys.exec_prefix, 'python.exe') Everything works fine!!! AWESOME! So my questons are: 1. If my coworker and I are having this issue, is anyone else have this issue? 2. Why can't the multiprocessing module find python.exe? Could it be related to arcpy "taking over" the Python install directory??? 3. Other than hardcoding the correct path to python.exe in the "forking.py" script, what can I do to make a permanent fix for this? P.S. Setting the PYTHONPATH system variable doesn't do the trick... ....Also, running ArcGIS v10.0 SP2, Windows7 Any ideas???

‎08-23-2011

The short answer is that yes, if you change tha path to the .tbx files, the scripts "should" work - provided nothing else prevents the script from working, which is quite likely. Also, note that you don't have to load any of the system toolboxes (managment, analysis, etc.), just the custom ones. So you could really just delete that line altogether.

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

My Ideas

Latest Contributions by ChrisSnyder

Re: Watershed tool producing a tiny catchment

Re: Making fields hidden/visible using MakeFeatureLayer help

Re: Making fields hidden/visible using MakeFeatureLayer help

Re: Watershed tool producing a tiny catchment

Re: is reclassify from the spatial analyst toolset available at the python command li

Re: Watershed tool producing a tiny catchment

Re: is reclassify from the spatial analyst toolset available at the python command li

Re: Add Join requires OID field for join - bug #NIM038601

Re: checking for existence of input data in toolvalidator crashes arcmap

Re: using mutiprocessing module - can't find python.exe anymore?

Re: using mutiprocessing module - can't find python.exe anymore?

Re: using mutiprocessing module - can't find python.exe anymore?

Re: using mutiprocessing module - can't find python.exe anymore?

using mutiprocessing module - can't find python.exe anymore?

Re: Can 9.3 python scripts using arcgisscripting run under 10.0?

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...