Latest Contributions by DavidJames

Here is a note that I recently posted in the Case write-up for a bug we discovered in 10.6. The issue here regards how ESRI resolves issues in the software. In this case, a serious problem with the Lookup command forced us to develop a work-around for those users operating in the 10.6 environment. ESRI realized the critical nature of this bug and responded very quickly...they made the necessary changes and are implementing the fix in 10.6.1. As I note below, by failing to patch the flaw in 10.6, there is now a hole in the software that will remain in perpetuity. This 'Fix in the Next Version' causes me a lot of heartburn...as a developer, I do my best to respond to my clients needs for software that is stable and remains as bug free as possible. I would like to think that ESRI would feel the same. When a critical bug is identified, like this Lookup tool issue (and worse -- like deleting your C: drive [bug 000113996]), it is important not to let this problem remain in the software life cycle. Doing so robs the user of their expectations for reasonable stability in the use of the software. ESRI...please embrace a system where critical patches are resolved in the version of the software that they occur!! While I understand that this case -- and the associated bugs -- are closed, I want to encourage you to address this problem in the version where it occurred, 10.6. the Lookup tool is a critical piece of the tools that we develop using ArcGIS software. By allowing this bug unresolved in 10.6, the work-around that we developed will have to remain in place in perpetuity...we have to at least try to support users in versions going back to 10.3.1. I have to believe that it is in your (ESRI) best interest to provide a patch to existing software with critical flaws like this one and, say, the bug 000113996. Failing to do so leaves a hole in the software that will last for years...10.2 will not retire for another year. ... View more

If a feature class is symbolized by a Date field, the Legend treats the values as charactrers and sorts them as such. This is stupid...Date fields should be sorted as dates. No                              Yes 1/1/2016                      1/1/2016 1/10/2016                    1/2/2016 1/2/2016                      1/6/2016 1/22/2016                     1/10/2016 1/6/2016                       1/22/2016 ... View more

in a Python window in ArcGIS 10.3.1...using arcpy.Describe on a raster will yield an appropriate value for the raster format...'S32'...which stands for 32_BIT_SIGNED. The returned value is NOT a valid value for use in other commands, such as CopyRaster, which require the quoted string -- "32_BIT_SIGNED".   Please...change Describe or change the commnads to honor the returned Describe value. Left hand, right hand, meet each other! >>> PxT = arcpy.Describe("ec3m070802080201").PixelType >>> PxT u'S32' >>> arcpy.CopyRaster_management("ec3m070802080201", "newRas", "","","","","",PxT)     Runtime error  Traceback (most recent call last):        File "<string>", line 1, in <module>        File "c:\program files (x86)\arcgis\desktop10.3\arcpy\arcpy\management.py",      line 12583, in CopyRaster raise e ExecuteError: ERROR 000800:        The value is not a member of         1_BIT | 2_BIT | 4_BIT | 8_BIT_UNSIGNED |         8_BIT_SIGNED | 16_BIT_UNSIGNED |         16_BIT_SIGNED | 32_BIT_UNSIGNED |         32_BIT_SIGNED | 32_BIT_FLOAT | 64_BIT.   >>> arcpy.CopyRaster_management("ec3m070802080201", "newRas", "","","","","","32_BIT_SIGNED") <Result 'D:\\Data\\ArcGISdefaults\\MyDefault.gdb\\newRas'> ... View more

 Allow user to sort by Label or Count in layer properties> symbology property sheet. ... View more