Adhere to geo_span setting from tenant if one is defined

[jeslefcourt]

What does this PR do?

• Reduces client and server overload by allowing the definition of a bounding box for an EarthRanger instance. Outside of these bounds, the client won't try to load data from the server. Currently this just works on features, but it can be easily used for events and subjects once those move to vector tiles.

Note for developers of the other vector tiles: See the way geoSpanFilter is defined and used around line 100 in src/SpatialFeaturesLayer/index.js

The bounds are defined as part of a tenant's envSettings in the TMS in the form:

    "geoSpan": {
        "lat": [-40.5, 40.5],
        "lon": [-180.0, 180.0]
    }

One known oddity of the behavior is that it won't load features that intersect, but aren't entirely contained in, the bounding box. For example, if you define a country as a feature and the bounding box being within that country but around the protected area, once you zoom in enough that you no longer see the edges of the country (+/-), the rest of the country or any formatting of the country will disappear. This can't be fixed with a reasonable amount of work, so we'll accept this and give guidance to make the bounding box big enough to encompass all features you care about.

Relevant link(s)

• Tracking tickets: ERA-12791 (https://allenai.atlassian.net/browse/ERA-12791)

Where / how to start reviewing (optional)

• Play around with intersecting views with polygons, lines and points: Overlapping, intersecting, non-intersecting

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

[Copilot]

buildGeoSpanFilter is new behavior in src/utils/map.js, but there are no unit tests covering valid/invalid geoSpan inputs (missing keys, wrong types, inverted ranges, etc.). Since this file already has a dedicated src/utils/map.test.js, adding focused tests there would help prevent regressions and clarify expected input handling.

[luixlive]

You can add a new describe block in src/utils/map.test.js and ask an agent to add some coverage to this new method:

describe('buildGeoSpanFilter', () => {
  // TODO: Claude, add unit tests for buildGeoSpanFilter here.
});

[Copilot]

The new geo-span behavior (adding bounds to the vector source when tenant config is present) isn’t covered by the existing SpatialFeaturesLayer tests. It would be good to add a test case where useSelector returns a non-null geoSpan and buildGeoSpanFilter returns a bbox, then assert map.addSource is called with a bounds field so this feature doesn’t silently regress.

[luixlive]

Great idea 💯 A simple way to avoid unnecessary network calls.

I added one non-blocking suggestion, but the code seems good.

[luixlive]

The validation steps in this method take more lines than its actual logic. We have a couple handy utilities isValidLatitude and isValidLongitude in src/utils/location/index.js that you can export / import and simplify these validations a bit:

import { isValidLatitude, isValidLongitude } from 'utils/location;

const areLatitudeValuesValid = Array.isArray(geoSpan?.lat)
  && geoSpan.lat.length === 2
  && geoSpan.lat.every((latitude) => isValidLatitude(latitude));
const areLongitudeValuesValid = Array.isArray(geoSpan?.lng)
  && geoSpan.lng.length === 2
  && geoSpan.lng.every((longitude) => isValidLongitude(longitude));

if (!areLatitudeValuesValid || !areLongitudeValuesValid) {
  return null;
}
...

[luixlive]

You can add a new describe block in src/utils/map.test.js and ask an agent to add some coverage to this new method:

describe('buildGeoSpanFilter', () => {
  // TODO: Claude, add unit tests for buildGeoSpanFilter here.
});