The Final Frontier in Lambda Labs

Nearing the end of my educational experience with Lambda School, I am part of a few cohorts of students in what is called Lambda Labs. Lambda Labs stimulates a real working environment with cross functional teams to accomplish set goals for a stakeholder. My particular team was assigned the project of Bridges to Prosperity.

Bridges to Prosperity is a real world charity organization that build bridges in Africa for underdeveloped regions. These bridges provide a safer route to sell and buy wares, seek medical help, and travel in general for otherwise near remote locals.

Previous cohorts have contributed to this project and we were given an almost complete app. Because of this, my peers and I were worried we would not be able to contribute to the project much. After asking the stakeholder what added features she would like to see implemented, we were tasked with adding shape files to to the existing map via mapbox. On this map was the ability to see completed bridges, bridges under construction, sites identified for future bridges, and site that were rejected for bridges. Adding shapefiles would give the user the ability to see different districts and villages potentially affected by the bridges. We also were asked to implement map clustering. Adding this feature makes it easier to see the number of sites as you zoom in and out on the map. If there are a lot in one area it will appear clustered and make it harder to see them individually. Allowing many to be clustered as the viewpoint is zoomed out will keep it clean, organized, and user friendly.

Clustering was my task to contribute. After watching some YouTube videos and reading documentation, I set forth to implement the code. Our legacy code already had a filter to map over bridge data and create geoson objects necessary for mapbox, so I tried using the existing function with useSupercluster. Unfortunately, it was unable to work without altering the useSupercluster hook completely or the legacy code completely. Having other developers on the team using the legacy code for the shapefiles, that was not a viable option. Instead, I created an almost identical function with the minor necessary changes. This function makes points within a set radius and clusters the bridges together, putting a marker on the map with the bridge count. Should only one bridge return for a particular radius, only that bridge marker will appear, or no marker if none found.

The roadmap for this user story was fairly simple overall as I just needed to import useSupercluster, make a geojson object called points to map over the bridge data and return a styled marker for clusters. Below is a screenshot of the trello board card with the steps needed to add clustering to the map.

I had the task of adding the feature of clustering on our map. It will cluster multiple pins in a designated area together to declutter the map. Zooming in and out will change the clusters respectively.

After adding the necessary code (making another geojson object called points, mapping over our bridges and putting that data in points, and then setting bounds of the map, zoom, and cluster details such as radius of clusters)to accomplish clustering on the map, my team and I discovered that at the current radius, if there are a lot of clusters it slows the app down to the point of breaking. Going back in and changing the radius allowed the cluster to be bigger and fewer as zooming out increasing load time. It also made it cleaner and more user friendly as too many clusters in an area was the same issue as too many single bridges in a single area. Changing the radius to a bigger area fixed these issues.

The previous radius was set to 75px. Having it at this radius gave too many markers on the map as a whole. The map took up roughly 80% of the page, each section of the map being 75px, that renders tons of markers for a heavily pinned and spread out map. As soon as a user tried to zoom in or out the page would break from the sheer number of cluster markers.

At first I tried to raise it 100px, but found that had little effect. 200px proved to be better but still would lag something terrible when zooming in and out, though not breaking the page now. I knew for sure this was the breaking issue now. I decided to make the radius 300px and now the map loaded much more quickly with less markers. It looked so much cleaner as well. Now the real test of zooming in and out. I was able to go almost completely 100% zoomed in on the highest marker area fast and without issues. I tried to raise the radius slightly more with 350px, but that proved to make map appear too free of markers. 300px would have to do.

Oh no, another issue came up! Now all the names of every pin of every stage was displaying the same name, also there was no longer graphs and data displaying when clicking on a pin. Back into the code I went to figure out why. After a little trial and error, I discovered it was because when I mapped over the bridge data, I did not include all of the data set properties in the new points object. Adding some missing properties was crucial as when it does display individual bridges, the information for those bridges are now being pulled from the points in clusters instead of the bridges objects directly.

I am now in the last few days of Lambda Labs. Labs last for 4 weeks. The first week consists of planning, architecture, and deployment. Having a mostly complete legacy code gave very little left to do in this stage other than redeployment. Week 2 is creating user stories, brainstorming new features, and thinking of ways to make current features better. During this time, we came up with a lot of user stories and features that the stakeholder just was not interested in unfortunately or were unable to complete with the current data. Week 3 we finally had concrete tasks to complete to ensure contribution to the project. Week 4 is finishing up those contributions and bug fixes.

During the month, we were able to implement the shapefiles to mapbox, giving different districts different colors when zoomed in. We also implemented clustering of pins on the map, and changed some styling to make the app more responsive and have a cleaner appearance.

I hope future cohorts will be able to combine the clustering with the shapefiles and highlight certain areas that the clusters include. Also having a temperature color for a district or village level would be good to see how far outward the impact of each bridge is. It will show areas that are in more need of a bridge because they will not be highlighted or could even be far away from a highlighted section.

Overall, I do not feel as if I have learned very much in Labs. Having a mostly complete project from day 1, lack of data, and nullification of user stories from the stakeholder did not leave much to learn. Even with these obstacles, I still feel I was able to effectively contribute to the project. I learned about mapbox, how to deploy with AWS, and how to cluster pins on a map. I don’t know if I will need any or all of these skills in the future, but I feel good about knowing them. I love to learn, and I will keep learning and growing my skillset and self.

I am glad to have had the opportunity nonetheless of working with such a great team of developers and data scientists. I cannot wait to see what the future holds for each of them!