Identify/Query Tasks return features intersecting envelope instead of geometry

[JulienDe_Vos]

I'm developing a client application with ESRI WPF API (2.4).
At some point, I perform an identify task in which I pass a polygon as argument. I realized that the features that were returned to me were not those that were intersecting the geometry of the polygon but those intersecting its envelope (I tried switching to a query task so as not to be bothered by extent, size and resolution issues but with similar results).

After some testing, I realized that this behavior is dependent on which data I put in the map service that I query, so I guess the problem is definitively server side.

At first I thought that it is some kind of coordinate system mismatch triggering what I believe to be a fall back to a default behavior, but so far I was unable to nail down the exact issue.

All my layers are query layers from an oracle database with SDO_GEOMETRY. I specified the same projection for all of them (Belgian Lambert 72) as well as for the data frame and I checked that the geometry columns were registered with that same coordinate system in the USER_SDO_GEOM_METADATA of the database.

Any clue what could cause this behavior?

[JustinHunter]

It's always good to see a snippet of the code to confirm that you are in fact properly sending in the proper geometry type before additional troubleshooting begins.

[JulienDe_Vos]

Hi,

Here's the code. But I did not see any way to specify the geometry type. The method just passes along a geometry to the parameter object such as it receives it, and I would like to keep it that way.

public IEnumerable<IdentifyResult>IdentifyComponents(string url,Geometry geometry){
 var task = new IdentifyTask(url);
 var parameters = new IdentifyParameters
          {
           LayerOption = LayerOption.all,
           Tolerance = 0,
           MaxAllowableOffset = 0,
           DPI = 96,
           Width = 600,
           Height = 500,
           MapExtent = geom.Extent,
           SpatialReference = geom.SpatialReference,
           Geometry = geometry,
           ReturnGeometry = true,
          };
 var results = task.Execute(parameters);
}

I also join an image of the situation on the map. The geometry passed to the function is that of the red boomerang, but the returned geometries correspond to those visible in the lower part of the red rectangle (which is the bounding box of the boomerang)

[ATTACH=CONFIG]22960[/ATTACH]

Thanks for your time!

[JulienDe_Vos]

Any answer?
I still think this has to do with the underlying data but I can't pinpoint what the problem is.

[ElizabethNolan]

Out of curiousity what are your results if you go to http://servername/arcgis/rest/services/ and click the mapserviceyou are wotking on, and perform the identify there without the java inbetween? This would be a better way to pinpoint if it is data specific.
Also, I noticed that the layers were projected, is it possible that the projection is causing the issue? You can see the layers of the data in the  mapservice under the rest directory. I've seen sometimes, where I have projected something in the client, added the layer, then shared the mapservice and then did not see what I expected for the layer as far as extents etc.
Also, through testing you can identify within each layer and see where the data is unexpected, my guess is that it will be because of a projection, or a data range in one of the layers being entered incorrectly.

[JulienDe_Vos]

Hi,

I would have tried that if I had a clue how to get a string representation of the geometry I am testing. Not being able to do so, I resorted to pulling each layer in turn out of the map service until the results returned were correct. I ended up identifying two layers on which ArcGIS Server seems to have trouble performing geographic queries (so the problem is definitively data related).

As I mentioned earlier, those layers are from an Oracle database (as are all the others as well). I exported them into a file geodatabase and under that format they do work fine.

I added all these layers to the mxd the same way (using query layers), specifying the very same projections for all and they all show the correct SRID in the rest page of the service but only those two layers generated this issue. My guess in so far is that they must be somehow registered differently in the oracle datamodel, maybe under another or no coordinate system at all. I agree with you that this smells like a projection issue but I am not sure where and what to look for inside Oracle entrails.

Best regards,

Julien

[MattiasEkström]

Did anyone found a solution to this problem?
Recently the same problem occurred to us, using QueryTask from ArcGIS Viewer for flex / ArcGIS API for Flex. The strange thing is that this used to work fine, but recently we noticed that the features that was return was the features intersecting the envelope and not the actual geometry.
Querying data that comes from a shapefile works fine, it's when were querying data from a Query Layer from an Oracle 10g database that we see this problem.
I also noticed that the same thing applies to the selection tool in ArcMap.
Any ideas how to solve this?

[JulienDe_Vos]

Hi,
I just ran into this problem again. Haven't found a "solution" to it but some sort of workaround that I leaves me deeply unsatisfied but that could save time if you don't mind too much.

First of all, I came to understand that ArcGIS Server perform geographic SQL queries against Oracle using SDO_FILTER which is a function that queries features that intersect the MBR (Minimum Bounding Rectangle~envelope, I suppose) of a given geometry. Sounds familiar doesn't it? After that, I can only speculate that ArcGIS Server takes it on himself to refine the resultset and return only the exact intersection result. It is that part that fails for unknown reason. I don't know if the same things happen with other Databases types.

I was finally able to obtain a correct intersection in two ways.

-First, I was able to get correct intersection results if I added a whereclause to the queries underlying the query layers. Any whereclause would do the trick (such as where 1=1). Why it did make it work, I have no clue. The downside of it is that it spectacularly increases the service response time. So much that I had to discard that solution altogether.

-Secondly, I was able to get correct intersections by getting the geometry service involved. This is how I proceeded.
    -I perform an identify task which sends me back the features intersecting the envelope of the geometry I provide. So I receive a larger set of features than I should but I know that all the features really intersecting my geometry are there.
    -I then run the "relation" operation of the geometry service with the geometries of the result features and the same geometry I sent to the Identify. In this method, the intersection is correct (I suppose because Oracle is not involved) and I am then able to sort the features that really intersect my geometry and those that don't.

The "relation" operation is pretty fast but the problem with this method is that I find myself performing multiple calls to the server where there should be only one (actually there's 3 subsequent calls as the relation operation only support one geometry type at the time so if like me you have points, polylines and polygons you have to make a call for each).

It sucks but it works.

[MattiasEkström]

Hi Julien!
Thanks for the update and your workarounds.
Your first workaround with the where clause did not work for me.
The second workaround I haven't tried yet (but I think it would work, as you said in that case Oracle isn't involved at all in the second step). In my case it would require modifying a lot of code in several widgets. We also have more layers pointing to shape-files than oracle spatial and in those cases it isn't necessary anyway. So I'm not quite ready to go that route just yet.
I've reported this issue to ESRI support and I'm waiting for their response.

By the way, which version av ArcGIS Server do you use? We're using 10.1 SP1, maybe upgrading to 10.2 could help...

[JulienDe_Vos]

Hi Mattias,
I understand it is not very practical. I'm none too happy about it either but it got me the results I needed so I thought I'd share. If you ever get to the bottom of this issue, please let me know.
We're using ArcGIS Server 10.1 sp1. I thought about upgrading to 10.2 but right now we are in a rather critical phase of the project and I don't want to tear everything down and have to put it all back together without any guarantee of result. When things settle down a bit, I'll certainly give it a try.
Best regards,
Julien