topic Re: Duplicate inbuilt 'identify' function for add-in in ArcGIS Explorer Desktop Questions

Duplicate inbuilt 'identify' function for add-in

BabbageOcelot — Wed, 18 Aug 2010 15:42:35 GMT

Hello dev guys & gals,

I know it's an odd request, but bear with me. My users are so used to having to click a button, to then identify, I'd like to give them one via an add-in; just clicking on the map is a bit of a leap! Something which changes the cursor to a crosshair would make them feel a lot better. I can also give them feedback if there's nothing there, as opposed to just doing nothing.

Is there a code shortcut to duplicate the click functionality - that is: detect click in MapDisplay, identify, bring up list of elements at point - of the inbuilt map click? Appending to MapDisplay.MapItemClicked doesn't do anything, and MapDisplay.GraphicClicked appends to the function click only on graphic overlays, which isn't really what I want.

I'd also like to add the identify location into a folder in the content pane, rather than have it stick around until the map is moved and then disappear, so it's not going to be a straight reference to the click handler...

Lastly: noted in the (hilariously techno) Explorer 1500 preview video what looks to be identify-by-area. Which is another thing users here really want, and is a job less for me. Is this the case? Hope so! 🙂

Is there a proposed feature list somewhere?

Thanks.

Re: Duplicate inbuilt 'identify' function for add-in

MikeRudden — Thu, 19 Aug 2010 07:29:07 GMT

Hi,

Not an odd request at all. The API does provide everything that you need to achieve this I think.

I'm assuming that you are working with a FeatureLayer such as shapefile or geodatabase feature class. If not the following may be irrelevant, so please post back if that's the case. So from the button click....

1. Capture user interaction with the MapDisplay using one of the Track methods (e.g TrackPoint, TrackPolygon > this will return a geometry

2. Return the Table for the FeatureLayer > FeatureLayer.Table

3. Perform a spatial query > Table.Search passing in the appropriate filter.

You then have lots of choices but you could then iterate over the rows and create Notes from the results and add them to the contents window or bind the results directly to a grid using the TablebindingAdapter.

The SDK contains plenty of advice how to use these methods and there is a conceptual topic called How to Search A Table which will be a useful reference

I can also confirm that the 1500 release does not have any out-of-the-box capabilities to do a search by area.

Mike Rudden

Re: Duplicate inbuilt 'identify' function for add-in

BabbageOcelot — Thu, 19 Aug 2010 11:14:06 GMT

Mike,

thankyou - that should get me somewhere near; this is all preliminary and I've not started hacking about yet, but it sounds about right. If it can be made generic, too, then I should be able to implement identify-by-area.

If I may, I've got another identify-related question, regarding Service Layers. The layer itself has to be 'enabled' with a checkbox via right-click properties; if this is not enabled, and I detect a click (hopefully using similar methods to those you mention above), will the identify happen?

Likewise, is there (currently, or in future) any way to limit identify results to Service Layer sub-layers which are currently being shown?

Thanks,

Ben.

Re: Duplicate inbuilt 'identify' function for add-in

MichaelBranscomb — Fri, 20 Aug 2010 09:19:36 GMT

Ben,

Querying map services (ServiceLayers) is a little more complex. By default, these are not included in the OOTB identify operation - as you have noted you need to explicitly enable this behaviour on a per-service basis. This is because map services can contain many thousands of coincident features which could cause a performance hit in ArcGIS Explorer. The ServiceLayer class also does not have the Search method as the Table does. Which means your best option if you want to include map services in your identify (/spatial search) is to use the ArcGIS SOAP API to perform the identify on the service and combine the results with the results from the Table.Search method... bearing in mind that you are likely have no control over the remote ArcGIS Server and therefore depending on many factors the query could take a little time to return so it's best done in an asynchronous fashion.

I've attached a 7zip'd VS 2008 Solution of an example I wrote a while back - it's intended to be used in a DockWindow Add-In, but could be put behind a Button Add-In and the results displayed in a new Form. Unfortunately I just recompiled this against 1500 to remove a couple of issues which means you won't directly be able to build the project until 1500 is actually released... but that's pretty soon. You should however be able to open it and copy the relevant bits (inc UI components from the DockWindow form I hope - but if not it's basically just a Button and a TreeView control plus a CheckBox and a ProgressBar).

N.B. There are some new query capabilities in the Explorer API at 1500 for both FeatureLayers and ServiceLayers/ServiceChildLayers - but they're more relevant to attribute queries than spatial searches.

Cheers

Mike 2

Re: Duplicate inbuilt 'identify' function for add-in

MichaelBranscomb — Fri, 20 Aug 2010 09:35:12 GMT

Ben,

Just found an issue with that code - you'll need to find the private void btnIdentify_Click(object sender, EventArgs e) method and copy/paste the section of code below to replace the code sample. It was just missing the extra slash (+ "/") in the URL construction.

      //Loop through the services adding MapServices to the ServiceInfo object
      foreach (ServiceLayer serviceLayer in serviceLayers)
      {
        if (serviceLayer.ServiceConnectionProperties.ServiceType == ESRI.ArcGISExplorer.Data.ServiceType.MapServer)
        {

          serviceInfo = new ServiceInfo();
          serviceInfo.MapServiceName = serviceLayer.Name;
          serviceInfo.MapServiceURL = Convert.ToString(serviceLayer.ServiceConnectionProperties.Url)
              + "/"
              + serviceLayer.ServiceConnectionProperties.ServiceName
              + "/MapServer";
          serviceIdentifyParams.MapServicesInfomation.Add(serviceInfo);
        }
      }

Cheers

Mike 2

Re: Duplicate inbuilt 'identify' function for add-in

BabbageOcelot — Tue, 24 Aug 2010 13:00:58 GMT

Mike,

I'm afraid this is a bit over my head (I'm a Javascript developer mainly). Does the WSDL proxy need recreating? I see from the netmon logs it's requesting using the schema:

tns: http://www.esri.com/schemas/ArcGIS/10.0

... now the server we're running map services on is 9.3.1, and it's Explorer 1200.

No queries (with known features at click point) return any results - in fact, I can't really see that the SOAP request is sending any point data. In return, the service responds with map information - spatial reference, visible area - but nothing related to a point.

Having never used the SOAP API, it's a whole new experience...

Thanks, Ben.

Re: Duplicate inbuilt 'identify' function for add-in

BabbageOcelot — Fri, 10 Dec 2021 21:05:45 GMT

Mike,

Example now runs perfectly in 1500; have pulled it apart and rebuilt to our specification without much fuss!
Fantastic job on the release, wasn't expecting it for weeks.

Look forward to reading the new SDK documentation.

Thanks,

Ben.

Edit: I should add there was a tiny bug in the example given. Odd failures occur if you select more than one map service, and click in an area where the topmost service doesn't have any features (but lower layers do).

It's to do with this:

//If no results are return exit
          if (mapServerIdentifyResults.Length == 0)
               return;

...which has the effect of halting the serviceIdentifyParams.MapServicesInfomation loop, even though there might be pertinent stuff lower down. Really easy fix:

//If no results are return exit
          if (mapServerIdentifyResults.Length > 0){
                ...etc
          }

Re: Duplicate inbuilt 'identify' function for add-in

MichaelBranscomb — Fri, 27 Aug 2010 09:02:07 GMT

Ben,

I'm glad you found the sample useful and are enjoying 1500. The new release does include the capability to perform identifies on map services but you might still prefer to stick with your Add-in with which you'll obviously have more contorl over the behaviour and user experience.

And thanks for bug fix to my sample... admittedly I hadn't done much testing of with different services.

Cheers

Mike

Re: Duplicate inbuilt 'identify' function for add-in

SergioGalindo — Mon, 04 Oct 2010 20:19:41 GMT

Is there any chance I could have that add-in (i mean the *.eaz file)??

Thanks in advance!!

Re: Duplicate inbuilt 'identify' function for add-in

BabbageOcelot — Tue, 26 Oct 2010 13:48:35 GMT

Mike,

sorry to drag this old one back to the top of the forum.

We're migrating our server from 9.3 to 10, and in the process only publishing .msd-based map services. Unfortunately, these don't work with this add-in - either the original, or my modified one. It's not a v10 issue, because I've published a further test on our 9.3 box demonstrating that mxd files work, and msd files don't. The only warnings that come up when creating the .msd are that the datasource is [and must remain] SDE.

The wsdl looks to be the same, so I'm confused. Is there anything you can suggest?

Is there any chance I could have that add-in (i mean the *.eaz file)??

Thanks in advance!!

Sure - I'll have to have a look at making it less rubbish (and a little more functional) before I distribute, though!

Re: Duplicate inbuilt 'identify' function for add-in

MichaelBranscomb — Tue, 26 Oct 2010 14:14:40 GMT

Ben,

When debugging the code are there any errors / messages?

Regards

Mike

Re: Duplicate inbuilt 'identify' function for add-in

BabbageOcelot — Fri, 10 Dec 2021 21:05:48 GMT

Ben,

When debugging the code are there any errors / messages?

Regards

Mike

Mike,

ah... I was hoping this would be a "Oh, we know about this..." sort of thing.
I'm afraid all that comes back is a SOAP fault:

<soap:Fault>
         <faultcode>soap:client</faultcode>
         <faultstring>Error processing server request</faultstring>
         <detail/>
      </soap:Fault>

After some analysis, the SOAP requests sent for the two services (same mxd file, different publishing method) are wildly different. I'll attach them, but in short the <LayerDescription> element in the msd request is quite minimal:

<ScaleSymbols> is set to false.
There is no empty <SelectionFeatures/> element as there is in the mxd request.
There is no <SelectionSymbol> element.
There is no <SelectionBufferSymbol> element.

I'll have a look at forcing these elements; at the moment this is all I have to go on. Hope it makes sense.

Thanks,

Ben.

Re: Duplicate inbuilt 'identify' function for add-in

MichaelBranscomb — Thu, 04 Nov 2010 08:46:55 GMT

Ben,

I believe you're receiving Tech Support on this issue currently? - if that's the case probably better to pursue through that avenue for better traceability.

I'm not currently aware of any differences in the WSDL between an MXD-based service and an MSD-based service. However, it's possible that my Add-in was using an old SOAP proxy library. Perhaps try downloading the 10.0 pre-generated proxies (or generate new ones yourself if you prefer) - http://help.arcgis.com/EN/arcgisserver/10.0/apis/soap/Pre-generated_proxies.htm.

Regards

Mike

Re: Duplicate inbuilt 'identify' function for add-in

BabbageOcelot — Fri, 10 Dec 2021 21:05:51 GMT

Hello Mike,

Yes - there's a tech support request out for this... the link you sent to the library was very helpful.

It turns out that msd-published services behave differently to mxd-published ones with regard to the ImageDisplay attribute of the SOAP request. Mxd-published services don't care if the ImageDisplay is created with the default constructor & sent on its way; to make it work with msd-published services, you have to set the width, height and dpi.

// Fails with msd-published services
ImageDisplay imageDisplay = new ImageDisplay();

// Works for all services
ImageDisplay imageDisplay = new ImageDisplay();
imageDisplay.ImageHeight = 500;
imageDisplay.ImageWidth = 500;
imageDisplay.ImageDPI = 96;

Thanks for your time on this, at least by using the compiled .dll I could remove that from the possible causes. The SOAP API C# Examples were also pretty handy for creating test cases.

Hope this is of help to someone out there!