Disable quantization / generalization on featurelayer

[ae]

Is there any way to force a featurelayer to never generalize and/or quantize the geometries in the layer? I am asking because I'm doing a lot of geometryengine operations on a featurelayer and sometimes I get tiny slivers as output from the engine. Seemingly this is caused by tiny differences in the geometries depending on zoom level etc. In version 3 of the api we had setMaxAllowableOffset and autoGeneralize props as means to control this but in version 4 I cannot find it. 

[JoelBennett]

There doesn't appear to be a means of disabling the quantization via layer settings, but using a RequestInterceptor to remove the quantizationParameters from the queries to the server should work for most common implementations:

var featureLayer = new FeatureLayer({
	url: "https://server/path/etc/FeatureServer/0"
});

esriConfig.request.interceptors.push({
	url: featureLayer.url + "/" + featureLayer.layerId + "/query",
	before: function (params) {
		if (params.requestOptions.query.quantizationParameters)
			delete params.requestOptions.query.quantizationParameters;
	}
});

map.add(featureLayer);

[JohnRitsko1]

Joel, question how we could address this same issues with an internal ArcGIS Server 10.9.1 hosted featurelayer. Thank you for any input you may have.

ESRI states: 

Known Limitations

Only supported with ArcGIS Online hosted services or ArcGIS Enterprise 10.6.1 services.

[JoelBennett]

As far as I know, the same approach mentioned above would work.  Can you add a link to the ESRI documentation you mentioned?

[JohnRitsko1]

https://developers.arcgis.com/javascript/latest/api-reference/esri-rest-support-Query.html#quantizat...

Thank you.

[JoelBennett]

I see; that statement is probably out of date, and should read something like "Only supported with ArcGIS Online hosted services or ArcGIS Enterprise 10.6.1 and later services."  @KristianEkenes can you confirm?

[JohnRitsko1]

Joel.  We took this along with some code you helped us with before and doesn't seem to like what I did.  Perhaps I'm missing something here.  

  esriConfig.request.interceptors.push({
      urls: /\/query/,
      before: function(params){
          if (/LIKE '[^%]/g.test(params.requestOptions.query?.where)) {
            console.log("Like request");
            ('like request intercepted', params.requestOptions);
            params.requestOptions.query.where = params.requestOptions.query.where.replace(/ LIKE \'/g, ' LIKE \'%');
          }
          if (params.requestOptions.query.quantizationParameters) {
            delete params.requestOptions.query.quantizationParameters;
          }
      },
      // Moves Null (KNOWNAS) Values to the bottom of list
      after: function(response) {
        console.log("In after function");
          var notNulls = [];
          var nulls = [];

          response.data.features.forEach(function(feature) {
              if (feature.attributes.KNOWNAS === null)
                  nulls.push(feature);
              else
                  notNulls.push(feature);
          });

          response.data.features = notNulls.concat(nulls);
      }
  });

[JoelBennett]

Since you're using optional chaining on line 4, you might do the same on line 9:

if (params.requestOptions.query?.quantizationParameters)

[JohnRitsko1]

Think I was putting the cart before the horse here.  We are using a search tool that returns  a graphic that is generalized for say an office polygon.  This polygon isn't correct as it's been generalized and doesn't show all the shapes of the office correctly.  I don't think pursuing this route as we've been discussing works because the Search Widget returns a graphic and not the feature layer.  Thanks for all the help.

[JoelBennett]

In that case, you want to remove the maxAllowableOffset parameter:

if (params.requestOptions.query.maxAllowableOffset) {
	delete params.requestOptions.query.maxAllowableOffset;
}

The 3.x API Search tool did a better job of calculating that value than its 4.x counterpart.