Latest Contributions by OliverSoong

I tested this a bit further and found out a bit more.  MapDocument.saveACopy seems to embed some attribute with the output filename in both the MapDocument object and the resulting mxd file.  MapDocument.saveACopy fails when writing to this same filename.  Alternating filenames works by alternating the embedded attribute in the MapDocument object. I apparently created my test.mxd by saving a blank mxd, at some point calling mxd.saveACopy("C:/tmp/test2.mxd"), and later renaming it to test.mxd.  This explains why I only see problems with C:/tmp/test2.mxd and no other path, and only with this mxd. BTW, I'm using Arc 10.1 SP1 and python 2.7.2.  ArcMap's Save, Save As, and Save A Copy do not seem to do this. ... View more

I thought I was subscribed to this thread, but wasn't. The DEM is a bit under 3.5e8 pixels.  Most of this is a single drainage basin, and near the outflow, the flow accumulation model would add small accumulations from small watersheds to the large accumulations from the mainstem.  A standard 32-bit single precision float has approximately 7(.2) significant digits of precision, so when flow accumulation from the mainstem reaches somewhere around 1e6 or 1e7, flow accumulation will start to lose some accumulation and will misrepresent which pixels have greater accumulation than which other pixels.  By way of conceptual example, in the land of single-precision floats, 12345678 + 1 = 12345678, and in some cases 12345678 = 12345677.  I wish I had an actual example, but all the numerical software I use only does double-precision. In short, the results would be wrong, and it would be distracting to have to consider and then explain why software inadequacies are hopefully not affecting any conclusions.  This would all be moot if the flow accumulation tool actually used double-precision, but the documentation just says FLOAT and floating point type, which in my experience has usually meant 32-bit single precision. Oliver ... View more

I'm running ArcGIS Desktop 10.0 SP5. I'm trying to write a python script to join fields from an Info table to a Coverage region and then Copy Features into a shapefile.  Join Field isn't working for me (all new fields are blank), but Add Join does work when I test things.  However, the qualified field names are too long for the shapefile, so they get truncated in an uninformative manner.  My fields are named uniquely, so I wanted to use unqualified field names. If I set arcpy.env.qualifiedFieldNames = False, the coverage region fields are qualified and the new fields from the info table are not. If I start a fresh ArcMap session, then set arcpy.env.qualifiedFieldNames = False in the python window, I get the same results, but I noticed that I can simultaneously have arcpy.env.qualifiedFieldNames = False and GeoProcessing->Environments->Fields->Maintain fully qualified field names be checked. If I start a fresh ArcMap session, set arcpy.env.qualifiedFieldNames = False in the python window, and uncheck GeoProcessing->Environments->Fields->Maintain fully qualified field names, I get the expected/desired results. Just for kicks, if I start a fresh ArcMap session, and only uncheck GeoProcessing->Environments->Fields->Maintain fully qualified field names, I only get qualified field names.  This is consistent with previously reported behavior: http://forums.esri.com/Thread.asp?c=93&f=986&t=278342&mc=4 Basically, it looks like the ArcMap GUI setting and the python setting are actually separate and both are being used. ... View more