 So I'm actually talking about a project we're working on at Esri. I'm actually started by Chris Helm who couldn't be here. He's busy enjoying Costa Rica. But it's a project called Coop, which is a pretty interesting project. So what it is, it's essentially taking any web API out there and converting it into GeoJSON and feature services. Nice way it scrolls off the page there. The kind of thing that drove this here is we have a lot of APIs out there, 311 APIs, things like that, that have their own unique flavor every single time. We want to make sure and pull this in and do filtering and analysis and visualization on those. So think of it as an ETL for APIs to fill more acronyms in there. So what it works is there's a, in the Coop server in the middle here, it's all node JavaScript. You write different providers that type into your REST APIs. It then ejects these out as feature servers for GeoJSON. And I'll show you some other examples of things it's dumping out to as well. And it can optionally have a cache internally. So it's all in GitHub on Esri slash Coop. You can go play with it. So the repo is there. You can go grab it. There's a Coop main project. There's a whole bunch of other, there's the Coop server and there's a whole bunch of other providers. I've shown here a couple that I'm working on. We have a Coop ArcGIS Online, Coop Elasticsearch, Sample Provider, Coop GIST, so on and so forth. So for example, you can go and take and say if there's a gist out there and happens to be, in this case, GeoJSON, I click map. It goes and gives me a quick map preview of it. Super basic, super simple. Mapbox provides the tiles to GitHub to do that. That's awesome. But we want to do more with it. So for example, here is City of Philadelphia has all their school facilities data here. Why don't I can go grab it a CSV GeoJSON KML? Cool, because they've uploaded and cached it there a year ago. So it's probably not up to date. But that's a whole other blog post. So using Coop, we can reflect that out and grab the GeoJSON convert into feature services. So I can go and use it my GIS and go do analysis, go do visualizations, things like that directly out of that GitHub repository. I don't have to move the data around. It points back to that. Theme it, query, filter, do drive time analysis around my GitHub hosted GeoJSON files. So there's other adapters and other APIs out there. And then also already builds in using open source tools, the ability to export via GeoJSON, KML, CSV shape file and more. It's R&D. We work for the R&D center. So we've already prototyped out dumping out UTF grids, vector tiles, PNG tiles, all from any of these arbitrary APIs. So if you had a bus tracking API, a 3.0.1.1 API, anything like that, you can go and even flicker, for example, and turn that into GeoJSON or PNG tiles or things like that on top of it. So you wouldn't want to play with one of the things we've been doing with is how do we actually make open-shoot map itself more accessible for people to do analysis and visualization with. So you can use this. There's an OSM output provider that you can go and grab to get, you know, if you ever want to play with your new GeoJSON libraries, I just need a lot of lines, for example. You can go and grab them by type. That's useful for technologists, but I want to go and grab them by state and get the count of them by state. I can go and get the number of cafes and start doing where clause queries against these via at least a query UI, and I can actually make it restful because it's just pretty easy to know to add more route endpoints there. You can even go and start diving into this more and more, even get distinct values here. So something we've built to kind of explore this is this little example here. So it's a little map I can go and say we'll click on, you know, Oregon and Multnomah County. Dive into there. Now I actually want to go get by, for example, amenity here. And I want to go and get, it's very important to always know where your local toilets are. So great. Cool. I have this little URL. This is querying against a OSM planet import. It's now dumping this out as a GeoJSON feature collection with all the different features there, by at least a defined scheme at this point. So I can go take this, go pull this into Curl it, do a tool into GeoJSON.io, for example, and I can go and map that out, right? So it's really things like OpenShift. Just one example really accessible for people to play with very quickly and very, very easily. So you can keep driving into it. So there's UI for it. That's really it. It's a pretty cool project. We're using it behind the scenes in a couple of projects like ArcGIS Open Data, but we also are seeing cities want to adapt it as a way to make their APIs already out there more accessible for developers like us to go and do cool things with it in whatever libraries you want to use. So, finish early. Thank you very much. Thank you. Yeah, okay. Thank you. I'm Jubal Harvester from Spatial Dev. So they pinged me this weekend and said, do we have some extra time? Can you talk? And I actually had nothing canned to talk about. So when I was working on my slides this morning at two in the morning, I was trying to figure out what we were going to talk about. So I'm going to preface this by saying that I'm not a developer. My team does not let me write code anymore. And I actually didn't implement any of the things that I'm going to show today. So my role in the organization now is sitting between demanding clients and brilliant but very opinionated developers. So let me just launch into it. So one of the things I hear all the time is this too slow. We all hear this, right? This is everybody's favorite. We say slow relative to what? What you want? What your data says? How fast can you go? What does that mean exactly? So in this particular example, there was a client that had 70,000 points and they wanted to use leaflet clusters and we wanted to classify those points. And what we were doing was taking about 10 seconds and that was just not good enough. So we rewrote the leaflet cluster marker library to get some SVGs out and inject some S3 goodness into them so we could dynamically cluster. I think we can get up about 90,000 points in two seconds down to the client. And here's the required screenshot. And you can see some magical points getting clustered and they move around. It's very fast. So that's one example. And these examples that I'm showing each of them is about a 30-minute talk, which I don't have time for, obviously. But they're all driven by the clients where the application is deployed. And in our work, it's mostly in the developing world where bandwidth is an issue, computers are an issue, browser versions are major issues. So the next one I have is takes too much bandwidth. And I always say, what does that mean? They say, well, you were in the hotel in Tanzania and then we took it out to the country and the application didn't work anymore. And I said, well, it's a website. Of course, it didn't work anymore. And I said, no, we want the same experience when it's not connected as when it is connected. Okay. So what are you going to do? Okay. So we're doing more on and offline. So right now we have a virtualized environment for some of our apps but we're moving to Node WebKit. So when the customer takes that data or unplug the internet, they get the same experience. And what this said, at least in our work is that they want the same experience regardless of the device and regardless of the internet connectivity. So it's mobile form factors, desktop web, and then on and offline. And here's an example we actually did deliver a virtualized environment with everything packed into one deliverable. Of course, the virtual environment is too big for any sort of realistic distribution but we're certainly working on that. It's too expensive. We all do that. It doesn't scale. And then I said, what does that mean? It doesn't scale. Like you want more servers. You want it faster. You want more data. And what I typically hear is if we have, you know, we want to start 10 million points and we're not going to do that. We have 10,000 layers. No, we're not going to do that either. So we want to have some balance of scale and cost so that we can actually implement something that's reasonable for the client. In this particular case, with scalability for them meant we have to buy too many servers in order to serve the number of data layers that they wanted to serve across the globe that were very complex. So we started working on NodeJS, PostJS, you know, wrappers that can dynamically generate tiles and dynamically generate vector tiles based on REST queries. And then we're working on some leaflet canvas stuff that we can have MATNIC, PBFs come right down and consume them in leaflet. There's a URL for that if you want to go check it out on Git. All of our stuff is open. I think we've exposed about a third of our repos and we're working on the rest of them, getting them cleaned up and sort of ready for prime time, if you will. And that's so chief asset scale. So we sort of developed this server and we started working on it because we needed to and it sort of got a little bit out of control and it almost looks like it's turning into a product, although we're not a product shop, so we're just sort of working on it for our own internal projects and it seems to be working out just great. So we have now about 10 developers, 12 developers depending on the day. These are our sort of tools and frameworks. Don't ask me any detailed technical questions about these things because I sort of understand the high level, but not how they actually get implemented by our brilliant team. So I'll just leave it there. And that's it. I'm Brett Camper. I work at a place called MAPSEN. We kind of lab in New York City, work on a bunch of open source projects. One of those that I've been working on is another WebGL mapping library called Tangram. We just put up a blog post about it yesterday actually. So you can check that out on our site. I will go through the demo if it loads. Okay, so let's see. Before I go through the actual demo, I'll talk a little bit about some components it uses. So it is implemented as a leaflet plug-in, actually using some of the newer leaflet features that Vlad talked about earlier, some of the pre-1.0 stuff, the new grid layer, which is really nice, much easier to work with. It consumes vector tiles, as you would expect, because it's rendering vectors. For that, as Jason mentioned, I also like to use kind of this simplest, like lowest common denominator, easiest to understand format. So in this case, I'm consuming mostly GeoJSON. Again, it's not the fastest or most efficient, but it is the easiest to understand and debug. And so MAPSEN has this pretty simple vector tile service that you could check out that is free and runs off of an OSM planet import, and will give you nice GeoJSON tiles. It also will serve the binary format, the MAPNIC-based binary format, as well, if you want to use that. This library also uses the tessellation library that LibTest that Brendan over there wrote. So it stands on the shoulders with a lot of other things. So anyway, mainly what I want to talk about is just kind of what you can do with this stuff that you can't do with traditional raster tiles. I think Lauren gave a great overview of the core components and why it's a huge pain to draw a line or pretty much anything in WebGL. So there is certainly a large hump to get over, but once you get over that, you can do some pretty cool stuff. So in this case, we're drawing 3D geometry by extruding OSM buildings into polygons. You can see we can do very accurate hit detection here with pixel-level feature detection, which lets us do some nice real-time stuff. Is that why it's coloring water? This is my cheesy water effect to show off that you can do real-time animated shaders and things like that. You can do things like... Without getting into how the whole OpenGL pipeline works, you can use these things called the vertex shader and the fragment shader to kind of alter your geometry on the fly as you're drawing it, which lets you do things like turn perspective off. There we go. Or do you look at kind of isometric-style projection? You can play around with lighting. You can pretty easily turn different layers on and off, so you can turn off the roads, et cetera. Whoa, sorry. I took a screenshot. Didn't mean to do that. It's got a screenshot feature, too. The real fun is kind of doing these different kinds of effects. This is always the one that kind of is most people... It tends to get the most response. This is just to kind of show off that you can alter the geometry client side in ways that would just be not even possible on any kind of pre-rendered map. So another one that I like is this kind of... Oh, wow, interesting. This is not updating, so I would normally expect on this screen size. So this is an example of 3D geometry in the middle of the screen that fades to 2D towards the edges, and that starts to give you an idea of the type of data-vis stuff you can do. So you also have total real-time control over how much of that effect you're applying. And then you can do similar things with, say, procedural textures. So here's like a 3D dot pattern applied to this geometry. So these are not like raster textures. These are actually just procedurally generated on the fly. Similarly, you know, you can do... change all this stuff. And then, you know, also things like... like if you're familiar with the Stamen toner style, you know, the ability to do kind of like... do those kinds of effects, but do them on the fly, tweak them on the fly, not have to pre-render the entire world, et cetera. So the real challenge of this... it's actually, once you learn how to do this stuff, it's not that hard to just make a bunch of crazy effects like this. The real challenge is to try and make it, like, usable for other people and more consumable. So a lot of what we're working on now is trying to create like a style shape language around this that is more tightly bound to GLSL, which is the open GL shading language, which is a pretty high bar to learn if you're not really familiar with open GL. It's kind of a C variant. Is that like a... am I down or do I have, like, five seconds? Okay. All right. All I will say is the elevator effect is one line of GLSL code, and that's the goal of the library is to make it easy. Awesome. So, yeah. Brian, thanks for asking me to give a talk. I am going to talk about JavaScript for approximately zero seconds. This is one of my colleagues here. This is Derek Watkins. He's a real great colleague. He sits right next to me, and this is one of my favorite things I've looked over in Seoul one day since looking at this map of the U.S. Oh, yeah, sorry, from the New York Times. And I'm also a student at UW Madison. So I'm a cartographer there. We are about 35 or 40 strong. We have a San Francisco bureau and a couple of people in D.C. and one person in Paris. So we're a pretty big shop. We have a little crew of cartographers who work on data-driven stuff and big data visualization, and we have an entire maps department to do all of the maps that you would see normally. Another guy I work with here is Jeremy White. This one might be good for you guys because I think he was trying to decode some crazy binary something or other. So, yeah, you know, actually, we do... So to not... Maybe this will work. Completely ignore the JavaScript thing. One thing we do use JavaScript for that you wouldn't maybe expect is we do a lot of illustrator scripting, which is kind of JavaScript-y. And our deputy RTC wrote a little thing called A.I. to HTML, which will take multiple art boards in Illustrator and create... Yeah, on a website, it makes it so that you can resize the browser. You can load it up. It seamlessly loads for you. And I really wish that this worked like that. But so the text scales and moves on the screen. So this is actually, like, these... Like, down here, let's see here. Picture. So, like, these maps... This text is vector. But as you, like, move it around, this is not gonna work. Boy. I feel like I'm that guy now. All right, let's get to this. So, all right, this is what I kind of want to talk about. It's not at all JavaScript. We make maps really frequently that are ethnographic because the conflicts that we're mapping are... If they are along ethnographic lines, they certainly are relevant to the conflict. And many of you probably have done ethnographic mapping in the past. And if you have, you would almost certainly have a Chrome across the scanner. Mike Isadi at Columbia. Have any of you heard of him? No one. All right, well, now you have. He has done decades of research and just created an absolute, like, library of ethnographic maps. This one, this map here that we did for this caucuses project we did in advance of the Olympics was based on this map that he made, which you'll notice is a bit complicated. He works in Appleworks. Have you know this program from 1984? He actually still works in Appleworks. And his computers that he bought up when he realized that this was not going to be something that was going to be available on new machines are slowly dying. And he's kind of like afraid that his work is just going to forever disappear. So maps like... So here's another guy that we did. So this map that we made of Baghdad, the ethnography and ethnographic groups in Baghdad was based on a map like this. But his, since his file, like he's creating these old, like Appleworks file, it's converting them into a usable map format. Now it's a little bit problematic. So they can be converted to vectors. It's a little bit time consuming. But he has, I think he said he has over 300 maps that he's made over the years. They're all in this format. And we're trying to pitch to him that he should open up his collection of maps, make them freely available with, like, a Creative Commons license in exchange for having people, like, digitize his work. It wouldn't be hand digitizing as much as it would be dealing with this file format and getting them into, like, a geo, like, file format that'll last for a while. So if you're interested in that sort of thing, this is me. Send me an email or just come talk to me. Sorry about my browser window. And if you want a good story about leaking coffee cups, you can come talk to me about that. Yeah, so I didn't actually plan on doing this, but I decided it would be nice to share with you some of the little stuff I was doing on GitHub besides leaflet and mailbox stuff. So I have a hobby. I choose some, like, I like to choose some really specific small domain. For example, an obscure algorithm that's useful in some of our work, and, like, make the best library that's implemented, like, the smallest and the fastest and better than alternative. So I've been doing some small projects like this. For example, the first example is simplify.js. It's a library that takes an array of points and simplifies it, and it does so really, really fast, like, faster than any other libraries. And actually, I extracted it from leaflet code and make it a small, separate library. So you can see in the example, there's 74,000 points, and they get simplified in real time in less than one millisecond. And it's, yeah, it's quite fast. So, and you can see that it's actually less than, like, a bit more than 100 points of code. The next project I have is SunCalc. So I think I really wanted to do a map with, like, that shows some positions. So I got into some astronomy articles and calculations for a couple of weeks to figure this out. It's pretty complicated, but I built a library called SunCalc. It's also pretty small, like 240 lines of code, and it allows you to calculate some positions for a given latitude, longitude, and date, and times of the sun phases, like where and when the sun rises, the sunset, et cetera, and some position at any point of time on any place in order. So it's times like sunrise, sun golden hour, dusk, and stuff like this. And it also calculates moon position and moonlight phases. It's pretty simple, easy to use, and I actually have an example of using this library, but I'm pretty embarrassed to show it because I wrote it four years ago before Leifert was created and it's Google Map-based. No, yeah. We have somebody from Google here, so be positive. Yeah, so you can see it's Google Map where, ah, there's a bug. It doesn't show you sunset for some reason, but, like, yeah, it's... Okay, this is just an example. And, yeah, you can actually see the amount of sunlight in particular ways has, like, throughout the year. Okay, the next is Dead Simple Grid. So I was fed up with lots of frameworks, like trying to propose a new way to do responsive design, like there are tens and tens of different responsive design frameworks, and I decided to bid them all and build a responsive design framework in 250 bytes. So the framework is... Here's the code. This is the whole code of framework, and it actually works. So they have... This is an example, and it's, like, if I had a beer screen, it would do more stuff. So it's a really nice grid-like framework. The next one is AirBush. It's some of my more advanced work. It's a library that implements R3 structure for indexing spatial data in JavaScript. And it's quite a specific library, but it's been really useful in some applications like Mapbox GLGS. It really depends on it when it does its labeling and interactive features, because it needs to... I'll show you an example. So we have lots and lots of rectangles over the 2D space, and you want to search them really, really fast. So you want to answer where it's like... In this box, give me all the items really fast. So it builds a tree structure, and there are some really heavy optimizations, and I read through lots of algorithms and papers on R trees, and it's really, really fast. Like, 100,000 items get inserted in 100 milliseconds, and then when you search, it's actually like almost no time. And there are also both construction algorithms that are even faster. It's used in Mapbox GLGS. It's used in OpenWare R3, so I'm kind of contributed to OpenWare R3. It's used in ID, OpenStreetBab Editor, and in some other nice applications. So there's also a small library called SimpleHeat. It's a really, really simple heat map implementation. I just... I didn't find a really, really simple implementation simple of all heat maps because they all were trying to do too much, but I decided to make like a super simple... the most simple library that could do heat maps, and it's 140 lines of code. And there's a leaflet plugin, leaflet heat, that uses this. Here's this one. Okay. This is the leaflet heat. Okay, so the next one is SATAL triangulation that Warren mentioned. It's the fastest triangulation library so far. It has... like, there's a compromise. It doesn't handle some really bad cases of really cramped data, like intersecting ages, or cleaner ages, but it's still the fastest by far. And the latest project I want to show you, it's actually my... the most seminal work that I did. And I don't know why I didn't get much exposure, but it's much more important than my leaflet work. It's called Bolshevius. And it's bookmarklet. It keeps a... let me see. Okay, it keeps a list of bullshit marketing terms. These are regular... it's not actually a geo-related, but it's still very useful. For example, you want to understand what some company website says. So here's a company I worked for. Earlier, Commians. Like a consulting firm. And let's run it through pollution. So you can actually see what the terms are. But you start to really understand what it's all about. Let me see a burr... Vlad, I'm a geospatial consultant. I'm deeply offended. Okay. Oh, this is my favorite part. I think this is where we applaud. So this is a fun lightning talk, because I also have, like, 5% battery left. So it's, like, both. It'll just end when either my computer runs out of battery or you buzz me. So I work for Esri, and I work on Esri Leaflet, which is just a plug-in to plug ArcGIS and Esri stuff into Leaflet. But one of the things I started getting asked, like, every single customer ever was like, well, can I use non-marketer tiles with it because we have to use state plane, whatever. And I'm an art major, so I was like, well, what the hell is a projection? So I pretty much just ignored them for a really long time until someone wrote this demo, and I met them at the Esri Developer Summit, and they were like, I was talking with someone else about it, and they asked that question, he was in the group, and he was like, oh, I solved that. And I was like, well, could you, you know, write a sample of it? So this is actually his demo showing, and it can prove that this is non-marketer, because that, right. But this is, but he's a developer at the state of Utah, Scott Davis. And it's actually kind of deceptively easy looking until you realize that, so this is, you just put in the EPSD code, and this is the props for JS definition for that code. This is a magic number. And then you have the list of all the tile resolutions. And so these are the resolutions that map to the zoom levels. And then you actually just pass that object to the CRS, and then you can just ignore the fact that this says Esri because this basically is like 10 lines on top of tile layer that just builds the URL out. But that gets you like tiles, and when I said that I had a demo of this, I got really terrified because I never actually put any, like, GeoJSON data on top of it. So I did that really quick. This is actually just, it queries a bunch of data from ArcGIS and converts it to GeoJSON on the client. You can see the zip code data that actually like lines up at the edges of the state, so it does GeoJSON data and dumps that on the map just fine. So we're reprojecting geographic data on the client? Right, so it queries the geographic data, and it'll reproject it on the fly for you on the client side. So this, the one, the one like kind of gotcha on this is actually finding, so if you know, like this is the same EPSG code that was over here. There we go. So you can just plug that into spatialreference.org, and this is how you get the Proj for JS definition. It's just that. Okay, I'll look at it later. These are by GIS. Right. I guess. I don't know. EPSG.io. So, and if you go to like the ArcGIS server, you can actually, the list of resolutions, we'll get this in JSON. JSON's easier to read than that. So this is actually like all the resolutions for all the tiles get baked out as a part of the service when you bake out the tiles. So it's pretty much just like for ArcGIS stuff, if you like come across these tiles somewhere, you can actually just like copy paste everything over. And I was sitting there like getting this ready, and I just realized that this transformation value that's in here, because I've been trying for months to figure out like where this, what this value is. Because it just seemed like this magic number, and if you put any other numbers in there, it won't work. But it's actually, if anyone knows what that is, exactly in explicit terms, you should tell me because I really want to know. Somewhere in here, oh come on, origin, tile info, extents, info, oh come on. I just found it, it's actually, the numbers are the exact same as the origin. So if I scroll all the way down here, it actually says origin, and the absolute values of those numbers are the same. So I don't know if that's actually just an ArcGIS server thing where the origin, and then you just turn that into some other magic numbers, and it just magically works. That's kind of what projections feel like to me. Like someone just said like Albers, and it goes. But anyway, that is, it does work, and if you know the projections and the scales and the transformation and everything else, it does actually work, and you can put it together. The guys who did Proj for Leaflet did a great job, and Calvin on Proj for Jazz, so I think I'm down to like two or three percent batteries, so it's probably a good time to stop. Thank you Calvin.