It would be vital to geo-processing service debugging and testing if the the data formats of "Feature Set" and "Record Set" be properly supported on the Desktop.
If the parameter of the model has the data type set as one of the above (Feature Set/Record Set) then one should be able to load JSON from a text file on disc or point to a feature service in AGO/ArcGIS Enterprise Server via a URL (or exiting connection).
That way, one could get desktop pre-testing closer to the actual environment that will be encountered on the web where JSON feature sets and record sets rule.
This is especially important for python script tools where commands such as describe result in objects with very different methods/properties depending on the data format.
Does this not make sense?
Sorry, but I have only dealt with feature sets input.
And this is an important way to get user input in a geo-processing script.
ie the user inputs some points, or draws a polygon, or what ever.
If you want to suck in a geoJson file, or point to an existing feature in any sort of database, that is a different process.
On the web when AGO or ArcGIS JS 4.3 API talks to a geo-processing service then features are sent as JSON:
Parameter: fl_out
Data Type: GPFeatureRecordSetLayer
However, when you are building the model on the Desktop (ArcMap/ArcPro) and test that model (before publishing it) the parameter boxes that appears restricts the user to selecting Feature Classes/Layer files even when one sets the data type to "Feature Set".
Then when the model runs the dialog for the parameter only allows Feature classes
The dialog should allow for JSON (text file with a .JSON extension) or a REST-URL to a layer in feature service.
The JSON to Features tool allows one the select a JSON (See below):
Is that more clear?
You have to give it a schema or template, so that the feature set knows what sort of geometry to expect - Point, Line or Polygon
That would be in the JSON
Here are the first few lines of the JSON file:
{
"displayFieldName" : "",
"fieldAliases" : {
"OBJECTID" : "OBJECTID"
},
"geometryType" : "esriGeometryPoint",
"spatialReference" : {
"wkid" : 26910,
"latestWkid" : 26910
},
"fields" : [
{
"name" : "OBJECTID",
"type" : "esriFieldTypeOID",
"alias" : "OBJECTID"
}
],
To reiterate, the ability to consume JSON via model parameters on the Desktop before publishing would greatly improve the geo-processing as a service experience. This would match the workflow on the web.
What is the GP service supposed to do? Digitize a point and do some processing? A feature set in Desktop is the same as a GPFeatureRecordSetLayer on the web, so once you define the template, you should be able either digitize a point in ArcMap or use an existing feature class as input. Once it's published, a web application will give you the option to draw a point in the application as the input point(s) to the GP task. The WAB also would allow you to provide a service URL as input.
A quick tour of authoring and sharing geoprocessing services—Documentation | ArcGIS Enterprise
A quick tour of using Feature Set and Record Set—Help | ArcGIS for Desktop
Hi Jonathan,
The major issue is that a Feature Set and a Feature class are NOT the same thing in the Desktop world (ArcMap/ArcPro)
Many tools will NOT accept a Feature Set in JSON format as input.
Give it a try by converting an existing Feature class to JSON then try to use the JSON as input for the many tools in ArcToolbox. The tools will not accept it.
Look at arcpy.describe
Describe—ArcPy Functions | ArcGIS Desktop
Notice the difference between a Feature Set and a Feature class.
And that's the 'thing'. The model parameters allow one to set the input data type as Feature Set but the parameter dialog that pops on the Desktop will not let you load a Feature Set (serialize as JSON in a text file) as input.
It would be great if it did. Save a lot of time when you are testing and debugging.
So in the Desktop world where you first build the model for a future web service, you cannot actually test with the actual JSON that it will receive in the future. Instead you test it with a Feature Class which does not exist on the web ... yet.
And that is my point. My services work fine with alterations in python scripts but that needlessly burns a lot of time.
If I could develop and test on the Desktop with raw JSON that would help and make sense.
Thanks for listening,
Rob
I'd say the convenient thing about feature sets in Desktop and their associated GPFeatureRecordSetLayer equivalents is that you typically don't need to provide JSON as input on the desktop side, yet the GP task should perform exactly the same in either environment. Typically, I've seen these tasks revolve around digitizing features in the application, which work fine using Feature Sets in Deskop and the equivalent GPFeatureRecordSetLayer on the Server. Can you describe, (no pun intended), a workflow or specific tools that don't work well when going from the desktop environment to the Server environment? Are you mostly interested in the Describe tool?