CCSFGIS Web Map Quick Start
Session 4
Agenda! bit.ly/ccsf-fall16-s4
SOME HOUSEKEEPING
Optional study hall will be this Thursday at 5:30pm (not 6pm, sorry) at Mapbox - 149 9th street.
How are your projects going? What challenges are you stuck on? Would you like to share anything with the class?
Before jumping in, let's review
What did we talk about last time?
Let's take it to the next level [guitar solo]
How the Internet works: extreme CliffsNotes edition.
THE INTERNET
The Internet is a network of networks
The Internet is a whole bunch of computers that are talk to one another because they speak the same language and are connected.
This is the essential Magic that makes the Internet possible.
When we think, "the Internet", we're usually thinking about the World Wide Web, but there are also crazy telephony, email, peer-to-peer sharing, etc things going on.
The WWW consists of all the connected documents we work with every day.
When you want to visit a web page, how do you get to it?
Every web page has a unique address called a URL or universal resource locator.
Put another way...
You tell your computer (the client) to ask another computer (the server) to please give you a web page.
This client ⟺ server relationship is core to everything web maps need to do
While we're ofting asking a server to give us things, what else can we ask a server to do?
BOOM! Perfect transition.
Let's talk about requests and responses
I'm summarizing the great info created by my super smart colleauge Lyzi on this page. Check it out for a more detailed explanation!
We talked about clients and servers earlier. The server's job is to receive requests from other computers, interpret those requests, and send back a response.
Sometimes, that response in includes a resource (like a Leaflet map tile!).
How requests are made
There are a bunch of ways to make a request, but we're just going to talk about one: via a web browser using HTTP.
We know what a web browser is, but how about HTTP?
HTTP stands for hypertext transfer protocol and it defines a set of common types of requests and responses that can be interpreted by all devices.
Remember earlier when we said that part of the magic of the Internet is that all devices can speak the same language?
This is that!
Let's talk about request structure
YOU GOT THIS
Just like a web page, an HTTP request has a head and a body
Also like a web page, the head of an HTTP request contains meta information about the request, while the body contains the resources intended to accompany a request.
Unlike a web page, HTTP requests don't always include a body
One super important component of the request's head is the request type
There are many request types, but the most common ones you'll see are:
GET
The client requests a resource from the server, but is not sending any resources along with the request.
Ex: typing www.facebook.com into your browser and hitting enter.
POST
The client sends a request along with a resource to be posted to the server.
Ex: making a new Facebook status update. The content of your status update is sent to the server in the body of the request.
DELETE
The client sends a request to delete a resource to the server.
Ex: deleting you Facebook status update
PUT
The client sends a request to post something to the server. If there is already something at the specified location, it is modified.
Ex: editing an existing Facebook status.
RESOURCES
The resource identifies where on the server you are making your request to
https://hostname:port/path-or-endpoint/resource?query=parameter
https://hostname:port/path-or-endpoint/resource?query=parameter
This is the main location of the server. Most of the time, the port is not explicitly defined and instead is handled by the server.
https://hostname:port/path-or-endpoint/resource?query=parameter
path-or-endpoint: once on the server, this is where to look for the resource. In the case of web pages, this is considered to be a path. When engaging with an API, it is often called an endpoint
https://hostname:port/path-or-endpoint/resource?query=parameter
resource: the actual resource being requested. This can be a webpage (like index.html), an image (like puppies.jpg), or some other resource.
https://hostname:port/path-or-endpoint/resource?query=parameter
query=parameter: query parameters allow you to send additional information along with the request. (remember the twitter example?
RESPONSES
Once the server has received your request, it has to interpret that request and send back a response.
Responses include status codes and sometimes resources
Have you ever gotten a 404 page? This is the HTTP status code for not found.
Some common HTTP status codes:
Read more at HTTP status dogs
BREAK
So why did we learn all that internet-y stuff?
Because you're going to make a web page and put it on the internet!
Finding a place to put your stuff can be tough. Luckily, GitHub provides an awesome service called GitHub pages.
Let's take a look...
Github
Borrowed from Alan and Camille of Maptime fame.
github wat?
Github is git & hub
Github is version control & a website
Github is collaboration software & free public code hosting
* wikis
* issue tracking
* gists
* website hosting
Why is git + github important?
open source lives on github
git flooooowwwwww
"A successful git branching model"
gah
resources:
* simple git guide
* cheatsheet
* try.github.io
* nodeschool's git-it
* Git Flow
* Hackbright Git exercise
nodeschool's git-it
GitHub Pages!
GitHub pages is a convenient way to make a website to share your web maps.
It runs Jekyll out of the box.
we won't get into that today, but...
Jekyll is a site generator that plays nice with GitHub.
Mapbox runs on Jekyll. So does Maptime!
Maptime has a really cool starter template you can check out on GitHub.
ANYWAY
GitHub pages totally works without Jekyll. Let's use it to put our maps out there!
Head to github.com and sign up for a free account.
Create a new repo.
Name it:
your-username.github.io
Create a new file, name it index.html, and add the code from last time's Leaflet map.
Head to your-username.github.io and check out your map! (It might take a sec to show up...)
Aww yeah!
Another way you can embed a map in a page is with an iFrame.
An iFrame is a website within a website.
A lot of web mapping platforms offer pre-made iFrame code for you. Let's try embedding a CartoDB map with an iFrame
Grab the code from this link, swap in your own iFrame, and try putting it on the Internet.
hint #1: try adapting the process we used to put our Leaflet map online.
hint #2: CartoDB provides handy iFrame code for you.
You are a champion!
Introduction to Mapbox Studio and Mapbox GL.
While I'm talking, log in to your Mapbox account
Today we're going to talk about GL maps and Mapbox Studio.
The following material borrows heavily (again) from a great Maptime presentation created by my colleague and co-Mapbox-support-teamster, Lyzi Diamond.
Mapbox Studio is a modern design platform for managing your spatial data and creating custom map styles.
Mapbox Studio is now your command center for interacting with Mapbox.
It also contains a sexy new data editor with a visual interface that leverages GL technology to help you build beautiful, custom maps with custom data.




It's really exciting.
But to fully appreciate this new tool, we first have to go back in time.
GL agenda:
Ready?! Okay!

Web maps history review
Before modern interactive maps, what were the basic steps to make a digital map?
With static and print maps, there was one extent and one scale to style for.
This is not to say that print cartography is easy...
... but rather to say that it is straightforward.
But on an interactive map, there are multiple scales and extents to design for.


Remember tiles?
Tiling introduced standardization to interactive maps, which facilitated a thriving ecosystem of mapping tools.
The standard includes:
This created an amazing, collaborative, open source mapping world that facilitated lots of interesting growth...

...including a little company called Mapbox and a little tool called TileMill.



TileMill was the first design tool from Mapbox. It was for creating interactive maps.
Thinking back, what were the three main steps to designing a print map?
The TileMill process:
Radical! But the magic of TileMill was all happening beneath the surface.
At its core, TileMill was a visual interface for interacting with a much more powerful tool: Mapnik.

Mapnik is the monster that eats data and stylesheets and poops out map tiles with the exact right extents, at the exact right zoom levels, stored in the exact right structure.

Mapnik is magical. All hail Mapnik.

In TileMill, users defined styles with a styling language called CartoCSS. In CartoCSS, you define how each data layer should be styled at each zoom level.

Would it blow your mind if I told you that CartoCSS was really just a pre-processor for Mapnik's XML styling specification?
So TileMill took your data and your CartoCSS style and fed them to Mapnik to create map tiles.
(Interactivity? UTFGrids.)
You could then add your map tiles to a map using Mapbox.js, OpenLayers, Leaflet, or one of many other web mapping libraries that facilitate interactions. The tiles were stored online and loaded in the browser on request.
So that was TileMill. And it worked really well for a long time.
But it had some limitations.
1. Image quality
2. Size
3. Malleability and updates
What to do?!
In an ideal world, you could create map tiles on the fly based on desired image quality and styling rules instead of storing a bunch of similar but different tilesets.
Enter vector tiles and the Mapbox vector tile specification.
Vector tiles are similar to map tiles (the world, in a grid, created with Mapnik), but they contain vector data instead of images.
Vector tiles use a super compact file type called protocol buffers, or pbfs, to keep the data both small and fully intact.
Vector tiles added a new level of efficiency to the map tile creation process.
Vector tiles separate data storage from map rendering.
With the raster tile model, rendering was the core of the operation, as images were stored. With vector tiles, rendering only needs to happen at the very end of the process.


Mapbox Studio Classic was released as a new desktop design tool to replace TileMill, focusing on this separated data/style paradigm.

It has two parts: source mode and style mode.
Source mode is for converting your vector data (GeoJSON, shapefiles, etc.) into vector tiles.

Style mode is for creating stylesheets based on those sources.
This makes the process for using Mapbox Studio Classic a little bit different than using TileMill:
It's okay. YOU GOT THIS.
When using TileMill, your output was a set of map tiles. What is the output from Mapbox Studio Classic?
A source and a style. No raster tiles are created at all...
... until you ask for them.
Mapbox stores your style and its associated vector tile dataset. When a web map is created using your style's ID and the browser requests tiles, the style and source are passed to Mapnik to render into map tiles ON THE FLY.
You can even use some Mapbox-provided vector tile datasets!
So this is the solution to the problems we outlined before, right?
Images generated on the fly mean no storage or malleability issues.
But... there are still limitations to this pattern.
Mapbox Studio Classic signaled a shift in the way sources and styles were managed on the server side...
... but the client-side behavior did not change: image tiles served to the browser in a grid, loaded when necessary at specific zoom levels.
The outputs of Mapbox Studio Classic are essentially basemaps with no truly interactive data.
To add interactive data, you need to add an overlay using your web mapping library and GeoJSON data, and there are limitations...
Unless you enjoy crashing browsers, of course!
Another bummer is the jumpyness when going bewteen zoom levels. And tile loading is fast, but not that fast.
What to do?!
We separated styles from sources when implementing vector tiles, so now the two are independent of each other.
Who says we need to keep using Mapnik to render image tiles? Why don't we just use a different renderer that better meets our mappy needs?
So we did. And we called it Mapbox GL.
[This is where we move on to the second part of our agenda.]
How GL works.
Mapbox GL is a way to render maps with vectors in the browser rather than as images on the server.
The part where I show off pretty GL maps
Up until now, all rendering has been happening server-side with Mapnik. Vector tiles are combined with CartoCSS styles, fed to Mapnik, and raster tiles are created and served to the browser.
With Mapbox GL, the rendering happens in your browser with the help of your device's graphics processing unit.
This makes map loading hella crazy stupid fast. It also means you can do cool stuff like rotating and tilting the map, smooth/infinite zooming, and more!
So in a practical sense, how does this work?
Because maps are being rendered in the browser (or on a device), we have to give some guidance on what to draw and how to draw it.
Remember how TileMill had styles written in CartoCSS? We now use something called Style JSON.
We send the browser a stylesheet written as JSON in the Mapbox GL Style Specification.
The stylesheet contains all the information needed to draw your map, including references to data, fonts, images, and, most importantly, styling rules.
So what does Mapbox Studio do? It is a visual interface for creating GL stylesheets.
Almost everything you do in Mapbox Studio relates directly to something in the Mapbox GL Style Specification -- especially creating and editing layers.
There were too many GIFs in this presentation, so I had to move the next part to another section :(
LINK to part 2
Whew! We just covered a lot of ground. Let's do a quick recap and wrap up for the day.
What did we learn today?
We learned about how the Internet works!
We learned about GitHub pages and created our own websites!
We learned about GL and how it works!
We learned how to use the Mapbox Studio interface and made our own map styles!
And we got our first look at Mapbox GL JS.
HOLY CARPS, Y'ALL! That's awesome!
You totally kicked butt today. Pat yourself on the back.
Keep playing! Keep making stuff! It just gets more fun!
Thanks a ton for being a great class!
Feel free to reach out via email or Twitter at any time if you have questions or just want to geek out about maps.
Don't forget to take today's exit survey.