Move GIS processing to client-side

[cormander]

The goal of moving GIS processing to client-side is to reduce the dependency of hosting an API, and thus dramatically lower the cost to run this.

The primary reason why this is normally done server side is due to the sheer size of the shapefiles of the various district polygons. Between state, congressional, and state legislative districts, they're at a minimum 700 MB. It gets much bigger once you add county and city shapefiles. As a whole this is too much to put into a client-side application, especially inside a bundled build.

However, you can host a large static site on GitHub, and it is able to do a React app so long as you use the HashRouter from react-router-dom for navigation.

I'm proposing we do the following:

• Create a build script that sources https://github.com/unitedstates/districts and other goejson sources and does the following:

  • Sources various publicly maintained repositories of politician info and merge it all together; nobody seems to have the complete set of info (I've done this in the past, code is here: https://github.com/OurVoiceUSA/civic-loader)
  • Use an Rtree algorithm to build a bounding-box (bbox) index of all the shapefiles and bundle it with the React app -- it shouldn't be more than a megabyte
  • The index refers to the URLs of shapefiles and areas on the static site with json objects about politicians who represent those districts

• The react app, after it receives the Lon/Lat coordinates, uses the bbox index to very quickly identify about 10 shapefiles this point is possibly in

  • Those shapefiles are downloaded and a point-in-polygon (available via npm) algorithm confirms which it's actually in, then fetches those 4 files (state, cd, sldl, sldu)
  • Example code of point-in-polygon can be found here: https://github.com/OurVoiceUSA/ourvoiceusa-sdk-js/blob/master/index.js
  • Politicians are displayed along with the district shape overlayed on the map, with their phone number front and center

The React app would exist on a gh-pages branch of the repository, like you do when you do a jekyll site on GitHub. The "build" of the index doesn't need to happen often -- only when people take or leave office, or boundaries get modified.

Any feature left that still needs persistent data (such as rating politicans) still needs an API -- but the hosting requirements go way down as a GIS database is no longer required. And perhaps more importantly - even if the API goes down, the core phone-your-rep functionality persists.