topic Re: Local Geoprocessing without packages in ArcGIS Runtime SDK for WPF (Retired) Questions

Local Geoprocessing without packages

GeorgeFaraj — Fri, 09 Nov 2012 19:26:40 GMT

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?

Re: Local Geoprocessing without packages

KerrieScholefield — Mon, 12 Nov 2012 10:34:45 GMT

Hi,

Geometry operations such as Union, Buffer, Intersect can be dynamically performed on graphics. Once the operation is complete the results can be rendered on the map in a graphics layer. To perform these operations on local data, the LocalGeometryService should be used in conjunction with the use of a GeometryService Task.

Please see the conceptual documentation on LocalGeometryService for more information and code examples:

http://resources.arcgis.com/en/help/runtime-wpf/concepts/index.html#/How_to_use_the_Geometry_task/017000000039000000/

Samples using the LocalGeometry Class can be found in the Sample Application under Geometry> Geometry Operations

Cheers

Kerrie

Re: Local Geoprocessing without packages

GeorgeFaraj — Thu, 27 Dec 2012 20:13:49 GMT

I would like to revive this thread. I'm not sure if the above answer is really what I need. I have one or more layers and want to perform operations such as Buffer, Union, Clip, etc onto those layers. I want it to work like in the ArcObjects SDK, where you use the Geoprocessor and you specify the input feature layers, and it would return the resulting features.

Can someone direct me on the right path?

Re: Local Geoprocessing without packages

GeorgeFaraj — Wed, 02 Jan 2013 13:05:11 GMT

Is there really no way to run geoprocessing tools without having to pre-package the geometry and tools beforehand? I want to run geoprocessing tools on dynamically added layers (which can be shapefiles) on my map. Is this not possible?

Re: Local Geoprocessing without packages

MichaelBranscomb — Thu, 03 Jan 2013 12:05:36 GMT

Hi,

I think depends on what you'd like to achieve with the output. If it's for display purposes or for the duration of the user/app session then the LocalGeometryService and the GeometryService task is a valid approach for the types of functions you mentioned (buffer, clip, union). They work with arrays of individual geometries so you'd need to construct a query first to retrieve the geometries. If you want to store these geometries you could add them to a Geodatabase via a FeatureLayer/ArcGISLocalFeatureLayer or you can also serialize the features to JSON.

Alternatively you can use Geoprocessing packages to create a LocalGeoprocessingService and use in conjunction with the Geoprocessor task. This gives you the benefit of being able to create longer workflows as a model or Python script (i.e. Input > Buffer > Clip > Intersect > Output) and calling it as one operation, asynchronously. Typically these GP tools operate on an entire feature class (although you can easily do selection/filtering in the model/script). You'll get the result back as a set of Graphic objects, or alternatively you can request a MapServer to render the results (better for large datasets). If you want to store the output in a Geodatabase you can have the model/script write the output as required, or create an separate model/script to do this piece. Again, you could also write graphics to a Geodatabase via a FeatureLayer/ArcGISLocalFeatureLayer or serialize the features to JSON.

Cheers

Mike

Re: Local Geoprocessing without packages

GeorgeFaraj — Thu, 03 Jan 2013 13:11:17 GMT

Hi Mike,

With regards to your second approach (Geoprocessor), how do I execute a geoprocessing tool on any layer on the map? Everything I've seen in the documentation suggests that I have to create the geoprocessing package beforehand with the geometry. I want to mimick the Geoprocessing functionality that is provided with ArcMap, where you select the tool you want and then set the input parameters, like which layers to use, etc. After running it, I will add the results as a layer.

Re: Local Geoprocessing without packages

jp — Thu, 03 Jan 2013 19:23:52 GMT

Charles,

Have you checked the code under ArcGIS Runtime SDK for WPF samples (desktop application )?

Under - Geometry -> Geometry operations -> Buffer a point

Similar to what Mike suggested.

Does this help for your requirement?

Re: Local Geoprocessing without packages

GeorgeFaraj — Fri, 04 Jan 2013 14:46:08 GMT

Charles,

Have you checked the code under ArcGIS Runtime SDK for WPF samples (desktop application )?

Under - Geometry -> Geometry operations -> Buffer a point

Similar to what Mike suggested.

Does this help for your requirement?

I am not sure if this works for me. For example, if I run the Buffer operation on Layer1, I want the results of the operation to contain (clones of) the features from Layer1 that are within that buffer. I need to use the attributes for these resulting features to perform other operations on them.

This was easily done using the Geoprocessor class in the ArcObjects SDK, by providing the input layer and a distance.

Re: Local Geoprocessing without packages

DominiqueBroux — Fri, 04 Jan 2013 16:51:28 GMT

You can't directly use the layer as input of a geometry service but most of the geometry service accepts a list of feature as input parameter (ex BufferParameter.Features) so setting the input with all graphicsLayer.Graphics is just a particular case.

Though note that the graphics returned by the service don't include the attributes. However the returned graphics are always in the same order as the input graphics so you can easily retrieve the attributes from the input graphics.

For the intersect service (not sure from your description if you are talking about Buffer or Intersect service), some features may not intersect the input geometry but even in this case graphics with a null geometry are returned in the output graphics so the number of output graphics is always equals to the number of input graphics.

Re: Local Geoprocessing without packages

GeorgeFaraj — Fri, 04 Jan 2013 17:22:19 GMT

Though note that the graphics returned by the service don't include the attributes. However the returned graphics are always in the same order as the input graphics so you can easily retrieve the attributes from the input graphics.

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.

Re: Local Geoprocessing without packages

DominiqueBroux — Fri, 04 Jan 2013 17:46:02 GMT

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.

Re: Local Geoprocessing without packages

GeorgeFaraj — Fri, 04 Jan 2013 18:14:56 GMT

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?

Re: Local Geoprocessing without packages

MatthewBrown1 — Sun, 12 Dec 2021 00:45:00 GMT

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

Re: Local Geoprocessing without packages

KevinHibma — Tue, 08 Jan 2013 19:27:24 GMT

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.

Re: Local Geoprocessing without packages

MatthewBrown1 — Tue, 08 Jan 2013 20:17:22 GMT

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.)

Re: Local Geoprocessing without packages

KevinHibma — Tue, 08 Jan 2013 20:24:15 GMT

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.

Re: Local Geoprocessing without packages

GeorgeFaraj — Thu, 10 Jan 2013 13:06:37 GMT

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?

Re: Local Geoprocessing without packages

KevinHibma — Thu, 10 Jan 2013 14:30:12 GMT

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.

Re: Local Geoprocessing without packages

MatthewBrown1 — Thu, 10 Jan 2013 19:15:43 GMT

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):

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

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.)

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?

Re: Local Geoprocessing without packages

GeorgeFaraj — Tue, 22 Jan 2013 13:54:32 GMT

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.