Latest Contributions by isburns

shapefile with double field produces 32-bit signed integer raster shapefile with float field produces 32-bit floating point raster file gdb feature class with double field produces 64-bit double precision raster file gdb feature class with float field produces 32-bit floating point raster So shapefiles are part of the issue with this workflow. So while the following workflow works around the problem, there is still a problem with the tool itself. Execute Raster to Point and save as a shapefile; Convert the shapefile to a file gdb feature class; and Use the file gdb feature class as input to Point to Raster. However, to confound the issue, with the additional troubleshooting I used a much smaller area to reduce the processing time, and the first time it gave me a 32-bit signed integer raster when the input was a shapefile with double field, but at some point the tool started giving me a floating point raster under identical conditions (rerunning the tool with the same exact inputs using the Results window). On the larger area, it consistently gives me a 32-bit signed integer raster using the shapefile with double field however. ... View more

The points are regular, they came from the Raster to Point tool. Even if they are not regular however, the documentation does not describe this. The point is that the tool behaves in an unexpected way from what the documentation describes. Granted, it doesn't actually describe using a double field as input, but a reasonable expectation for this is for it to create a floating point raster and NOT an integer raster. I wouldn't call think this is an omission from the documentation, I'd call it a bug. If you'd like to see if you can reproduce this, here are some steps. Run Raster to Point with a floating point raster and save the output as a shapefile. My floating point raster had values of xxx.xxxxxx. Also worth noting, if you save the output as a feature class in a file geodatabase, the grid_code field will be a float, and in the shapefile it is a double. Add a float field to the output shapefile and calculate it from the double field. Here is one opportunity for a loss of precision (xxx.xxxxxx to xxx.xxx). Run Point to Raster with the double field as the value field. The output is an integer raster, and consequently results in loss of precision. Run Point to Raster with the float field as the value field. The output is a floating point raster. You haven't lost precision at this step per se, but you lost precision at step 2 so the output raster has less precision than what you started with. ... View more

The value field was a double and the cell assignment was most frequent. An easy demonstration of how Point to Raster can result in a loss of a precision is to execute Raster to Point on a floating point raster followed by executing Point to Raster on the output of Raster to Point. Provided you set the snap raster and processing extent the same, the result should be identical to the input, but it's not. ... View more

This behavior is still present in ArcGIS 10.4.1. When I run Point to Raster with the value field of the input set to a double field, the raster becomes an integer raster. When I run Point to Raster with the value field of the input set to a float field, the raster becomes a floating point raster. The expected behavior is that the output is a floating point raster when the value field of the input is a double field. If it wasn't so difficult for my agency to file a bug report, I would submit this. Anyone else care to? ... View more

We are planning on submitting a support request today, but I'm curious if anyone else can replicate this behavior on a different server. Dan Patterson‌ or Mody Buchbinder‌ (or anyone else), are you able to publish a Hillshade GP service and successfully run it with a floating point raster input? Thanks Shea ... View more

The hillshade does work using the same data when run from ArcToolbox in ArcMap. In ArcGIS Server Manager, there are three SEVERE level entries and nothing else in the logs. I think the first entry results in the subsequent two entries. There is no error report in the logs directory that Manager instructs me to check. Here are the entries in the logs: Entry 1 Level: Severe Time: Aug 11, 2016, 11:12:58 AM Message: Instance of the service 'agwa/HillShade.GPServer' crashed. Please see if an error report was generated in 'C:\arcgisserver\logs\MUDFLOW\errorreports'. To send an error report to Esri, compose an e-mail to ArcGISErrorReport@esri.com and attach the error report file. Source: agwa/HillShade.GPServer Entry 2 Level: Severe Time: Aug 11, 2016, 11:13:00 AM Message: com.esri.arcgis.discovery.ejb.ArcGISServiceException: Could not service request. at com.esri.arcgis.discovery.ejb.impl.GPServerBean.handleRequest(GPServerBean.java:197) at sun.reflect.GeneratedMethodAccessor6100.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144) at org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:164) at org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:92) at sun.reflect.GeneratedMethodAccessor6099.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144) at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:122) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:221) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:174) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:136) at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238) at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129) at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:196) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:149) at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71) at org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213) at org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233) at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66) at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91) at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: com.esri.arcgis.discovery.ejb.ArcGISServiceException: Could not service request. at com.esri.arcgis.discovery.ejb.util.EJBBase.handleRequestBase(EJBBase.java:601) at com.esri.arcgis.discovery.ejb.impl.GPServerBean.b(GPServerBean.java:331) at com.esri.arcgis.discovery.ejb.impl.GPServerBean.handleRequest(GPServerBean.java:192) ... 29 more Source: Soap Entry 3 Level: Severe Time: Aug 11, 2016, 11:13:00 AM Message: Error handling request to service 'agwa/HillShade.GPServer'. Could not service request. Source: Soap Thanks Shea ... View more

Dan, The output of hillshade is an integer raster, but it's when the input is a floating point raster that the problem occurs. ... View more

I know this is an older post, but I still see this behavior occasionally when a user tries to install my add-ins in a newer version of ArcMap then what the add-in was built with. What I discovered is that the "No GUI components found in this Add-In. Add-In version does not match." error only occurs when the user tries to install the add-in using the Add From File button in the Customize dialog. When the add-in is double-clicked from Windows Explorer, the add-in is installed successfully. Hope that helps some others. Shea ... View more

I was able to install the SDK for ArcGIS 10.3 with Visual Studio 2015. There were several steps, but none of them are too difficult. First, to get the SDK installed, you need to add a few registry keys so that ArcGIS thinks that you have a supported version of Visual Studio installed. Add registry string value: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\12.0\InstallDir (or whatever version the SDK installer is looking for) and set it to: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\ (or whatever version of Visual Studio you are trying to use). Add registry string value: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\12.0\ShellFolder (or whatever version the SDK installer is looking for) and set it to: C:\Program Files (x86)\Microsoft Visual Studio 14.0\ (or whatever version of Visual Studio you are trying to use). Second, if you're working with an existing project created for/with an older version of ArcGIS and Visual Studio and creating an add-in, you may need to edit the project file that builds the add-in to correct part of its build task. More on this at 45263 - Unable to generate add-ins when migrating from older to newer versions of Visual Studio used in ArcMap . Change <Import Project="$(MSBuildExtensionsPath)\ESRI\ESRI.ArcGIS.AddIns.targets" Condition="Exists('$(MSBuildExtensionsPath)\ESRI\ESRI.ArcGIS.AddIns.targets')" /> to <Import Project="$(MSBuildExtensionsPath)\ESRI\ESRI.ArcGIS.AddIns.11.targets" Condition="Exists('$(MSBuildExtensionsPath)\ESRI\ESRI.ArcGIS.AddIns.11.targets')" /> and change <Warning Text="Unable to create .esriAddin; missing ESRI ArcGIS Add-in SDK component(s)." Condition="!Exists('$(MSBuildExtensionsPath)\ESRI\ESRI.ArcGIS.AddIns.targets')" /> to <Warning Text="Unable to create .esriAddin; missing ESRI ArcGIS Add-in SDK component(s)." Condition="!Exists('$(MSBuildExtensionsPath)\ESRI\ESRI.ArcGIS.AddIns.11.targets')" />. Alternatively, you can copy and rename the existing ESRI.ArcGIS.AddIns.targets file to ESRI.ArcGIS.AddIns.11.targets. The MSBuildExtensionsPath is located in your Program Files (x86) directory. Third, if you're building an add-in, you need to edit the .targets file from the previous step to look for the version of Visual Studio you are trying to use. In C:\Program Files (x86)\MSBuild\Esri\ESRI.ArcGIS.AddIns.11.targets change <UsingTask AssemblyName="ESRI.ArcGIS.AddIns.SDK.12, Version=10.3.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86" TaskName="PackageAddIn" Condition="'$(VisualStudioVersion)' == '12.0'" /> <UsingTask AssemblyName="ESRI.ArcGIS.AddIns.SDK.12, Version=10.3.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86" TaskName="ValidateAddInXMLTask" Condition="'$(VisualStudioVersion)' == '12.0'" /> <UsingTask AssemblyName="ESRI.ArcGIS.AddIns.SDK.12, Version=10.3.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86" TaskName="ConvertToRelativePath" Condition="'$(VisualStudioVersion)' == '12.0'" /> <UsingTask AssemblyName="ESRI.ArcGIS.AddIns.SDK.12, Version=10.3.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86" TaskName="ResolveAddInReference" Condition="'$(VisualStudioVersion)' == '12.0'" /> to <UsingTask AssemblyName="ESRI.ArcGIS.AddIns.SDK.12, Version=10.3.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86" TaskName="PackageAddIn" Condition="'$(VisualStudioVersion)' == '14.0'" /> <UsingTask AssemblyName="ESRI.ArcGIS.AddIns.SDK.12, Version=10.3.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86" TaskName="ValidateAddInXMLTask" Condition="'$(VisualStudioVersion)' == '14.0'" /> <UsingTask AssemblyName="ESRI.ArcGIS.AddIns.SDK.12, Version=10.3.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86" TaskName="ConvertToRelativePath" Condition="'$(VisualStudioVersion)' == '14.0'" /> <UsingTask AssemblyName="ESRI.ArcGIS.AddIns.SDK.12, Version=10.3.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86" TaskName="ResolveAddInReference" Condition="'$(VisualStudioVersion)' == '14.0'" /> Alternatively, you can simply remove the Condition="'$(VisualStudioVersion)' == '12.0'" from these entries. Fourth and finally, you need a copy of the Visual Studio 2013 shell registered in the GAC. I was able to copy this from another machine (it was located at C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.12.0), but if you don't have access to a machine with VS2013 installed you can download the Visual Studio 2013 SDK from Download Microsoft Visual Studio 2013 SDK from Official Microsoft Download Center and copy it from there. Find a copy of the Microsoft.VisualStudio.Shell.12.0.dll for Visual Studio 2013 and copy it to your machine. Register it in the GAC using an elevated command prompt by entering gacutil /i Microsoft.VisualStudio.Shell.12.0.dll from the location you copied the file to on your machine. Note that you will now have two versions of this file in the GAC, one from Visual Studio 2013 and one from Visual Studio 2015. This can be seen by entering gacutil /l from the command prompt to list all of the entries in the GAC. My entries look like: Microsoft.VisualStudio.Shell.12.0, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL Microsoft.VisualStudio.Shell.12.0, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL Hope that helps some others. Shea ... View more

Was this ever resolved?  I seem to be experiencing similar behavior, but I'm developing in VB.NET.  I've set the LogHistory property of the ESRI.ArcGIS.Geoprocessor.Geoprocessor to false, but my Results tab still shows the of tools I've executed in the Results tab.  I'm worried about the performance hit because I'm executing 10-15 tools per feature in a feature class. OK all, Here is a tough one. I've written some VBA (because pythons method of spawning sub-processes meant my code was going to take 62 days...) and I've noticed the memory usage just keeps on creeping up. At one point I use the geoprocessor to call the Select Tool to create a new shapefile containing 1 point (Which is then used as a pour point for catchment generation) I create and set the geoprocessor as such: Set pGP = New GeoProcessor With pGP      .OverwriteOutput = True      .AddOutputsToMap = False      .LogHistory = False      .TemporaryMapLayers = True End With I call the tool as such: query = Chr(34) & "ID" & Chr(34) & " = " & CStr(ID) With pVA     .RemoveAll     .Add pFeatureLayer_Sites.FeatureClass     .Add "in_memory\tempSP"     .Add query End With pStatusbar.Message(0) = "Extracting a single site to in_memory" Set pGPR = pGP.Execute("Select", pVA, Nothing) Set pFeatureClass = pGPUtils.OpenFeatureClassFromString(pGPR.GetOutput(0).GetAsText) Set pGeoDataSetPP = pFeatureClass I release the memory as such: With pGPUtils     .RemoveInternalLayer "tempSP"     .ClearInMemoryWorkspace     .RemoveInternalData     .ReleaseInternals End With and I even kill off the geoprocessor within the loop as such: Set pGP = Nothing pGPUtils.ReleaseInternals In Arcmap Tools > options: Log geoprocessing is ticked off, results are temporary and results management is set to "Never Save" So at all stages I say NO results, NO logging yet the Select tool still adds an entry in the ArcToolbox results Tab which overtime consumes memory. I need to run this tool a lot of times for a long time but I just can't make ArcMap not Log a result! Any ideas, any undocumented tips or is this a bug? Duncan ... View more

I had the same problem in ArcGIS 9.3.1 with current service packs.  The online help indicates NoData cells should be -9999 but they are 0 for me.  I just replaced the NoData cells in the input with -9999 using CON and IS NULL to get the same results. http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?id=6230&pid=6215&topicname=Sample Shea ... View more

The repair of the SDK installation fixed it.  I didn't have any problems, warnings, or errors during the installation and it was a clean install on a new machine of both ArcGIS and Visual Studio so I'm still not sure what caused the problem initially.  Anyway, thanks for the suggestion. Shea ... View more