Error loading Geometry

[StevenGriffith]

I'm getting an error -2147024882 being thrown when a query or identify returns a large geometry. This is only happening in IE; the same query and identify functions work just fine in Chrome and Firefox.

The response file returned from the REST service is 1.47 MB in size. What's interesting is that other, smaller geometries from that same layer work just fine.

This happens in both v2.4 and v2.5 of the API.

Steve G.

[derekswingley1]

Do you have a proxy set up for your app?

[StevenGriffith]

Do you have a proxy set up for your app?

No. What's interesting is that the entire layer will display just fine if the layer is made visible. The large geometries are only a problem when they are a query or identify return.

Steve G.

[derekswingley1]

Are you displaying the whole layer as a dynamic map service or a feature layer?

Are you sure you need to send a 1.5MB geometry to the client? I would guess that you could generalize the feature and this error would go away. Plus, your app would be faster.

Both the queryTask and the identifyTask support maxAllowableOffset. Here's a blog post I did on the details of how to calculate a suitable value for maxAllowableOffset:  http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2011/06/13/Feature-layers-can-generalize-geomet...

Once you have a value for maxOffset, set it on your query object or your identifyParameters object.

[StevenGriffith]

Are you displaying the whole layer as a dynamic map service or a feature layer?

Are you sure you need to send a 1.5MB geometry to the client? I would guess that you could generalize the feature and this error would go away. Plus, your app would be faster.

Both the queryTask and the identifyTask support maxAllowableOffset. Here's a blog post I did on the details of how to calculate a suitable value for maxAllowableOffset:  http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2011/06/13/Feature-layers-can-generalize-geomet...

Once you have a value for maxOffset, set it on your query object or your identifyParameters object.

That's an excellent idea - unfortunately, this is a dynamic map layer, not a feature layer. What concerns me is that this fails in IE only. Chrome and Firefox are perfectly happy with the large geometry.

Steve G.

[derekswingley1]

maxAllowableOffset isn't specific to feature layers, query and identify tasks can also use it. It's a best practice to use it and I'm pretty sure it'll stop this error from appearing.

[HemingZhu]

maxAllowableOffset isn't specific to feature layers, query and identify tasks can also use it. It's a best practice to use it and I'm pretty sure it'll stop this error from appearing.

Just want to share with developers what i have learned on maxAllowableOffset.  I recently have a project where I need write an ArcObject routine to retrieve a collection of features from a polyline feature class. And then convert them into a featurecollection JSON text (layerdefinition, featureSet etc) so that I can create a feature layer dynamically using this featurecollection. Initially it took around 315 seconds to converting 8 polylines to JSON text. So I added the method Polyline.generalize(double maxAllowableOffset) before the conversion. Now it only takes 18 seconds to convert (5.7% of the previous time!). I am not 100% sure whether the method is what Javascript API maxAllowableOffset internally implemented. However it is amazing how geometry generalization make a huge difference. The method uses widely accepted Douglas-Poiker algorithm for linear simplification. It basically treat the two points within maxAllowableOffset as the same, thus dramatically reduce the number of points in a polyline�??s pointcollection.  In my case it reduced the lenght of featurecollection JSON text from 630,681 to 13, 161 and still well preserve the integrity of geometry shape.  So I strongly recommend using maxAllowableOffset whenever you can.

[StevenGriffith]

Just want to share with developers what i have learned on maxAllowableOffset.  I recently have a project where I need write an ArcObject routine to retrieve a collection of features from a polyline feature class. And then convert them into a featurecollection JSON text (layerdefinition, featureSet etc) so that I can create a feature layer dynamically using this featurecollection. Initially it took around 315 seconds to converting 8 polylines to JSON text. So I added the method Polyline.generalize(double maxAllowableOffset) before the conversion. Now it only takes 18 seconds to convert (5.7% of the previous time!). I am not 100% sure whether the method is what Javascript API maxAllowableOffset internally implemented. However it is amazing how geometry generalization make a huge difference. The method uses widely accepted Douglas-Poiker algorithm for linear simplification. It basically treat the two points within maxAllowableOffset as the same, thus dramatically reduce the number of points in a polyline�??s pointcollection.  In my case it reduced the lenght of featurecollection JSON text from 630,681 to 13, 161 and still well preserve the integrity of geometry shape.  So I strongly recommend using maxAllowableOffset whenever you can.

Do you have a code sample that you would care to share?

Thanks!

[HemingZhu]

Do you have a code sample that you would care to share?  

Thanks!

It's a ArcObjects code written in Java. I am not sure if it is appropriate to post here. Here is the code snippets (i appologize if someone feels offended).

while(feature !=null)
{ 
      /*
       * reproject feature to web mercator
       */
       feature.project(webMercator); // webMercator is a SR defined as class property
       if (getGeometryType()=="esriGeometryPoint")      geometryStr=ServerUtilities.getJSONFromPoint((Point)feature.getShape()).toString();
       else if (getGeometryType()=="esriGeometryMultipoint")
 geometryStr=ServerUtilities.getJSONFromMultipoint((Multipoint)feature.getShape()).toString();
       else if (getGeometryType()=="esriGeometryPolyline")
       {
 polyline=(Polyline)feature.getShape();
 polyline.generalize(1);
 geometryStr=ServerUtilities.getJSONFromPolyline(polyline).toString();
       }
       else if (getGeometryType()=="esriGeometryPolygon")
       {
 polygon =(Polygon)feature.getShape();
 polygon.generalize(1);      geometryStr=ServerUtilities.getJSONFromPolygon(polygon).toString();
       }
      else
 geometryStr =JSONObject.NULL.toString();
   
      attributesStr ="{";
      /*
       * create a JSON text of feature attributes
       */     
      for (int i=0; i<fldCount; i++)
      {
            field = fields.getField(i);
             //SHAPE.LENGTH and SHPAE.AREA
 if (field.getType()!=esriFieldType.esriFieldTypeGeometry && 
     field.getType()!=esriFieldType.esriFieldTypeRaster &&
field.getType()!=esriFieldType.esriFieldTypeBlob && field.getName().indexOf("SHAPE.")==-1)
 {
     if (feature.getValue(i)==null)
 attributesStr +="\""+field.getName()+"\":"+ JSONObject.NULL.toString()+",";
     else if (field.getType()==esriFieldType.esriFieldTypeString ||field.getType()==esriFieldType.esriFieldTypeDate)
 attributesStr +="\""+field.getName()+"\":\""+ feature.getValue(i).toString()+"\",";
     else
 attributesStr +="\""+field.getName()+"\":"+ feature.getValue(i).toString()+",";
           }         
 }
 /*
 * add change type to the attributes
 */
 attributesStr +="\"changeType\":"+ changeType +"}";
     
 /*
 * put geometry and attribute key/value pair together
 * and form a JSON representation of feature
 */
 featureJSON =new JSONObject();
 featureJSON.put("attributes", new JSONObject(attributesStr));
 featureJSON.put("geometry", new JSONObject(geometryStr));
             //featuresArray is a JSONArray
 featuresArray.put(featureJSON);
             feature =(Feature)pCursor.nextFeature();    
}