Feature Layer Generalization and Selections

[NathanHeickLACSD]

Would anybody have an explanation of how generalization works in the JavaScript 3.X API?

1. Is the feature's actual geometry stored on the client and/or is the generalized geometry stored on the client?
2. Where does the generalization occur?  Does it happen on the server?
3. Is the generalized geometry requeried at every zoom level?
4. If you have a selection, do the selected features get requeried at every zoom level.

We're having an issue with selected features being less precise if you select them and zoom in.  They appear generalized.  It's like selected features don't refresh the same way that unselected features do.

Thanks,
Nathan

[David_McRitchie]

Hey Nathan,

I am not 100% certain but I have had a recent Support case that was very similar and resulted in a bug being logged. In this we were finding using Create Layer when selecting a feature in the Web AppBuilder was exporting a generalised polygon when zoomed out. Given Web AppBuilder is built on JavaScript 3.x I believe this related.

From my knowledge In terms of generalisation if the layer is stored on ArcGIS Online drawing optimisation is enabled then the generalisation should be done via ArcGIS Online, otherwise yes I believe it will be done on the client.

Do you get any issues with the selection when zoomed in on the layer? 

Many thanks,

David

[NathanHeickLACSD]

Hi David,

What we're doing is a bit complicated, but we're doing it for the sake of better symbology.  In that complication may lie the problem.

We have a feature layer and we set the selection symbol to a null symbol.  We then have an event handler that copies the selected features to two graphics layers.  One graphics layer uses the same renderer and scale dependencies as the parent layer.  It basically draws the selected features exactly as they are normally.  The second graphics layer is a highlight layer and is always visible.  It lets us see the selection at all scales.  That's important when we do flow traces across our system.

What is happening is that the graphics layers work as designed, but the selected feature in the feature layer appears to be generalized.  We sometimes make selections when zoomed out using various widgets.  Then, when we zoom in, the selected feature is not where it is supposed to be.  For point features, the location is off.  For line features, the vertices are off.  It's almost like the coordinates are imprecise when zoomed out but good enough for that zoom level.  Then, when we zoom in, they are not adequate.

The end result is that the features we selected are invisible per the design and not where they are supposed to be.  So, if you click on the graphics layers which are at the correct location, you can't get a popup.  You have to go hunt for the invisible point or line feature to get the popup.  Since the graphics layers are correct, you would never think to click off in space randomly.

My intuition says that when you select the features, the implementation of the selected features in the JavaScript 3.X API is such that the graphic for the selected feature is static and does not get updated each time the zoom level changes.  Normally, the feature layer keeps requerying the features at each zoom level and generalizes them adequately for each zoom level.  It's like the requerying gets shut off while the feature is selected.  I think it's either in the design of the JavaScript API or because I'm using null symbology.  I tried reading the API code but I haven't found where generalization occurs.  I've just found mentions of the feature layer mode.

In the 4.X API, you can just set a selection renderer, which is what I would like to have.  Still, I think it has more do with how selected features are symbolized than my graphics layers.

Thanks David!

Hi @ReneRubalcava3, do you have any thoughts on this issue?

[ReneRubalcava · Accepted solution]

Been a while since I used 3x, but I believe the behavior is the same as 4x in this regard. Features are requested generalized from the server (saves on bandwidth), so when you copy them to a GraphicsLayer, and zoom in, they will be overly generalized at the new scale. In 4x, there are methods to handle this via Effects and FeatureEffect, as well as the 4x Highlight which uses the oids.

If I had to tackle this in 3x, I would take the following steps:

1. Save the oids of my current selection
2. On scale change, clear selection
3. Create a new selection using saved oids

Yes, this involves more requests, but is probably a cleaner solution. Maybe in 3x, you could manually query the results, with a 0 maxAllowable offset (I don't know if that's right) and use the results at all scales, but that could be slow to draw given how complex the linework is (and I know yours can be, lol).

[NathanHeickLACSD]

Thanks Rene!  I'm actually querying the features directly from the server to load them into the graphics layer without any generalization.  If I stopped generalizing the feature layer, that might not be necessary though.  The main problem seems to be that the selected features in the feature layer don't update on scale changes like they do when there is no selection.  Do you understand why that happens?

My main concern with the solution you provided is that when have a large flow trace, the selections can take a long time to perform so it would be slow if you had to redo them every time you changed scale.  I will delve into the generalization settings on the feature layer, see if I can get them to work, and see what the performance impact is.

[NathanHeickLACSD]

Using the methods setMaxAllowableOffset or setAutoGeneralize did the trick.  The selected features update now on scale changes towards the end of the redraw.  You can see them move from where they were before to where they should be.  The performance hit was not significant.