Latest Contributions by ChrisSnyder

So with that mystery solved, anyone know off the top of their head what version of scipy and pandas is "sort of" compatible with v10.3.1? The last time I tried to do this I recall it wasn't very easy and I only got about half the stuff working... which I suppose is why ESRI dropped it. ... View more

Yar... ... View more

I was actually thinking of converting my units to chains to really throw things off. BTW: according to your converter, 1m = 3ft 3 3 ⁄ 8 in. I think this output is intended to mock the U.S. system. ... View more

Sorry Dan and Chris, I should have clarified, but bit depth promotion is not what is going on here. For example... a value of 34.5678 * 3.2808 would not result in an output value >= 3.402823466e+38 (which according to the documentation would be the max of the 32-bit threshold), but regardless the resulting raster is output as a 64-bit float... even though there is no reason to warrant that. If I was trying to resolve 3.402823465e+38 * 3.2808 I would of course expect (and want!) the result promoted to a 64-bit depth. Basically what I'm look for (wishing for!) is either a envr setting or a map algebra function that would ignore the unwarranted bit depth promotion. My feeling is that ESRI probably just hard coded it so that if a float type operand was used with an input 32-bit float datasets it would just auto-promote, regardless if the output values exceeded the limit of the 32-bit max/min. A more elegant algorithm would test the max values of the rasters, the operations, and operands then resolve if promotion was necessary. More code for sure, but certainly more elegant. Worth noting that multiplying a 32-bit float raster by an integer (34.5678 * 3) retains the original 32-bit float depth in the output. ... View more

Hi Jay - Not sure what you mean here... your explanation of the process is not very clear. Basically I have a 32-bit float input raster in FGDB format, and I want to do some simple math involving  some floating point numbers. For example: myRst * 3.2808. I want the output raster to remain in FGDB format. Currently when this process is executed the output raster (in FGDB format) is pumped out as a 64-bit raster. Is there a direct way to "force" the output to remain a 32-bit float? For what it's worth, I did try the following w/ no success: 1. Created a 32-bit raster (a copy of the input), and used that as the output (aka I overwrote the copy with the output). Result: 64-bit. 2. Altered the NoData envr setting (under Raster Storage heading) to 'MINIMUM'. Result: 64-bit. ... View more

GRID only supports up to a 32-bit float (64-bit isn't even an option!), so yes that would work. I actually prefer GRID format usually, but indeed some things are faster/more efficient with FGDB format. One thing in particular is that the FGDB format offers (over GRID, .img, etc). is compression support for 32-bit floats. This comes into play especially for rasters with sparse data coverage (the NoData values compress!). Otherwise your 7.2GB LiDAR raster in FGDB format ends up being a 120GB GRID format raster! Yes, a bit depth environment setting or spatial analyst function sure would be nice! ... View more

I agree with Mr. Bixby, no need to store row ids. This code using set() objects also does the job: magicNumberSet = set([16,17,18]) #the building must have all of these codes to be in the yesList buildingDict = {} searchRows = arcpy.da.SearchCursor('L_DAMAGE_RESULTS_WIND', ["BLDG_ID", "HAZARD_ID"]) for searchRow in searchrows:     buildingId, hazardId = searchRow     if buildingId in buildingDict:         buildingDict[buildingId].add(hazardId)     else:         buildingDict[buildingId] = set([hazardId]) yesList = [buildingId for buildingId in buildingDict if magicNumberSet.issubset(buildingDict[buildingId])] noList = [set(buildingDict.keys()).difference(yesList)] ... View more

This is very easy to do using the .items() dictionary method. Consider: dict = {1:16, 2:17, 3:19, ...} key = 2 #this is your variable valueList = (16,17,18) # vals you are looking for in the keys. There's only one value per key right? dictItems = dict.items() for value in valueList:   if (key, value) in dictItems:     print str((key, value)) + " is in the dictionary!" ... View more

Okay - someone's probably made one of these already, but I'll stick it here incase I need it again. ... View more

Curtis, I agree with you. And I feel your pain...but we will march on! Hopefully someone on the ESRI Dev team notices this one... Too late for 10.3 though. ... View more

Yet in Python: >>> 'grid_code' == 'gridcode' == 'GRID_CODE' False ... View more

OK - Thought I was imagining stuff for a while but: In v10.2.2, the StreamToFeature tool still pumps out 'grid_code' field (or 'GRID_CODE' if using a shapefile. Thus. now with the advent of the 'gridcode' flavor in v10.2,  the problem is actually worse now in that there are now three different flavors: 'gridcode', 'grid_code', and 'GRID_CODE' .... Right after I did a blanker find='grid_code' and replace='gridcode'. *&(^(^^%!!!!!   I can't win... Note the StreamToFeature tool in v10.2 returns a schema of: For shapefile format: 'ARCID', 'GRID_CODE', 'FROM_NODE', 'TO_NODE' For FGDB format: 'arcid', 'grid_code', 'from_node', 'to_node' ... View more

Good point Curtis - I wasn't aware of that. As I recall, long ago it also used to be 'GRID_CODE' in caps... Maybe that flavor was for coverages. ... View more