Adding feature ID expressions and fixing DragBox cleanup in OpenLayers

Our map application received large backend responses, and processing them in the browser slowed visualization. I wanted to reduce that work.

Why I wanted an ID expression

I wanted the backend to return data in a form that an OpenLayers ID style expression could use directly. The frontend could then visualize the response without another processing step.

While investigating that approach, I found an existing OpenLayers issue requesting the expression I needed. I offered to work on it in the community and submitted an implementation.

Making the feature ID available to style expressions

I submitted the initial implementation and tests for the ['id'] expression. My first patch used an internal object identifier. Reviewers pointed out that the expression needed to return the Feature ID instead.

A maintainer added a commit that completed canvas rendering support. The merged implementation tracks whether a style needs the ID and supplies the value from feature.getId() to the evaluation context. It also includes a rendering test using the ID as a text label.

PR #15271 was merged on October 25, 2023.

Stopping before product integration

The expression was merged upstream, but I did not apply this approach to the product. Backend instability made another data-processing layer difficult to add, and feature development took priority over the performance work. I stopped before product integration.

Cleaning up an interrupted DragBox interaction

Our map displayed multiple polygons, and users needed marquee selection to select several of them at once. That feature exposed the DragBox bug: deactivating the interaction with setActive(false) could leave its selection rectangle visible on the map.

We had already handled the problem with a custom class in the application. My library contribution was part of moving that fix into OpenLayers and updating the application to use the corrected library behavior.

The merged change detaches the RenderBox from the map, emits a cancellation event when a drag has started, and clears the drag’s starting position. It also guards against further drag and pointer-up handling without that starting position, and geometry updates without a map.

PR #15671 was merged on March 26, 2024. Its review history includes revisions to the cleanup behavior; the final code uses setMap(null) rather than the disposal call described in the original PR body.

Checking the fix in the application

We checked the behavior manually in the product and added unit tests around our application’s marquee selection class.