Map Filter search by resource layer feature

[whatisgalen]

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of Change

Screen.Recording.2024-04-24.at.12.13.11.AM.mov

Overview:

• map popup sends afeature to a method in map-filter.js called filterByFeatureGeom().
• the method adds this feature to the map-filter as if a user had drawn a feature.
• the user can alter the feature on the map to adjust the filter as they want.
• clicking a new feature removes the old one from the filter, replacing it with the new

Issues Solved

#10816

Checklist

• Unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Ticket Background

• Sponsored by: @scholiumtech
• Found by: @whatisgalen
• Tested by: @bferguso
• Designed by: @whatisgalen

Further comments

blocked until PR #11056 gets merged (done)

[whatisgalen]

My new test is failing, debugging that. In the meantime the feature is definitely testable.

[whatisgalen]

issues fixed via the latest commits:

• clicking a new feature replaces the old one in the filter with the new, as expected
• the featureid from the clicked feature is used to look up the matching one in the resource descriptor geometries' filters
• the lookup via featureid in the backend map-filter logic has been removed. All payloads now have a geojson feature collection

[bferguso]

Actually, it seems like featureGeomIndex is always zero, regardless of which geometry is selected. This is true if there are 2 geojson nodes, or 2 features in a single geojson node.

[bferguso]

I'm seeing in my instance that feature.id is in the format 9caa54cd72738367ea32eda99400c385 and popupFeatureObject.featureid is in the format 9caa54cd-7273-8367-ea32-eda99400c385 so this is never returning a geometry.

Seems like the feature.id is stored without the hyphens in the tiles.tiledata column.

[bferguso]

I think popupFeatureObject.feature.properties.featureid should be used insetead of 'popupFeatureObject.featureid. Using 'popupFeatureObject.featureid always results in the first geometry in the resource being selected.

[bferguso]

This is looking really good!

I came across one issue - I created a bunch of geometries using the trigger views to do some load testing, and the trigger views don't add the featureid to the tiledata. We'll need to populate that value from the trigger views to allow geometries to be added that way.

The featureid is there for geometries created through the system. Wondering if:

1. There should be a migration that adds any missing featureids if they're not present.
2. The trigger views need to be updated to populate featureid if populating geometries that way.

I don't use CSV import or bulk importer, but wondering if those processes do/do not populate featureid as part of those processes.

I'll manually add the featureid to the tiles that are missing it, but I think the missing values would be problematic for users with geometries not created with the UI.

[bferguso]

Currently only one map geometry or feature can be used as a geometry filter. Perhaps this should read "Filter by Map Feature" instead? The term "Add" is somewhat confusing since it will clear any existing geometry filters.

[bferguso]

What about using a funnel icon instead? (ion-filter icon) Or a magnifying icon, which is used as search elsewhere (fa fa-search)?

[chiatt]

@bferguso It looks like @whatisgalen addressed the change you requested. There was a scoping issue that popped up after that fix (which I think you may have observed) but Alexei fixed that in a90dfaa. I also noticed that the filter button would appear in the map widget within the resource editor. Alexei was able to take care of that as well.

[bferguso]

Looks good!

[whatisgalen]

Per my comment, the featureid was removed from the request payload to the backend (map-filter) because if the user edited the drawn polygon on the map, (for example to cover a larger spatial query area) the feature identified by featureid would differ from the query geometry, and there wasn't a great way to confirm whether the geometry had actually changed (given potential precision differences). This would have yielded search results out of sync with the search query.

However, because the only payload is the geojson feature itself, this means large coordinate sets can exceed the character limit on the GET request header (and url length in the browser). Unfortunately, those requests then fail, hence #11578 and the need for #11582