search

klpdotorg / dubdubdub

Home of KLP. Houses *most* of the data and APIs.
MIT License
5 stars 4 forks source link

hierarchy aggregation road map #145

Open geohacker opened 10 years ago

geohacker commented 10 years ago

This is to outline what involves in the boundary aggregation -

  1. Templates for each levels.
  2. Database refactor - We will have to considerably change the way boundary information is stored in the database right now. Flatten it out from the current parent-child relationship to an OLAP structure (like what we did with DISE).
  3. Run the aggregations - The aggregation logic is not trivial. We cannot possibly aggregate all the variables at all the levels. This needs some homework and need to make sure that this is part of the workflow in a clean way so that if we add/remove a boundary, it's easy to generate the required data.
  4. Change the way years are stored - The aggregations need to happen based on the academic year and the way it's stored is not useful. We need to refactor this, apply it across other tables, create relationship.
  5. Create API endpoints - A fairly complex set of API endpoints need to be built to bring the data to the front-end. For comparison, volunteer and information.
iambibhas commented 9 years ago

We can put the aggregated data inside /admin/:id endpoints.