I'm working my way through all of the ArcGIS Pro tutorials and I'm up to the "Make a geoprocessing model" tutorial but I've run into a bit of an issue. The tutorial tells me to change the scratch workspace location to Model_output.gdb, which I've done. However, when i then run the Summarise Invasive Species tool, it saves to the current workspace gdb rather than the scratch workspace gdb. I'm following the tutorial to the letter so I'm not sure what I'm doing wrong.
And you are continuing on from the other project as noted in steps 1 and 2?
what step is bogging you down?
what happens if you set it to what it should be in the geoprocessing environments?
Yes, I've followed the tutorial from step 1 all the way through.
In the "Set model properties and environments" section, step 19 tells me to set the scratch workspace to Model_output.gdb, which i've done. In the following section, step 7 says "Notice that the output path goes to the new Model_output geodatabase." and it says it does if i hover over the filepath. However, when i run the tool, the output actually goes to the "make_a_geoprocessing_model.gdb" geodatabase.
see if you can change the output location in the interim
If it is a documentation glitch... go to the bottom right of the screen and see if there is a …. Feedback on this topic.... link or similar and send a notification to the documentation group in case there is something not clear that has lead to this
Robert, what version of Pro are you running? Asking because I haven't been able to repro the problem on 2.1 or 2.2 beta software. If you're using something older, I'll give that a try.
Hi Robert, there's something going on I don't really understand. I'll ask some people on the geoprocessing team if they can look into it.
The path you show to the Model_output geodatabase: C:\Users\rghall\Documents\ArcGIS\Packages\Make_a_model\Model_output.gdb isn't the path you should get.
Following steps 11-13 in the section Set model properties and environments, the new geodatabase should be created inside the project package folder. In other words, your path should look like: C:\Users\rghall\Documents\ArcGIS\Packages\Make_a_geoprocessing_model_D2D7AC16-48C3-4826-ADE1-5332A4C4EA0CF\Model_output.gdb.
The fact that your path points to \Make_a_model\ instead of the package folder makes it seem like you might have typed in part of the path name, rather than browsing to it, when you created the file geodatabase. Is that possible?
I can reproduce your results if I create a new file geodatabase and, in the New File Geodatabase dialog, browse to C:\Users\<userprofile>\Documents\ArcGIS\Packages and at that level type \Make_a_model\Model_output as the name of the geodatabase.
In that case, the geodatabase will show up in the Catalog pane and can be set as the scratch workspace. However, when you run the tool and enter an output feature class, the output path points to the original project geodatabase--exactly as you show.
By clicking the Browse button next to the output feature class, you can point the output to the new file geodatabase (the one you want)--but of course that defeats the point of setting the scratch workspace.
Like I said, I don't know what's going wrong... something to do with the structure of project packages? I'll see what I can find out. In the meantime, try retracing your steps in the exercise and creating the Model_output geodatabase within the project package folder--as shown in the image after step 13. In that case, the rest of the steps should work properly.
NOTE: After doing some more testing, I think the problem may be something simple. After you set the scratch workspace to the new model_output geodatabase, you have to save the model. (This is step 21 in the relevant section of the tutorial.) If you don't do this save, you see the behavior you describe: the path to the new geodatabase is shown in the Environment settings, but when you run the tool, the output defaults to the original project geodatabase. Basically, the model needs to be saved before the new scratch environment is recognized. Can you try this and see if it resolves the issue? If so, I think it's probably expected behavior. And then disregard everything above about the location of the output geodatabase, which now seems irrelevant.