Episode 42: The “Things” about Maps [Final Project Week]

On a late Sunday afternoon, a team gathered on this online platform called “Skype”, to reunite with an idea. Most came up with ideas from data visualisation books and others, spontaneously. It branched off from topics such as eco walks , sleep patterns to topics such as an altitude map for those who were scared of heights.

However, it was wise Lewis, the 29 year old Laboratory Research Scientist or for your understanding (the frog), who had an idea that resonated in everyone. An idea that not only educated the public but an idea that gave freedom to the public, of what they wanted to be educated by.

This idea was to “create your own map” and learn about the place you are in based on where you go and your interest.

In other words, a travel diary.

Our First StandUp Onwards:

On Monday morning, we started to flesh out this idea of what this travel diary could be. Eva prompted the question: “How would you summarise the idea in one sentence.”

At this point, we realised that we were drifting away from the “education” concept and wanted to something that possibly had a purpose of educating but not entirely. We wanted this travel journal to not only document one’s places, tracks and memories of those places around the world. We also thought it be a cool idea to make it social, to see where your friend or people base on your interest had travelled to as well.

Hence, we concluded that we wanted to make

“A social travel journal with a map interface.”

We believed that the travel journal idea done by digital platforms were not as interactive or user friendly, and technically thought that it was going to be a challenge. Our next strategy listed our the “Needs” of the idea and “Nice to have’s.” This allowed us to segregate on what features were priority and to also to have potential to start thinking about our MVP.

However, immediately once we had this one-line idea set in stone, this idea bounced different interpretations of how it could look, in mind and thus, we had to flesh it out to get a balanced view of how we all imagined it.

We adults definitely know how to draw the map of the world.

It would good to get our interpretations out there to get people in the team to see what we individually saw. It also gave a rough outline of what features we would go where and how it could work. This open other ideas for features.

Given that we suddenly had a kick-off in five minutes, we quickly listed out what things we had to research or do today to sort everyone’s mind of the list of things that needed to be done. What was great about a to do list was that we had options of jumping to another topic if we got stuck, or if we wanted a change of scene.

Setting the end goals for the end of the day ended up quite vital, given that the project was under a time-frame and that the goals wouldn’t linger on.

• Knowing what technology we were going to use and familiarise ourselves with it
• Investigate testing frameworks (such as Jest, Mongoose)
• Having this answered by the retro

Coming back from our kick-off, it stepped up the process by a notch and we got down to documenting some user stories. Through the process, apart from concluding the user stories, we decided this app was going to be a web app given it would work nicely with the map interface.

Categorising the user stories was a smart strategy to use as it forced us to think small. We started from the top left, coming up with our MVP ( Minimal Viable Product ) and thought carefully on what made our project unique.

Given we wanted a map interface, most of our MVP did the following

• See a map on screen
• Drag a pin on the map
• Save the pin on the map
• Load the pin on the map

Having these as small things to implement will allow to stay focus on the objectives, and not stray into struggling of building a bigger problem. Finally, we ended up setting a list of things that everyone set out to do in order to make sure of our number one goal of the team.

“That everyone was on the same page”

Goals were to familiarise ourselves with Map-box, with testing React and Figuring out the Back End

So, with all this in mind along with the list of things to do, our first objective was “knowing what technology we were going to use and familiarise ourselves with it”

My Morning Venture, MapBox:

MapBox is a web mapping library that allows developers to acquire maps in web or mobile applications. Many great companies such as Airbnb, National Geographic and Pinterest have used it. It’s a library that allows one to do the following:

• Get the datasets for the map (streets, location, etc)
• Custom your own data via an Api and use it.
• Geocoding (This means to translate an address into coordinates, visa versa)
• Customise the styling for the map
• Create static maps through programming (if you want to)

One could say you could just use Google Maps from the Google Api. However, as developers and craftsmen, we want to have as much full control and customisability of a map instead of having restrictions. Hence, Map-box was the better option for us to use, given it did this in many ways more than Google’s.

To get the datasets or use the functions of MapBox, they use webApis. We can use it for either two reasons. First, to retrieve data and second, to use the Mapbox functionality. Given that Mapbox communicates via apis, we would have to suggest to the api on what data or function we want to use.

In the api request, you have a base link (which is from mapbox, and ends with a json), a mode input (they’ve used mapbox.places, which I assume is a set of data), a query input (which they’ve used Chester, which is a place) and finally an access token key, which will allow the access of that data.

To get the access token, you would have to sign up to Map-box to retrieve the access key. What’s interesting is that MapBox Api’s have different scopes, which means it has different permissions on accessing the api. In other words, if we specify the scope, we are specify the accessibility.

Each Api has a version attached to it. Like how softwares have versions, Api has versions that can remain the same or can be incremented ‘independently from other APIS’. I’m assuming here it means if we were using multiple apis in our situation. An Api would only have to be incremented if we are deciding to remove propeties from a Json Object or change the Api Structure.

To render a map on a page, Mapbox uses something called tilesets, and there are two tyles. Raster tilesets and Vector tilesets.

Raster tilesets contain tiles of an image of map. This is what display the map on the page, or what we are looking at specifically.

Vector tile-sets are similar to tilesets, except they produce the data. Whether it be street name, city name or location, they are bits of data that match up. Given they are small file sizes, you can load thousands of them without worrying about the speed and have all of the street names printed out! In addition, they are customisable style-wise! Sweet.

You can obviously not only get tilesets, but data sets of what one would like to portray on the map. As Mapbox works with API’s, we can not only get the visual stuff but also print out the data Mapboxs uses. This could become in handy for geocdoing (coordinates) or getting data about the place to a extent of specificity such as street name.

Mapbox have different identifications which represents a map with a certain style and what data they show. As mentioned that maps used something called tile-sets, they can be retrieved by Tile-json or through HTML.

Sounds Great! How do I implement it in my code?

Very, very excellent and good question. Let’s start off with a simple tutorial of putting a pin from the api, because the code is let’s just say quite heavy. However, before I show you the crazy image of code…concept-wise we are doing the following.

Mapbox has default map styles, which we intend to grab from their website to put it on our website. Then, with the data we get from the GEO.json file we download, we then want to do a get request to that API dataset. Then, we would want to pin those locations on the map, and finally, we will do something funky at the end.

It sounds so simple in three lines. Step 1, let’s go…line by line-ish.

01. Setting Up the Map

Whoa, look at this crazy amount of cde.

We have our html file, that’s great.

We then have a viewport, which means that this sets the settings of the display of the content base on the window size. In this case, there is 1 value for the scaling because we don’t want the map to scale with the viewport (if not we would place on value to 0 or one value to 1). Im guessing this, given I’m used viewport CSS once.

In addition, Mapbox already has a feature where we can zoom into the map, so we don’t need a viewport adjustment to the window if not things get a bit crazy.

Then, we have the fonts api that gets a font, we then require both the mapbox-gl.js file (which is the file that will give us the map and data of the map).

We then require the css styling of the map, to deliver us the map as how we all recgonise it.

Lastly, we have our own css file because guess what, the styling of the markers and actual window needs to be somewhere that isn’t going to cluster our HTML page. Good so far?

Then, in our map div which we will style, we call our access token to allow us access to get the data from the api.

Lastly, the map is called with the following features.

• Container (where this data of the map should live. We made a div called map so that’s where this map from Mapbox will go)
• Style (Mapbox comes with stylesheets you can customise and default ones)
• Centre (The centre point of the map in base of coordinates, longitude and latitude)
• Zoom (How much you want to be able to zoom into a map. Similar to Google Maps, we can zoom in to the specifics as much as we want)

Now, magically, this page of code so far will give us this:

Omg cool slick map that can turn 3D omigash.

That’s step 1.

02. Loading our Data

Currently, the tutorial has asked us to hard-code the data of the api in, in which I have done so. However, I believe if we were dealing with a heavy API, we would require our Geodata.json file from somewhere or have a link containing all of our data in the api.

Either way, you need to get your data from an Api into this HTML file. Whether it is through jquery, some form of Get request, it just needs access to the data you from the Api, so you could make a callback from your Api that you got with the access key.

We’ve saved it to a variable so we could use this and affect it later.

Cool. Nothing has changed visually because we have not asked our files to do anything with the data yet.

03. Making the Markers

Oh finally, the fun stuff has come in. For this part, I have required an image to be the marker and styled the marker as that image in CSS file. However, let’s look at the code we have to the HTML file.

Remember that we saved our api data in a variable, we’re going to use that variable now to iterate over the data to print the map base on the coordinates.

So, here we are iterating over the for Geojson variable, to implement the same method to every location we have chosen.

We are calling the div block to save it into a variable, given we want the marker on the map. We are going to make the class name “marker” given that is what we are doing, but this is simply a html class that we will style.

From there, we are using the mapbox.gl, and placing this “marker” html class base on the coordinates, and adding to the map. The magical result is the following:

Oh my god! We have points on the page!

04. The Fancy Stuff

The fancy Stuff is how we are going to be implementing a pop up on the pointers that will allow us to see details of the pointer. This could be anything, but let’s say that this will just so the location on the page.

Remember the last two lines we were talking about. We know that the first line mentioned how it was going to place the markers base on the images, and then the second line was to add to map.

However, if we think about this logically,

What stuff do we want to add to the map before we add them?

In this case, for the fancy stuff, we want to add the pop up with the following details of title and description of location before we add it to the map right?

In other words, we are adding all the elements of the marker and pop up before we say “okay add them and let them pop up now!” Hence, after this step, we would have come to this outcome of the map.

Oh, look there’s a fancy pop up on the map now where our marker is!

From the little experience I have of Map-box, it already proves itself to be quite straight forward on how it works and what it offers. Whether you are using their own software to place a marker or code the marker yourself on your own website, the documentation is quite effective (although there are multitudes of it everywhere) to obtain and give it a try.

Plus, I believe that’s the only thing that they can do for their product. They can only advertise what it does and what it can do. The ways of how one will use it, customise it and extract it is an exploration set out for the developer.

Home Study:

After researching through javascript back-ends, of which were the best to use for our project, majority of us were keen to use Node.js given it was a popular combination to use React.Js as the front and Node as the back.

My instant concern was that through reading articles, node would have limitations such as memory for large scalable apps and thus, being unstable with Apis. However, as we were only going to use less than two apis max in the project, this settled my nerves to give node a shot.

Within that, we would use MongoDB to handle the database section of the project. We need database to not only store the User’s information but the API dataset we will get from MapBox. This is a program we will install via Node.

Perhaps, it my mind, we would also want to use Express.js which is the Sinatra of Javascript. In other words, our file where all our roots would be determined but these are thoughts for the next day onwards.

It sounds like we wanted to have a full on javascript front and back end for the project. This may not have necessarily been the case although we all knew we wanted to escape from Ruby due to the limitations it had compared to Javascript.

If anyone is stuck in this dilemma, theses were some of the useful reading resources are in the links below to give me a better scope:

13 Node.js Frameworks to Build Web APIs | Nordic APIs |_Node.js is one of the most commonly used technologies in the web space. According to the StackOverflow 2017 survey, 47…_nordicapis.com

Why to Use Node.js: Pros and Cons of Choosing Node.js for Back-end Development_Choosing backend technology is one of the most important decisions that every CEO and CTO have to make. It determines…_www.netguru.co

Node.js as Backend: Best Use Cases, Tools & Limitations - Snipcart_In 2009, a new technology made its humble beginnings in the vast universe of backend development. Node.js was the first…_snipcart.com

Ruby, NodeJS and Go: advantages and disadvantages for backend development_For single-page applications there is a pretty clear-cut distinction between frontend and backend. The presentation and…_www.leanpanda.com

Although it was intimidating being the only team unsure of the technologies, what I appreciated was that we did our research on what technologies for the front and back were suited for the project. Whether it was based on popularity or understanding what the technologies were used for (pros and cons), it helped us get a better scope and list of considerations for the project.

Although today felt not as productive, given we were reading a lot of documentation and not reaching for the keyboard, it’s a benefit for tomorrow’s venture. At least for me, it will help be aware of all the technologies we need and enable myself to map out the architecture of our program, and how all these technologies talk to each other.

As I sit here, tired after a long day, about to end my day with a Youtube clip about Node, I await till tomorrow’s standup/retro to have these decisions be made and begin the exciting setup.

Fun Fact of the Day:

Dear Juniors and Mids at Makers Academy,

When you watch the graduation, of if you are going to do or have watched one already, you might be in awe of how many new technologies groups tackle in their three month of coding experience. You might think to some extent they are crazy and greatly admire them for the stretch that they’ve done. I was once like you, thinking they were nuts but as my team and I are about to tackle three new things, it’s honestly normal.

Makers trains you to have a growth mindset and be unafraid of exploration, even in the times that it count. It’s bold, it’s risky but looking at the graudations, everything works out.

And sooner than you know it, you will be in the position that I am in, scared but excited but hopefully be less afraid than I was

~ Dania