POST
|
Well that settles it. I'll stop pulling my hair out now and just wait for the bug fix. Thanks for the update. Julien
... View more
12-09-2013
02:30 AM
|
0
|
0
|
219
|
POST
|
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
... View more
11-18-2013
11:02 PM
|
0
|
0
|
833
|
POST
|
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.
... View more
11-13-2013
05:10 AM
|
0
|
0
|
833
|
POST
|
Hello, Little update on the situation. Things have evolved bizarrely and probably out of the scope of this particular thread but since it is consecutive to it, I'm just putting a word here in case someone wonders if and how the problem was solved (it was not). I've put a word about data fragmentation to our DBAs, they seemed quite skeptic about it. An argument in their favor is that we've been monitoring the SQL generated by ArcGIS Server and tried to run it in a simple RDBMS client. To our surprise, we found no noticeable difference in response time between Oracle 10 and 11. It seem to us that the problem then must reside within ArcGIS Server. We ignore too much to make this test foolproof and this conclusion...er...conclusive but this is the assumption we based ourselves on. If you see a flaw in the logic, please share... The second surprise was to discover that ArcGIS Server only makes use of SDO_FILTER in its queries, which appears to be a function that queries features intersecting the MBR (Minimum Bounding Rectangle, that is the envelope if I am not mistaken) of a given geometry instead of the geometry itself. I suppose this is so to make optimal use of the spatial index while the exact intersection is then computed by the server on the subset of features returned by the database. Maybe that processing is where the problem manifests itself although why it should differ from one version of Oracle to the other is unclear to me. Except maybe I've been told that in oracle 11g all geometries are now 3D, I'm not sure if it is an absolute truth but it certainly is the case for our databases and our old 10g database were 2D, could that be related? This is were things get weird and wander off subject. We kept trying things and finally found something that "seemed" to work. We went through our query layers and realized they were rather complex. As I said earlier, we don't own this schema so to aggregate the data as we needed it, we had SQL somersaulting through some really mean hoops. What we did was to remove all the complexity of the queries underlying our query layers. We created a dedicated schema in the database where we created views that aggregated all the needed information. In our query layers we now only had the simplest possible SQL statements ("select * from view"). After republishing the map service with the modified query layers we observed that response time improved until it was back to the same range of values as when we were using Oracle 10g. I then performed a live test with the application and realized with some...,correct that, huge dismay that if the query was fast indeed, the results were now faulty. I realized that the mapservice was returning features outside the geometry I provided. Actually it returned all features that intersected the envelope of the geometry instead of the geometry itself. Sadly, I've encountered this problem before (see Identify/Query Tasks return features intersecting envelope instead of geometry), I was never able to solve it but it turned out the affected layers were not strictly essential to the application so I just stopped querying them. I don't have that option today. Now, in light of the tests we've conducted, it seems to me that ArcGIS Server is sending back the results of its SDO_FILTER SQL query "as is" without processing the exact intersection (which could account for the lower response time). Have you any idea why that would happen and how we could force it to perform an exact intersection? Moreover, I realized that if I put back a where clause in my query (by "a" where clause, I mean "any" where clause, "where 1=1" will do the trick), the intersection results would be correct but I'd lose the performance again. In short, I'm running in circles here and the aberrant behavior I have observed leave me completely clueless as how to solve this. Well, actually, I was able to obtain a correct intersection by using the geometry service but I'm not satisfied with it. 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 point, polylines and polygons you have to make a call for each). Once again, thanks for your time
... View more
11-13-2013
04:54 AM
|
0
|
0
|
319
|
POST
|
Hello! Thanks for your answers. I have no clue how the data was migrated. This was all handled by our db admin team. The database is not anormally big and as for the Oracle version, apart from 11gr2 I couldn't tell you. I'll pass those questions to the database administrators as well as the tip for data fragmentation. Good point about the hardware too. It was definitively not upgraded, but unfortunately, this is not a point that we can change, it'll have to do, I hope we can make do with what we have. As for ST_GEOMETRY, please pardon the maybe naive question (I'm not an expert) but what exactly do you mean by "ST_GEOMETRY is available when ArcGIS Server is present". Does that mean that ArcGIS Server can somehow dynamically convert SDO_GEOMETRY to ST_GEOMETRY and that would be more efficient? Wouldn't that bring additional processing time? Or do you mean that we could install ArcSDE and use it instead of pure native Oracle Spatial? That we cannot do, not being the owners of the databases we cannot make any change to the schema structure (certainly not get an SDE schema involved) nor the data types, so it has to remain Oracle Spatial and SDO_GEOMETRY only. We keep investigating, if anything comes up, I will post what we found here. In the meantime, if anyone thinks of other avenues to explore, please let me know.
... View more
10-30-2013
03:48 AM
|
0
|
0
|
319
|
POST
|
Hello, We have an ArcGIS Server 10.1 on which we mounted several mapservices that only uses query layers to Oracle databases (so no SDE involved and all geometries are SDO). A client application was developed with ArcGIS WPF api 2.4 that consumes these services to display maps as well as running query tasks and identify tasks. Recently, our database servers were migrated from Oracle 10g to 11gR2. Immediately after this migration we experienced a rather spectacular rise in response time from the ArcGIS Server. The identify task seems to be the most affected functionality with response time up to 10 times longer than they used to be before migration. We strongly suspect the new Oracle version to be at the root of this issue. To try to ascertain that, we re-mounted our old database (Oracle 10g) and set up identical map services with it. With this version of Oracle (and all other things remaining unchanged), we get back the performances that we used to have while despite our best efforts we can't bring the mapservices using Oracle 11g "up to speed". Of course, there's always the risk that the schemas, users, permissions and/or whatever were not copied correctly from the old databases to the new ones but after pestering our database administrators almost past their point of endurance with these consideration we are fairly confident the problem lies somewhere else. So, has anyone experienced this kind of issue? Is it,as we suspect, related to the new version of Oracle? Most importantly, how can we fix this? Thanks for your time!
... View more
10-28-2013
06:12 AM
|
0
|
5
|
833
|
POST
|
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
... View more
04-26-2013
03:50 AM
|
0
|
0
|
833
|
POST
|
Any answer? I still think this has to do with the underlying data but I can't pinpoint what the problem is.
... View more
04-15-2013
12:00 AM
|
0
|
0
|
833
|
POST
|
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!
... View more
03-26-2013
08:24 AM
|
0
|
0
|
833
|
POST
|
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?
... View more
03-19-2013
02:00 AM
|
0
|
11
|
1768
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|