Add "link to layer by spatial relation" analysis

[AbelVM]

The idea is to have a "Link to layer" ("filter by layer") analysis but using a spatial relation instead of a column match.

v.G: I have two layers, "species" (dots) and "wards" (polygons), and I want to link the dots layer to the polygons one with the relation "dot within polygon". As of today, the flow is like:

But it would be so cool if this is a standalone analysis, where the spatial relation is selectable (within, contains, overlaps, disjoint, intersects,... the most common ones)

cc @saleiva @javisantana

[saleiva]

We have two options here...

Adding a new card to the analysis which would be called ___ and do this, or just add an extra option to the Filter by layer analysis where you can specify if you wanna use the_geometry or a pair of columns.

[AbelVM]

And show a combo for the available spatial relations options

[saleiva]

Can you elaborate on why would you want more than intersectino?

On Jul 15 2016, at 10:30 am, Abel Vázquez Montoro <notifications@github.com> wrote:

And show a combo for the available spatial relations options

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[AbelVM]

The most common relations are:

1. Intersects: we are cool with this
2. Contains / Within: returns features of one layer FULLY contained in the features of the other, without touching the borders
3. Overlap: intersects but A != B, so the intersection is not 100% => St_intersects(A, B) AND NOT st_equals(A,B)
4. Touches: to retrieve the neighbors
5. Dwithin (buffer + within in just one shot)

(quite naive) Examples, buildings layer and plots layer:

1. The buildings that may or may not have a portion of them located in a 2nd plot, or even outside a defined plot.
2. The buildings totally contained in a unique plot
3. The plots that are wrongly defined and overlap
4. The buildings that share walls with your building
5. The buildings that are closer than N meters to your building

[AbelVM]

We may add disjoint to get the geometries that don't fit in any of the filters 1-4

[andrewbt]

+1 this came up with a current use case sales conversation with a cellular telephone network company. They have AOIs around their stores, and want a widget that filters down the zip code polygons that intersect those AOIs. So, "Filter by layer" based only on spatial intersection.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[andrewbt]

@hannahblue I believe you're the relevant product manager for Builder Analyses so based on your own recommendation I'm pinging you :)

Ping @jsanz since he gave this a thumbs up back in the day too. Should we advocate a priority for this one?

[hannahblue]

Thanks @andrewbt :)

I'm trying to make sure I'm picturing this correctly. This sounds similar to the Filter Points in Polygons analysis. But with the ability to choose how it's related (intersect, overlap, within, etc), and have that chosen and rerun dynamically via a widget selection?

Other than the part I italicized does Filter Points in Polygons get the basic job done or am I misunderstanding something?

[stevelewis99]

Is it valid to also want to filter polygons within polygon[s]? Or should it only ever be points? Just throwing it out there as I've been having to do this manually using SQL.

And.. @hannahblue it feels to me like the natural place to go and look for this type of 'spatial linking' is filter by layer, but on reflection that is only due to me now thinking like CARTO because when I first starting using Builder the "filter by layer" term didn't make any sense to my brain, I didn't recognise what it did on first glance of all the analyses... However, once I understood it, I was like "ahhhh.... why is it called that though?". But that's just an aside, and a much wider topic (not for here) as I remember how it looks to a fresh set of eyeballs.

[andrewbt]

@hannahblue I actually most like Sergio's "just add an extra option to the Filter by layer analysis where you can specify if you wanna use the_geometry or a pair of columns." explanation above, and Abel's addition to it "And show a combo [box] for the available spatial relations options". If that helps clarify, you almost don't have to read further...

This is a bit like a hybrid between the "Filter points in polygons" and "Filter by layer" analyses. Ignore the "choose how it's related (intersect/overlap/etc)" part for now - that's important but not central to the concept - and think just of one kind of spatial intersection.

"Filter points in polygons" is applied to a polygon layer (something my brain's always struggled with, applying an analysis to it's predicate, and I often first apply this wrongly to my points layer and have to go back, but that's a sidebar and I don't know how to improve the wording) and filters a points layer to only those points spatially contained within the polygons - once run the analysis "node" transforms from a polygon layer to a point layer, but has additional columns about the polygons those points were within.

"Filter by layer" is applied to any layer, and needs a common column (name, unique ID, etc) with another layer, so that widgets applied to the other layer will also filter this layer. (Oddly enough, a widget applied to the "filter by layer" analysis node layer will not do anything - another sidebar area where we could improve usability/guidance somehow)

What a "Filter layer A by spatial relationship to layer B" analysis would do is make it so any widgets applied to layer B would also filter any records in layer A based on their spatial intersection criteria. In essence, just what "Filter by layer" does, except without the need for a common column - because thanks to the magic of geography we have all the commonality we need, common space! We frequently reference this in our marketing - because everything happens somewhere, location is the only "unique ID" you need to find out how one thing/layer is related to another thing/layer...and yet "filter by layer" requires a unique ID ;-)

Currently, the partial-workaround Abel detailed above that uses the "Filter points in polygons" analysis and then also the "filter by layer" analysis does get close to this...but only for the polygon=>point pairing (a second "filter by layer" in the reverse direction is needed afterward for the point=>polygon case). We have no way to "filter by spatial relationship" for polygon=>polygon or point=>line or line=>point or polygon=>line or line=>polygon or line=>line, because even though the "filter points in polygons" is actually just doing an ST_Intersects() query behind the scenes which would be geometry agnostic, the analysis limits the layers it lists for its parameters by geometry type...

Also here's a CARTO file that illustrates the workaround if it helps ("what rail stations are in which neighborhoods?" and add a "filter by layer" on Layer A0 for the corollary "what neighborhoods contain which rail stations?"): Filter Rail Stations in Neighborhoods by Geometry (on 2018-02-20 at 23.29.34).zip

@stevelewis99 yes polygons intersect/contain/overlap/touch/dwithin polygons! and polygons and lines, or lines and points, or...or... 😂 Seriously though, that use case I described above last year with the telco was trying to determine which postal code polygons were at least partially covered by an AOI drivetime polygon. We definitely should not limit ourselves by geometry. Also +1 on your "what does filter by layer mean" comment and better wording - will need to think on that myself.

[hannahblue]

Yeah, I'm familiar with how the analyses work. I think my work-around was similar to Abel's, but you're right about the limitations. I'll keep this on the list for Analysis improvements.

Btw, @stevelewis99 we've spent time reviewing and updating the Analysis names and descriptions. We'll be announcing and releasing the updates in the next few weeks. Here's the github issue for reference

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.