In ArcGIS 10.5, when I publish a Python Toolbox result as service, the parameters such as GPRasterDataLayer become GPString if these parameters are unfilled when running the toolbox on Desktop. This causes errors when using these GPString parameters as they are supposed to be GPRasterDataLayer. Is there any way to go to the server arcgisserver\directories or any folder and modify the data types?

  • 1
    Can you provide a test.pyt that contains just enough code to illustrate what you have tried and where you are stuck, please? – PolyGeo Mar 17 '19 at 20:15
  • This applies to all toolboxes I tried. If you try any toolbox you have, you will face the same problem. – wondim Mar 18 '19 at 0:19
  • Modifying a deployed service by hacking the folder contents in the config store can't be a supported methodology. I doubt Tech Support would go there, though they might have a different solution. – Vince Mar 18 '19 at 1:06
  • @Vince true but there is no option to modify parameters from an interface. Absence of this is the reason why modifying the the config is needed. – wondim Mar 18 '19 at 2:24
  • No, modifying the config is not an option. Publishing from an execution with all the parameters is a better solution. – Vince Mar 18 '19 at 2:37

As pointed out in the comments, you're trying to fix a problem by addressing the unexpected end behavior, when in fact you should be trying to fix the problem causing the issue. You should not try to modify the parameters from the tbx/pyt inside the arcgisinput directory. Actually, you can't. This information is baked into the binary files inside the service. (You could technically hack the code in the .py or .pyt, but you can't 'hack' the service as asked in your question)

I'm not really sure why you're seeing a GPRasterDataLayer parameter get turned into a GPString, but your comment on this only happens when you don't supply an input. The seemingly obvious answer here is to provide the tool with a raster dataset when you run it, before publishing. The result from your execution will know and honor the GPRaster input when creating the service. Running the tool on desktop in the same way someone would use it as a service, prior to publishing, sets the service up to be well defined and avoids these problems of unexpected executions/parameter types/etc.

Thinking about your situation, you're talking GPRasterLayer -- does this mean you want a hardcoded set of layers the user will choose from at execution time? Or do you want to allow the user to send a raster of their own to the GP Service? If the later, you'll need to change your input parameter type from Layer to Dataset. This scenario is all about having a good, well defined tool, so when creating a service you get that same experience.

  • If it is in a binary file, then there is no hope for me. Regarding GPRasterLayer vs Dataset. I am using already published image services. There is an option to Upload, even though not working. When it works, I want to publish the uploaded image as image service so that users can see the map of course ArcGIS Rest API refused to work too so I might go to the Dataset Route. Thank you for the input! – wondim Mar 18 '19 at 15:09
  • Why doesn't ArcGIS server creates the same parameter data type as provided in python? – wondim Mar 18 '19 at 15:10
  • Geoprocessing Services only support a sub-set (10-12) of the full parameter list. The reasons don't really matter, because it is what it is and you need to work within the list of supported parameters. The thing to note, if a parameter type is NOT supported, it is either mapped to CONSTANT (hardcoded) or STRING. This might be what you're seeing. – KHibma Mar 18 '19 at 15:30
  • All of that said, you can use image service layers in a gp service (not as a true parameter, but referenced inside the code) and you can use raster layers and raster datasets. So I'm not entirely sure where you're running into problems. – KHibma Mar 18 '19 at 15:31
  • The tool I failed to publish has about 60 parameters. – wondim Mar 19 '19 at 2:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.