Clip allowed area filter

[taba90]

When defining a spatial filter the user will be able to define whether the filter should be applied as an Intersects filter or as a clip filter thus cutting filtered features.
A new combo box will be available in UI on layerDetails tab and ruleLimits tab to select the spatialFilterType.

A new field will be added to RuleLimits and LayerDetails to hold the value of the spatialFilterType.

[etj]

According to https://github.com/geoserver/geofence/wiki/Rule-matching, constraints are merged inside GeoFence.

There are 2 main points where area are merged:

• When rules within a group are coalesced: here constraints are limiting more and more the access, so areas are merged using intersection. Here we can select the most restrictive filtertype:
  • CLIP + INTERSECT --> CLIP
  • CLIP + CLIP --> CLIP
  • INTERSECT + INTERSECT --> INTERSECT
• merging of accessLimits belonging to different groups: here the constraints are merged so that the user is granted the accesses she would get by belonging to each single group. This means that the restricted areas may be completely disjunct, but the user is granted access to all of them.

In this latter case we may have different areas with different spatialFIlterTypes, but the filterType returned to GeoServer needs be only one.
So, in the case we have 2 areas with 2 different filterTypes, what shall we do?

• Convert all to INTERSECT: we may give too much permissions around the area we want to be clipped
• Convert all to CLIP: let say the user has the first area (INTERSECT'ed) in her first group, then was added to a new group allowing CLIPped access to a completely different area; she would then have less grants on the area she first had when belonging to a group only. So, adding the new group would remove some grants she already had.

A design decision has to be taken about this.

[nmco]

I see you point @etj, thinking out loud, the ideal solution would be, obviously, that if a rule define a clip, than a clip is performed, if the rule defines an intersection then and intersection is performed.

If my memory serves me well, the clipping is always done on the GeoServer side, Java code. Hence, why not:

• Getting the merged rule as usual from GeoFence including the geometry to filter by, send it to the source store with an intersect.
• Then extend GeoFence to allow us to retrieve the individual geometries that we need to clip by and apply them.

Does this makes sense? @etj I have asked help from @taba90 to double check if this is possible to implement, and how much would it cost, he will ask you for guidance and support ✈️.

If the above is not possible, then I would go whit falling back to the more restrictive one, hence clipping.

[etj]

@nmco what is returned to GeoServer is not the content of a single rule, pls see https://github.com/geoserver/geofence/wiki/Rule-matching

[etj]

If the above is not possible, then I would go whit falling back to the more restrictive one, hence clipping.

This implementation would cause undesired results, and users may think something is broken when they are added to other groups. Pls check the case "Convert all to CLIP:" in my previous comment.

[etj]

A proposal may be:
we keep 2 different sets of areas:

• allowedArea -> handles intersection aread
• clipArea -> handles clipping areas

Areas returning from groups, with spatialFilterType=CLIP will be unioned in the clipArea, while
areas with spatialFilterType=INTERSECT will be unioned in the allowedArea.

These 2 areas will be returned to GeoServer in order to select 2 sets of features:

• the features intersecting the allowedArea will be returned to the client as is (which is the current behaviour)
• the clipArea will select a set of features,
  • the features in common with the intersecting set will be removed from teh clip set, in that they aer already fully returned
  • the features left will be clipped according to the clip area

[aaime]

Intersection is filtering, clipping is manipulation, they are two logically separate steps:

• Intersection goes into the data source, it's a filter, "give me everything that is overlapping with this reference geom"
• Clipping is result manipulation, "for every geometry returned, cut using this cookie cutter"

@nmco in GeoFence one can have two (or more) limit rules, one using a intersects filter, the other using a geometry clip. That's where the headaches start.

Mixing the two is messy:

• In the filtering step, one can add the clipping geometry in the filter, in OR. This part is clear.
• In the clipping step, one would have to cookie cut on a geometry, but what to do here?

The clipper should be smart enough to clip on the clipping geometry if the feature geometry is intersecting it, but don't do it, if the feature geometry is also overlapping with the "intersects" geometry? Bit weird IMHO, but would respect the logic of "using the looser of the two rules". It would mean bringing around clip and intersect geometries as two separate bits, and be able to also expose them as separate in the GeoServer rule... which is not difficult, since a read filter field is already available, just add a clipping geometry one.

[nmco]

Meeting minutes 21-12-2020:

• Rules in GeoFence get merged differently per group \ role.
• When in the same group the more restrictive win, clipping in this case.
• When merging different groups the more permissive will win, in this case intersection.
• One thing to think about is how to share with GeoFence users the new schema updates.

[etj]

Merged in 3.4.x: #164