Why is it needed?

1. Ramp is not the first project aimed at mapping the ”missing millions”, and we look to benefit and expand upon the numerous efforts in this space from the last several years. There have been large releases of building footprint data across huge geographic areas in the past, including the Facebook and Google open data releases, and there are also widely-used platforms including OpenStreetMap that make building footprints available to the world at no-cost, but these projects have their limitations. The open releases of Facebook and Google have yielded incredible insight for organizations like the WHO and UNICEF, but the technology behind how the data was produced, essentially the documentation, codebase, training data, etc., have not been released in a manner that can support replication or extension of these efforts. OSM does indeed provide invaluable access to localized data, but the data is generated manually by individuals and through crowd-sourcing efforts, so this platform is great for hosting but is not currently a pathway to large-scale data creation. The ramp project builds off past open releases and open mapping competitions with a distinct focus on making every aspect of the project openly available to the world. Open competitions often release training data, and are good sources for discussion on best practices, but the scope of the project goal is typically much more limited than what we’ve cooked up for ramp – which is delivering a baseline model for footprint extraction that performs well across diverse geographies, and a ‘fine-tuned’ model that will exceed 90% accuracy in building extraction across Bangladesh.
2. These models are coupled with thorough documentation, jupyter notebooks, and a significant amount of training data that GIS Analysts and Data Scientists alike can use to create their own fine-tuned models over a geography of choice. A primary objective of our project is to lower the level of effort required to use ML to extract building footprint data, hopefully only needing to create a small amount of training data specific to a new area of interest. Historically, if an organization wanted to create a machine learning pipeline to extract buildings over satellite imagery they could reference past competitions for insight and direction, but there is still a need to construct the code-base, curate a significant amount of data and then pull this all together to create an output, all the while the event being supported is actively unfolding. Ramp codifies much of the preliminary work in a codebase that is fully open, and put to use via Jupyter Notebooks that then allows an org to just focus on creating a small amount of training data that can be used to generate a new “fine-tune” model that will work exceptionally well over the desired geography.
3. Another primary objective of our project is shifting the production of these data to the regions where the work is being done. By creating a ‘building extraction toolkit(ramp?)’, we look to empower local actors with the tools needed to create their own building footprint datasets. Modern machine learning solutions to satellite imagery problems typically require some sort of cloud computation or powerful hardware that can easily get into the $20k+ USD range, which can be out of reach for many mapping organizations in LMICs, let alone an individual. Our open approach enables a GIS Analyst to take what we’ve done and apply it to their region of interest without needing to procure access/storage on a cloud computing system. Further, once the localized training data has been created and integrated into the model, the GIS Analyst is well positioned to respond to their next mapping need with even greater quickness.

What does it support?

1. On-demand mapping in LMICs to support disaster planning/response and microplanning. 
   1. Take for example an unfolding natural disaster in Laos, like a major flood event. In order to get an understanding of the potential impact to human lives, which in part dictates the response, there would be a rapid response team gathering data from sources including OSM and national/sub-national land records to map the population distribution ‘pre-event’. The data from these sources will have varying levels of accuracy, and no immediate ability to refresh that data aside from manual digitization. The ramp project greatly reduces the time needed to create an updated map of where buildings existed prior to this flood event as the rapid response team would only need to feed the machine learning model a small set of training data to “fine-tune” the model so it can extract building footprints against the most recent satellite imagery over the impacted region(s). This solution of course still carries its own challenges, but the reduction in time associated with data creation can be repurposed towards planning the response with a more accurate and recent map.
2. Capacity enrichment at gov institutions, NGOs, universities.
   1. The name for our project is not just a GREAT acronym ;), it is also reflective of our approach. We hope to create a ramp that other institutions and individuals can not only benefit from immediately, but also serve as a launchpad to expand upon the scope and outcomes of our first iteration of ramp. Thorough documentation, openly available training data and code will enable the global development and humanitarian communities to integrate this approach into their own map production workflows, which we hope sparks new and innovative ideas on how this can be used to serve program needs far beyond what we have envisioned.
3. Having a server-based approach broadens the user pool so cloud-based processing is not a requirement.
   1. Our deliberate decision to avoid a model that is optimized for cloud-processing has its roots in our human centered design of the project. Through interviews with our technical advisors it became evident early on that cloud-based optimization cannot be our initial focus, as that would exclude a large number of users from leveraging our tool. The cost of cloud computing is no secret, and the stories of massive bills for large-area computation rightly bring pause to organizations working on thin budgets. The speed of cloud computing cannot be matched with ramp, but we can easily contain the costs of a given mapping effort given our server-based approach. This looks to broaden the user pool for organizations and individuals who are tasked with the production of on-demand maps for both project planning, monitoring/evaluation, and event-respons