The evolution of technology continues to create many possibilities that seemed impossible decades ago. In Dr. Lillian Pintea’s presentation, he stated one thing that resonated with our team: How do we take Data and convert it into Conservation Impact? While listening do Dr. Pintea's presentation, we heard the importance and value of involving stakeholders in the map creation/review process and the power of the TACARE process. This empowerment and grass roots approach inspired us to think outside the box.

Coming from a development perspective, we know the value of managing changes to code and having a workflow to approve and review code. Each change is documented and there is a history available that can be referred to. The thought came to mind, why can't we do this for maps? Most map data formats that we came across did not allow for this type of workflow. Enter GEOJSON!

GeoJSON is a standardized JSON format for storing GIS data. ArcGIS and other popular GIS platforms can easily consume this format for further analysis.

By storing map data in GeoJSON format, we can take the approach of map data as code and version control it just like any code. This isn't a new idea. While doing research for this hackathon we came across ( and ( . We felt that this ability to keep a history of map changes would be a huge value to the JGI team. This inspired us to store and version control map data in GitHub. GitHub also has integrations to be able to view GeoJSON data on a map ( See all of our map features stored as GeoJSON in GitHub repositories here (

What's more grassroots and empowering than allowing stakeholders to create their own maps. Open source map features. We chose to integrate using the Esri ArcGIS javascript library and use our own backend to store data as it is more accessible. The only thing a user needs to do to create a map feature is create a free account. All you need to create an account is an email address. This easy accessibility is vital to allow for an open platform. Certain features could be made private in future releases.

This year has had its ups and downs with the COVID-19 situation and good data driven decisions in the sciences are more important than ever. This project gave our team a real experience on how collaboration in technology can be used to benefit the world. All of our team has all served the non-profit sector in some capacity and we understand resources are scarce. Many times process and operational improvements are an afterthought because of competing priorities. This project was an amazing opportunity to give back to an organization that gives so much to the world.
--And yeah, we also are a team that loves to hack code for good

What it does

TacarEZ is an application that solves a workflow challenge for the Jane Goodall Institute. How can the process of new map changes be quickly iterated so that stakeholders can have the most relevant and up to date information? The workflow can be broken down as follows

Precondition: -A feature owner (could be someone at JGI or another stakeholder) has a map feature that is currently the source of truth used by stakeholders.

-A stakeholder with new information can request changes to the feature by creating a revision. This revision copies the original feature and gives them access to modify the feature data. Once they are done with their revisions, they can request that their changes be merged into the feature.

-Once a merge request is submitted by the stakeholder, the owner of the feature gets a notification that a merge request is awaiting action. They own a copy of the revision (known as a merge request) where they can make modifications and review the changes. The owner can then request a stakeholder approval to get input from others.

-The stakeholder approval is a DocuSign ESignature envelope that contains the map data, change notes and links for stakeholders to explore the map data. The map data is hashed which proves the integrity of the data for the signers.

-Once all stakeholders sign the review, the feature owner will get a notification that the review is complete. They can then approve the merge request which takes the changes and applies them to the original feature. This is now the authoritative map feature.

How we built it

(See Architecture Diagram on Figure 2)

The front end is a single page application built with Angular and the PrimeNG component library. It is hosted as an Azure Static Web app. The database for our application is a Azure CosmosDB database. Map data is stored in our GitHub repo and is compiled into map views using Esri ArcGIS javascript API.

The backend consists of 4 microservice API hosted with Azure Functions.:

DocuSignAPI (Handles auth, sending envelopes, retrieving envelope data) DocuSignWebHookAPI (Handles events coming from DocuSign) GitHubAPI (Handles auth, creating, reading and updating repositories in Github) TacarEZ API (Integrates all API and provides access to the database for the front end)

The front end authentication provided is Azure B2C.

How we collaborated

Microsoft Teams and Miro: See our board:

Challenges we ran into

The biggest challenge we had was that our data points in our custom front end web application did not refresh fast enough for us. It took a lot of time trying to debug this and figure out why the most recent map data was not being pulled after saving. Since we are using GitHub to host our map data, we found out that there was a caching issue. We created a hack fix to solve this but it took a while to figure it out.

We also wish we had more time to complete this project. We have a ton of features we want to implement and hope this MVP does our work justice.

Accomplishments that we're proud of

We are very proud of our custom web app. Modern technologies such as Azure make it very simple to stand up custom applications. We are also proud of what we could accomplish as a team in remote parts of the US. Our team is located in different time zones but we were able to find time and build something we are proud of.

What we learned

This was a project of many firsts (first time developing with DocuSign, ArcGIS, CosmosDb, Github API).

I wasn’t aware of DocuSign’s robust API capabilities. I thought it was just a PDF tool but it’s so much more after digging into the documentation. This was also the first time working together on this project as a team.

We learned each other’s strengths and opportunities. It also allowed for us to ignite our passions and inspirations around technology, science, and non-profits.

Known bugs/issues

Please excuse our messy code. No time for refactoring!

Sometimes the page fails to load. We believe this may be due to all of the map scripts that are being loaded. A simple refresh usually does the trick. does not redirect to If you are getting a 404, make sure you type the www. This is a limitation of how we are hosting the application.

All API are built on a serverless platform. There is a cold start associated with these request. Initial requests take longer than subsequent requests.

The map preview included in the DocuSign stakeholder review document is generated from visiting a custom screenshot page and taking a screenshot. This is a hacky way to get a map image. Because this involves loading a page and taking a screenshot programmatically, results sometimes vary based on load times.

What's next for TacarEZ

We would love some stakeholder feedback. This was a learning experience for us all and we would love to see how we could improve in both technical aspects as well with our presentation.

As software engineers, we're never fully satisfied with the work. There are always more ways to make the product better, faster, more secure, accessible, etc. Here are some product features that we would love to implement in the future:

-Each change to a feature or revision is documented with a change note. We believe it would be valuable to be able to provide these notes so that make reviewers can read how the map changed over times.

-Load older map layers. We believe it would be valuable to be able to load a map feature and step back in time to older versions of the map to see how it changed over time.

-ArcGIS limits editing to only one type (point, polygon, line, etc). We only implemented creating point features for our proof of concept. We would like to implement these other types for new maps.

-Dynamic feature attributes. Currently we limit the properties/attributes that a feature can have. We believe it would be valuable for users to define their own attributes for their map features.

-Implement more DocuSign roles. We currently only have the "Signer" role for DocuSign. We know it would be valuable to add more roles.

-Resending DocuSign envelopes. We believe it would be valuable for map feature owners to be able to manually trigger DocuSign to resend an envelope to a Stakeholder.

-Recent map features. We believe it would be valuable for users of our application to have a way to view a history of the most recent map features they have viewed and easily navigate to common features that they use.

-ArcGIS service. Like JGI, many teams use ArcGIS for analysis and map building. We believe it would be valuable to expose a service that makes it easy to import map data into ArcGIS. Currently, if you want to import data into ArcGIS, you need to save the GeoJSON and import it into ArcGIS.


More videos

For part two of the demo, (too much too cover) follow this link:

For anyone interested in a look behind the scenes of our application follow this link:

Anyone interested in a more in depth breakdown of the features and demo, follow this link:

Built With

Share this project: