Local Geoprocessing without packages

[GeorgeFaraj]

I'm opening feature layers from map packages and now I need to run tools such as Union, Buffer, Intersect, etc. dynamically on those layers, then add the results as a new layer in the map. What is the best way to do this locally without using pre-modeled packages?

[DominiqueBroux]

That doesn't make sense to me. If I want a buffer of N kms around X features, I want the results to also contain features outside of those X features but within the buffer distance. In other words, the results should have X or more features.

The Buffer geometry service returns one buffer polygon by input geometry. Each input geometry is buffered at the specified distance and the buffer polygon is returned as output.
Note that there is also an option to get only one output geometry that is the union of all buffers.

But in no case the result has more features than the input.

[GeorgeFaraj]

Yeah, I need to get info about features that are not part of the input, but are affected by the operation. I used to do this with the Geoprocessor class in the ArcObjects SDK. I want to use the Geoprocessor here too, but I don't want to have to package the geometry with the geoprocessing tool. The user should be able to open any layers and perform the geoprocessing operation on those layers (just like you would in ArcMap). Is this possible?

[MatthewBrown1]

Hi Charles,

Further to Mike's earlier post, have you tried creating a geoprocessing package or service and sending a dataset from the Runtime using GP parameters? This will allow you to have control over the data you send, including the attributes you require, and this data doesn't have to be stored in the GPK.

Here's a generic example from the online help:

//Create a new Geoprocessor object
Geoprocessor gp = new Geoprocessor(_localGPService.UrlGeoprocessingService + "/Buffer");

//Create a new List of type GPParameter to hold the parameters for the service
List<GPParameter> parameters = new List<GPParameter>();

//Create a new GP FeaturerecordSetLayer with parameter name
GPFeatureRecordSetLayer gpFeatureRecordSetLayer = new GPFeatureRecordSetLayer("Input_Locations");

//Add the GpFeatureRecordSetLayer to the parameter list
parameters.Add(gpFeatureRecordSetLayer);

The architecture of the Runtime SDK is different to ArcEngine and Desktop, so you have to adjust your workflows (and GP models/scripts!) to suit the service-oriented architecture. (Also, be aware that not all GP tools are supported in the Runtime local geoprocessor and there are some limitations in terms of the size of the datasets you send to the GP service - you can adjust the output, but the input seems to be fixed at 1000 records from the work I have done.)

Having said that, ArcGIS 10.1 uses some kind of Runtime local service to perform background geoprocessing on "standard" GP tools (i.e. no GPK is required), so I think there is merit to your initial question.

Hope this helps,

Matt

[KevinHibma]

The architecture of the Runtime SDK is different to ArcEngine and Desktop, so you have to adjust your workflows (and GP models/scripts!) to suit the service-oriented architecture. (Also, be aware that not all GP tools are supported in the Runtime local geoprocessor and there are some limitations in terms of the size of the datasets you send to the GP service - you can adjust the output, but the input seems to be fixed at 1000 records from the work I have done.)

Having said that, ArcGIS 10.1 uses some kind of Runtime local service to perform background geoprocessing on "standard" GP tools (i.e. no GPK is required), so I think there is merit to your initial question.

You're correct about the modifying of models and scripts.
I can explain things a little further from the GPK/GP Runtime side of things, but I dont have the core knowledge of Runtime... so hopefully this might be enough to move you forward:

When you create a GPK for Runtime - that GPK will end up the same way if you created a GP Service. In a way you can think of Runtime hosting a GP Service for you.
For example, if you create a model which takes a featureclass as input, and create a runtime gpk, then that featureclass parameter becomes a featureset in the gpk. Featureclass is not a supported input type for GP Server (thus Runtime), but featureset is. (I know this sounds trivial, but its important to understand the parameter type in regards to how it can take input)

So, lets say I created a GP Service and this service made use of a featureset as input. I could consume this in Desktop and pass in a layer to the featureset parameter (desktop streams the features to the server) and the service would act upon them.
Now this is the part I dont know enough about in Runtime: if you have the same notion of layers in Runtime as you do in ArcMap, I'd say its conceivable that those layers could be passed to the "gp service" (ie the geoprocessing task runtime has spun up).
So if you know the answer to the "layer" question, and its "yes", then I'd suspect you could pass that layer into the GP parameter within the applications code and it should act upon it.

Your note about the runtime local service for background in desktop: True again. Note though: Well, yes they share common components and the same name - they do not equal one another. Background server in Desktop has zero interaction with a Runtime application. Basically I dont want you to confuse that just because you can do something in Desktop+Background you could potentially do the same in Runtime.

[MatthewBrown1]

Now this is the part I dont know enough about in Runtime: if you have the same notion of layers in Runtime as you do in ArcMap, I'd say its conceivable that those layers could be passed to the "gp service" (ie the geoprocessing task runtime has spun up).
So if you know the answer to the "layer" question, and its "yes", then I'd suspect you could pass that layer into the GP parameter within the applications code and it should act upon it.

Your note about the runtime local service for background in desktop: True again. Note though: Well, yes they share common components and the same name - they do not equal one another. Background server in Desktop has zero interaction with a Runtime application. Basically I dont want you to confuse that just because you can do something in Desktop+Background you could potentially do the same in Runtime.

Hi Kevin,

I wouldn't say layers in Desktop and Runtime are the same from my experience, but I've set up a few local GP services that *only* consume data from the application (both feature service and graphics layers) and I think you are correct about FeatureSets being the key. It took me a while to figure this out when I started using the Runtime SDK, and even though the documentation is more complete now than during the beta and pre-release, it could be made more obvious for folk coming from Desktop/ArcEngine or those with complicated projects that go beyond the GP samples.

Yes, I figured as much when I couldn't see a REST endpoint or anything in Fiddler, but it would be quite cool if this was opened up in the future as I have been frustrated with some GP tools not being available with the Runtime SDK. ArcPy gets better with every release, so some missing tools can be replaced with scripts, but it would be great if ArcInfo-level tools were supported in the Runtime. (But I guess this would contradict the intended purpose of the Runtime and you would be better to use something else from the ESRI stack.)

[KevinHibma]

Hi Kevin,

I wouldn't say layers in Desktop and Runtime are the same from my experience, but I've set up a few local GP services that *only* consume data from the application (both feature service and graphics layers) and I think you are correct about FeatureSets being the key. It took me a while to figure this out when I started using the Runtime SDK, and even though the documentation is more complete now than during the beta and pre-release, it could be made more obvious for folk coming from Desktop/ArcEngine or those with complicated projects that go beyond the GP samples.

For 10.1 sp2 (due probably around March) - we've enhanced the GPK for Runtime creation.
You'll now have parameter control support. So the whole point above about how parameters being mapped to a supported type happen under the hood: now you'll be able to play with those parameters when creating your GPK. Basically we've given the GP Service creation experience to the Runtime GPK experience. Hopefully this will make it easier for you and everyone else trying to do crafty things with GP in the Runtime.

Yes, I figured as much when I couldn't see a REST endpoint or anything in Fiddler, but it would be quite cool if this was opened up in the future as I have been frustrated with some GP tools not being available with the Runtime SDK. ArcPy gets better with every release, so some missing tools can be replaced with scripts, but it would be great if ArcInfo-level tools were supported in the Runtime. (But I guess this would contradict the intended purpose of the Runtime and you would be better to use something else from the ESRI stack.)

If theres a tool you want/need but it isn't supported: either submit it to the ideas site, or present it to the forums with a brief description of what you're doing. The Runtime team (Mike, etc) are very accepting of feedback. Theres many driving factors which determined what tools made the cut, so simply bringing up a good use case might help them be considered.

[GeorgeFaraj]

Let me see if I understand what you're saying.

I can use ArcMap to create a GPK with only the set of tools that I need, and I can have the geometry passed through a GP parameter when executing the tool.

Is this accurate?

[KevinHibma]

Let me see if I understand what you're saying.

I can use ArcMap to create a GPK with only the set of tools that I need, and I can have the geometry passed through a GP parameter when executing the tool.

Is this accurate?

Yeah - more or less.
You'll have to run the tool to get a result to turn into a GPK...
But if you have 3 or 4 workflows, get some "sample" data, construct each workflow, run each, then build them into the single GPK.

[MatthewBrown1]

You'll have to run the tool to get a result to turn into a GPK...

Hi Charles,

In addition to Kevin's post, you might want to use the 'Package schema only' option so only empty layers are packaged with the GPK.

I'm not sure if this is what you'd call "best practice" in terms of GPK creation, but it works for me (and seems to fit your scenario):

1. Create your script/model tool using FeatureSet for input parameter(s) instead of Feature Class/Layer/etc.


2. Run your tool with no data to get (an empty) result. (You can set the schema from the sample data if developing/testing your tool in Modelbuilder.)


3. Create GPK. I use options 'Package schema only' and 'Support ArcGIS Runtime' but the former might be redundant with empty inputs.

Any other suggestions from forum members?

[GeorgeFaraj]

Thanks for the suggestions guys. I still need some more help though. When I try to run the tool in my Runtime app, the geoprocessor fails with this error:

Bad request: POST GPServer/BufferModel/execute The 'execute' operation is not supported.

Any ideas why this would happen? I am attaching a screenshot of the Model Builder. When I run this tool in ArcMap, I select a sample layer for the InputFeatures parameter, and I have the Distance pre-set to 350 meters. The tool succeeds, and after that I am sharing it as a Geoprocessing Package.