[FEATURE] Improve client annotation rendering

[jacksonjacobs1]

Description

The current rendering approach does not perform equally across different zoom levels because:

1. We render a greater number of WebGL features while zoomed out
2. We render a greater number of points while zoomed out

A better rendering approach involves the following changes:

1. Decouple each WebGL feature from a single tile (and tile id). Each WebGL feature should be capable of including annotations from multiple tiles within a group.

2. GET Tile endpoints should accept a grouping_factor parameter, which causes a group_ids array to be returned.

   e.g.,
   Given a 4x4 tilegrid of ids 0-15, say we get all tiles, with grouping_factor set to 1 (defualt)

   resp.tile_ids = [0 - 15]
   resp.group_ids = [0 - 15]
   

   With grouping_factor set to 2:

   resp.tile_ids = [0 - 15]
   resp.group_ids = 
   [0,0,1,1,
   0,0,1,1,
   2,2,3,3,
   2,2,3,3]
   

   With grouping_factor set to 3:

   resp.tile_ids = [0 - 15]
   resp.group_ids = 
   [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
   

   The client then only requests annotations for each unique group_id. Each group_id thus corresponds to a webgl feature.

3. Create a new endpoint for getting annotations within multiple tiles. This endpoint should also accept a simplification threshold so that resulting polygons are simplified to reduce the number of points to render.

[choosehappy]

i'll need to think about this a bit more - it feels like the UI already knows which ones are grouped, so could instead loop over them internally as opposed to having the backend figure it out - or are you proposing this because its easier to write in python than JS?

you can likely do this as part of the DB sql query, and have a dynamic field called "group_id" computed based on the tileid with a bit of finesse

or...alternatively....maybe there should be a separate endpoint that simply accepts a boundingbox and group_factor, and returns the tile_id numbers? then the UI can request them however it would like? this would require an additional round-trip, but the pay load would be tiny, so overhead practically nothing

[jacksonjacobs1]

Yeah... I was debating back and forth whether the client should just perform this conversion - the downside is that we then need to put a tileSpace-esque function in the client to map tileids to groupids. this function would have to leverage the base image width and height, work_tilesize, and base-to-work scaling factor, increasing the risk of bugs.

I felt like it would be safer to keep this functionality in our backend. Thoughts?

[choosehappy]

ah i think i misunderstood -- there is no DB query actually being performed here, is there?

i don't know that anything should be modified to accept a "group_by" - instead i would imagine a helper rest endpoint that is in the backend which accepts e.g., classid, tileid and a "distance" , and returns sets of IDs in groups

the UI would then do whatever it liked with that information

however our current Tile GET/DELETE (others?) endpoints should all accept lists of tlieids and not just single tileids. our DB calls should be modified from pseudocode "tileid == query_tileid" to "tileid.c.in_(query_tileids)"

do you see what i mean? this may be what you suggested but i mentally parsed it incorrectly

[jacksonjacobs1]

This is different from what I suggested, but I like it much more!