Duplicate inbuilt 'identify' function for add-in

[BabbageOcelot]

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.

[MikeRudden]

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

[BabbageOcelot]

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.

[MichaelBranscomb]

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

[MichaelBranscomb]

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

[BabbageOcelot]

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.

[BabbageOcelot]

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
          }

[MichaelBranscomb]

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

[SergioGalindo]

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

Thanks in advance!!

[BabbageOcelot]

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!