Latest Contributions by FredSpataro

I've never seen anything that states arcpy should/must be imported first in order to not override other system modules.  I only skimmed this document but didn't see anything specific, although their examples tend to imply it.  However if you do a import-from on datetime BEFORE importing arcpy, then you're datetime import will be destroyed: >>> from datetime import datetime >>> datetime.now() datetime.datetime(2016, 7, 14, 12, 10, 12, 433000) >>> import arcpy >>> datetime.now() Traceback (most recent call last):   File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'now' >>> Either import datetime after arcpy or use the import-from-as syntax and give datetime an alias. ... View more

Hi All, I'm tracking on odd issue that's come up when I moved some code to the production environment. In that environment, the rasters used by the scripts are stored in an enterprise geodatabase.  When running arcpy.sa.ExtractByMask with an input raster from an enterprise geodatabase the following error is thrown: Messages Executing: ExtractByMask GIS.DATACREATOR.dem watershed C:\...\Default.gdb\Extract_GIS.1 Start Time: Wed Jun 29 14:14:06 2016 ERROR 999999: Error executing function. The table name is invalid. No spatial reference exists. ERROR 010302: Unable to create the output raster: C:\...\Default.gdb\Extract_GIS.1 ERROR 010067: Error in executing grid expression. Failed to execute (ExtractByMask). Failed at Wed Jun 29 14:14:19 2016 (Elapsed Time: 13.04 seconds) The stock system toolbox tool (System toolbox\Spatial Analyst Tools\Extraction\Extract By Mask) generates the same error.  It appears that this is caused by the "default output raster name".  In this case, that string is 'Extract_GIS.1' - which is an illegal raster name.  This is the typical GP default value: part tool name, part input dataset name.  Since the input raster is from a database, it's name is fully qualified (database.schema.table): GIS.DATACREATER.dem and the default text string uses the first four characters including the dot character ".".  It's unclear why the default name is not being checked as a valid name for the workspace... this seems to happen everywhere else in the stock GP tools. So...in the stock tool, modifying the default output name to something valid allows the tool to run correctly.  BUT the arcpy.sa.ExtractByVersion does not take an "output dataset parameter".  It only takes the input raster and mask features. It then creates some default scratch raster which, in the examples, is later saved to a specific name using the raster.Save() method.  But b/c the default name is invalid, this arcpy function can never complete successfully if the input raster is from an enterprise geodatabase.  Ugh. Things I've tried: 1. creating a layer file for the input raster with a clean name... the function still tries to use the FQN as the base for the default output name and fails 2. Changing the scratch workspace to a folder rather than the file geodatabase... Same name issue occurs with slightly different message but the file based name is still invalid as well....Again why is an invalid default name being chosen? Why is the method signature of stock toolbox tool and arcpy version different? ... View more

Hi All, Does anyone have some "best practices" or "lessons learned" they'd like to share on creating a complete US level SSURGO geodatabase in SQLServer?  I'm creating an application that will hopefully be useful across the entire US but really hate the idea of coding a big fat 'if STATE='X' then GDB="X" to deal with the smaller data chucks that come from USDA.  Handling user AOIs that overlap state boundaries gets even uglier... We've made an initial attempt at loading the dataset chucks and are close to 30M MUPOLGYON records and performance is not that great. Is ugly code better than an overtaxed database? Thanks in advance for any advice. ... View more