brainstorming querying alternatives

[answerquest]

I'm confident that the present mapbox querying solution will still work out fine; but just for some nerd fun and potential future use I want to work out decentralized alternatives for the core problem statement of this project : If you throw up any lat-long, how to figure out which polygon it is in, from a vast number of polygons with complex and heavy data, with a limit on amount of bytes that can be loaded for the job?

Here's one strategy:

• generate bounding lat-longs for all constituencies. So 4 numbers : min_lat, max_lat, min_lon, max_lon
• make a simple csv table of that along with all metadata per constituency : codes, state, election phase, date (or maybe a separate lookup table for phase > date?)
• load the table up on page load
• When user clicks a location, filter the table and arrive at just the small handful of rows for whom the lat,lon is within their bounds.
• Load up their shapes (stored separately of course) and check using point-in-polygon (there's turf.js but there's others too)
• When a match is found, publish the result (ie the metadata/attributes of the constituency that were stored as CSV)
• If wanted, render the constitudency boundary too on the map as a non-ineractive geojson layer.

To prep up the data for this kind of thing, here's what would be involved:

• if we start with the Parliamentary Constituencies in ESRI shapefile format: https://github.com/datameet/maps/tree/master/parliamentary-constituencies
• Generate 4 metadata values for each item: [min_lat, max_lat, min_lon, max_lon]
• Create a CSV (one PC per row) with the attributes that were, plus these, plus the extra stuff like election dates, hindi names etc if possible.
• Split into individual .geojson's for each shape. (and name them properly, like {state code}_{pc code}.geojson - that's important!)

Depending on how we do this, the splitting could happen first or last.

Benefits of this strategy :

• Avoids having to load up enormous amounts of geo-data. The shortlisted constituencies will be mighty small in number - in many cases there'll be directly just one possible match. In other cases, there many be two, maybe four.. but very small number.
• The calculation will be almost instantaneous and loading won't take very long either (CSV and a couple of geojsons : both gzip well too) - so this might actually perform faster than an API call. It would be fun to pit the two methods against each other and time them.

[planemad]

An interesting and useful problem to solve! The algorithm sounds like it should work fairly well.

[answerquest]

Made a python program for preparing the data:

import fiona
from shapely.geometry import shape
from collections import OrderedDict
import pandas as pd
import json

shapefile = "shapefiles/india_pc_2019.shp"
DEV = False

metaCollector = []
counter = 0

# iteration statement from https://gis.stackexchange.com/a/120574/44746
for pc in fiona.open(shapefile,'r'):
    
    a = pc['properties'].copy()
    b = shape(pc['geometry']).bounds
    # from https://gis.stackexchange.com/a/90556/44746
    # Returns a tuple of 4 like: (91.14863890266327, 23.06298596293192, 91.73082235147041, 24.111512008872182)
    
    # importing the bounds into the metadata
    boundLabels = ['min_lon','min_lat','max_lon','max_lat']
    for x in range(4):
        a[boundLabels[x]] = b[x]
    metaCollector.append(a)
    
    # they're natively geojsons! Just dump'em!
    json.dump(pc, open("shapefiles/PCs/{}_{}.geojson".format(a['ST_CODE'],a['PC_CODE']), 'w'), indent=2)
    counter += 1
    print("{}: {}({}) / {}({})".format(counter,a['ST_NAME'],a['ST_CODE'],a['PC_NAME'],a['PC_CODE']))
    
    if DEV and (counter > 10): break

df = pd.DataFrame(metaCollector)
df.to_csv('pc_metadata.csv',index_label='sr')

[planemad]

Theres an alternative approach by encoding the vectors as a bitmap and using that as a lookup topojson/topojson#311 (comment)