Hey, everybody. So my name's Steven Lead, and I'm from Full Extent. We are a small consultancy in Sydney, and we specialize in web mapping. So I'm going to tell you about a project that I did for IAG Insurance. So I did this project for IAG Insurance. You might know them as the owner of NRMA, CGU. They've got policies all over the country, housing,

commercial, boat, caravan. So as you'd expect, they need to make a lot of maps. So specifically, I was working with the location engineering team, and these guys are the experts at doing the back end stuff you need to do GIS. There's not an address in Australia that they couldn't geocode. They know everything about databases and GeoServer

and all the back end stuff. But at the time, what they were missing was front end JavaScript, and that's where I came in to help out. Now, one of the problems was they had a lot of these maps, the legacy maps, but they were based on older technologies, Flex, Silverlight, and they were getting to the end of their life. They needed to be replaced. So they looked at using the web app builder,

and that's a great product for getting up and running nice and quickly. It doesn't require any coding, and you get up and running and get your map without any of that coding required. The problem is you reach a point where it gets quite difficult to customize any further without doing coding, and the coding becomes quite difficult. What they also found is that they're having to convert their workflows to match the application rather than

the application matching their workflows. So that's the state we were in when we started. So what we wanted to do was revamp the web mapping that they were using in that team, and the requirements were fairly simple. They wanted the maps to be fast to load. Some of those older maps were quite slow to load. They wanted the maps to load quickly and work quickly.

They had to work on desktop, tablet, mobile, any kind of size of device. They're using a variety of ArcGIS Server, ArcGIS Online, GeoServer, so all of those needed to be supported. They wanted the applications to work out of the box just with a bit of configuration, but also to be extensible when they needed to make changes.

And finally, the team needed to be able to create and deploy these applications really quickly. In the insurance world, sometimes the maps are created and they're used for years, but sometimes they're put together as a result of an emergency. For example, Cyclone Debbie, they had a couple of days to put together huge maps and send them out to the whole company. So it needs to be nice and quick to use.

So the very first thing I did was to look at the Bootstrap framework, which is released by Twitter. Bootstrap is excellent for building a web application which is responsive. So here we're looking at a large desktop. If we were to shrink the screen, the page elements move around. If we go down to a phone size, things move around again, but it all still works. So it's an excellent responsive framework to use.

That was one thing. The second thing we wanted to use was Leaflet, a lightweight, fast, easy-to-use web mapping application. So putting those two into Google, I quickly found there's an application called Bootleaf, which has been written by a guy called Brian McBride. I think he's in the States or Canada. And he wrote this application a couple of years ago,

and it gave us a really good benchmark to get started. Here's what the application looks like. Now across the top, we've got our menu bar with a bunch of options. On the left, we've got a panel which has some options in there. We've got the map itself. We've got the table of contents. So that was maybe 80% of what we needed in terms of the framework for the look and feel ready to go out of the box.

There were some limitations, though. If we jump into developer tools mode and have a look, you can see that the entire application sits inside that app.js file. So by that, I mean, what is the extent that the map opens at? What layers are in the map? What fields are in those layers? What happens when I hover over a button? Everything is just kind of smudged into that one file.

So it's not really easy for us to take that and make many different maps very quickly from that. So the very first thing that we did was to take the configuration and the application and break them apart, break them into two separate things. So an example of the configuration is we can say, what is the opening extent? What is the name of the map?

And then further down in the config file, layer definitions. By doing that, it meant we could build that application once and then deploy it many, many times nice and quickly. Here are a couple of examples of where we did that. Here is a map showing all the different brands that IG owns times all the different products, home, commercial, boat, caravan, et cetera.

So that's one particular map. Another map based on the same framework is looking at embargoes. So when there's something like a cyclone or a bushfire in progress, you can't immediately take out an insurance policy and be covered. Those are embargoes. So this is a different map, but using the same framework, just a different config file. Here is a completely different one

where the auditors are going out and visiting the motor repair shops. So again, it's exactly the same framework in the background. The only difference is the config file. Let's look now at some of the advanced functionality that we built into that. So I'm going to jump to a live demo now. So what I'll do is I'll open up the demo page.

And you can see straight away it opens up nice and quickly. It takes about a second or so for it to open up. Now, on the table of contents over here, we've got a whole bunch of different layer types. So we're looking at a ArcGIS server dynamic layer at the moment. I'll turn on a WMS layer, which is coming from GeoServer, WFS layer coming from another GeoServer.

The point is it doesn't really matter. The application doesn't care. The user doesn't even need to know. All of these layer types just work. In the table of contents, you can see we've got some layers that are grayed out. That's because we're currently zoomed beyond the scale extent. So if I zoom in a couple of times, you can see that the county layers now turns on,

because that's been set as turning on within a certain scale range. So that's something that we added to the framework. In the tools option here, we had to add a bunch of advanced functionality that the users required. So one of those is the Identify. When we turn on the Identify, you can see the map slides across, and we get a new panel on the left-hand side.

Now, when I click on the map, you can see it runs on Identify. And that's running across all the different layer types, dynamic layers, feature layers, WMS, WFS. It doesn't really care. The user, again, doesn't need to know the difference. So it just runs that Identify. We get the results on the left-hand side. And as we hover over each of the results, you can see that they're highlighted. If we click on one of them, it zooms us into it

and shows us the info window. So that was another bit of functionality that we added. Spatial bookmarks are also provided. So these can be configured by the user. So we can jump to a spatial bookmark, such as Pacific Northwest. Map's getting a bit confusing, so we'll turn the layers on and off. There's an option we added there

to turn all layers on and off very quickly. So IOG sometimes work with 50 or 60 layers. It gets very tedious to turn them on and off individually. So we added that function. Let's turn back on the Heritage Trees layer. And this layer is coming from ArcGIS Server as a point layer. And one of the options in a point layer that we added was to cluster. It's a simple yes or no toggle.

Because we've clustered them, you can see that they appear like this. When we click on the cluster, we quickly zoom into the cluster of points. Hovering over one of the points, you can see we have a tooltip. Or clicking on one of the points, we get a full info window that pops up. Another option we added was a query.

So it's all very well and good to be able to click on a feature on the map and see what it is. But what about the reverse? Tell me where these features are. So that's the query widget. So any layer that's been configured as queryable appears in the dropdown. We can choose different types of query. The thing starts with, this thing ends with. So let's put in, say, for example, the thing starts with A within this polygon.

And we'll draw a polygon on the map, so something like that. And let's run a query. And that's going to run that query against the feature layer. Again, the same functionality works for a feature layer, WMS, dynamic, whatever. It doesn't really matter. It all works seamlessly to the end user. Here are the results. And if we hover over each of the results,

you can see highlights on the map. We can sort, or we can filter. So if we put in, say, P, L, it's going to filter based on those. We can also download those results to CSV. And that was typically used by non-technical users who needed to use the map to find some data and then download it and process it in Excel or whatever.

Final thing to show is the history. So we can go to the previous extent. So that's a lightning overview of some of the advanced functionality that we added. We'll jump back into the presentation and look in more detail at how that worked. OK, so we needed, as I mentioned, a bunch of layer types.

They wanted to be able to see ArcGIS server, GeoServer, Tiled, and GeoJSON. And one of the things that's pretty cool about Esri is that instead of viewing Leaflet as a threat, they viewed it as an opportunity. And they've got a team which works on Leaflet for Esri. And they've got a library called Esri Leaflet, which you can download from GitHub and you can use.

And so that's what we used. Using that Esri Leaflet library, all we need to do to configure an Esri layer is to set its layer type as ArcGIS server feature layer and then give the URL to that layer. It's as simple as that. It just works. Further down, we configured a thing called fields or outfields. And that is where you define what fields you want to see in that layer

and what aliases, whether they're numeric, currency, et cetera. Same thing with ArcGIS server dynamic. We simply set the layer type as dynamic, give it a URL, and that's it. It just works. Jumping across the GeoServer WFS, again, we just give it the URL.

But you'll notice that the field definition is exactly the same. So it's the same type as we use for ArcGIS server. That became important at IOG because they were in the process of migrating some of their layers from ArcGIS server to GeoServer. And to make the change, all we had to do is change the type from ArcGIS server feature to WFS, change the URL, and that's it.

Everything else just continued to work because the field definitions, et cetera, everything else was exactly the same. Same with WMS or tiled layers. So those layer types are all supported out of the box. A bunch of base maps are also supported too. So we support base maps from Esri, Mapbox, Bing, or leaflet-tiled base maps.

All we need to do in our config file is just have an array of which base maps do we want. And those are the base maps that will appear in the dropdown within the application. Controls are also provided out of the box. So looking here at the map and then at the config file, we've got the geocoder. So we support it out of the box, the Google type geocoder.

I think ArcGIS server and OpenStreetMap as well were options. There's a table of contents, and we allow nested table of contents or grouped layers, as well as having that option to quickly turn layers to all layers on or all layers off. There's also the history, allowing us to get previous or next extent, and then

the spatial bookmarks. So those bookmarks can be set in the config file, or they can be set by the user and then stored as cookies. A bunch of tools and widgets were also added, and these were important for IAG for the more advanced functionality that they needed to do, almost as a desktop replacement. So this one here we're looking at is the query, which I demonstrated.

So we can put in the query parameters, get the query results back, hover over a feature in the list, and it highlights on the map. And then the way we configure that is simply using this query widget parameter inside the config file. And simply by setting that, it means that when we go to the query dropdown inside the application, that layer appears.

The fields can be set within the query widget itself, or they can be inherited from the layer. So we've got fine-grained control over what fields we want to see. One of the options there is hidden. So what we allowed there is a field can be not displayed in the table on the left, but when we download to Excel, the field

might be displayed there. So it allows us to have a lot of information without overwhelming the user interface on the application. The Identify was where we can click on the map, and then it runs the query against feature, tile, dynamic, WMS, WFS, all those layer types, and then gives us the result on the left-hand side.

As we hover over one of the features, it then highlights on the map. So the way to set that is simply to have an Identify object within our config file. And then when we have that, it simply works. When we click on the map, it identifies that layer. Another one of the things we found is that the users were doing a lot of work

and navigating to an area of interest, turning particular layers on or off. And then they wanted to share that with other colleagues. So we built in the ability to do that, navigate to an area, turn the correct layers on, and then say Share Map. And when they shared the map, what we then do is parametrize all of those options and put them in the URL. So the latitude, the longitude, the zoom,

what's the base map, what's the list of layers. And they can simply email that to someone else, and the map will then open up exactly the same as they last had it. So it makes it really easy for them to share. Now, I mentioned that we wanted the application to be extensible. So what we did is we built in two hooks where the users could add in custom code.

There's one function called before the map loads. As you'd expect, that's the first thing that runs when the application loads. And we can do things like check the port number that we're currently running on. If we're using a reverse proxy, we can say, let's redirect the application to port 8080 and then reload it before anything else happens. There's another function called afterMapLoads.

And that runs after the map is loaded, the table of contents is filled, we have a list of all the layers. And so we can put in custom JavaScript functionality at that point, too. So here are some examples of where we did that at IAG. I mentioned one of the brands is CGU, and they wanted to know, for a particular suburb, how many policies do we have,

how many motor repairers do we have, and who sold those policies, which of our agencies? So all they need to do is type in the name of a locality, in this case, Roselle, and then it just does all that for them. It zooms to the area, shows them how many policies they have, how many repairers, and who sold those policies. So that's one example. Another example is for, what is this one, Ed?

This is looking at motor repair shops. So putting in the address of a motor body repair shop, it then shows the user where is the nearest hire car. So we can order a taxi, the person can drop their car off to be repaired, and then we can order them a taxi to go and get a hire car from Hertz or Avis or whatever.

This is one of my favorites, I spent the most time on this one. This is where the auditors are going out in the field every day, and they've got iPads in their hand. They need to go and find the motor body repair shop to go and audit. So they start typing the name of the assessing pod that they're working within. So we use Type Ahead, so as they start typing, it pre-fills the options for them. Once they've chosen the pod,

they start typing the name of the repair shop, and that filters based on the pod, while also auto-filling for them. When they hit the search button, it zooms them into the area, and then when they click on the repair shop, the map disappears and we get now a table showing the summary of all the cars that are in that repair shop being repaired. They can filter those based on the number plate

or based on the model of the car, and they can say, great, you've got a Forester with this number plate, where is it? Let's go and do a quality assurance check on this particular car, make sure the work is up to scratch. Now, what's interesting about this is that application is what they were previously trying to do within the web app builder. They could do it in web app builder, but there were so many more steps required.

They had to adjust their workflow to match what the application did, compared to this thing here, which was perfectly attuned to what they were trying to do. It stepped them through at every point. So what are the conclusions to the bootleaf project? Really, I think the advantages are all of the requirements, that it's fast to use, it's a very lightweight application,

it works on desktop, tablet, mobile, completely seamlessly, supports all the different layer types they need, ArcGIS server feature, dynamic, tiled, WMS, WFS, GeoJSON. It works out of the box, but if they need to, they can spend a lot of time and heavily customize the application.

And lastly, it was fast for them to build and deploy. If you like the idea of bootleaf, it is freely available. So if you go to bootleaf.xyz, you can find a bit of information about the application. And if you want to download it, there's a link from there, where you can get it from the IAG Geo GitHub. So I just wanted to really thank and acknowledge IAG for supporting open source.

They built this, they paid for it, they could easily have kept it and not let anyone else use it, but they were really good at making it all open source. Hugh, who's sitting here, was very, very strong about making it open source, and he constantly bugged me, get it up on GitHub. So many thanks to IAG for that. So that's an overview. Thank you for your time.

Please let me know if there's any questions. Steven, that was great. I've used bootleaf myself and I really like it. How much of, my question is, how much of what you've written, I see there's an IAG GitHub, how much of what you've written has gone back into the main repo? So it's a good question. I wrote to Brian McBride, the original guy,

and he doesn't seem to care too much. His repo is kind of a standalone thing now, and I think this bootleaf has really taken off from there. As has been mentioned a few times in this conference, you need people to be in charge in keeping things ticking over, and I think Brian hasn't touched his original bootleaf for three or four years.

He's got lots of other projects on the go. He's written things which are different to bootleaf, but which do the same thing of getting you up and running quickly. I think, putting words into his mouth, he viewed this as a demo, and that's where it sits. So he doesn't seem to be too interested in ingesting this back into the original.

While Eduardo's walking across, I've had a few inquiries from other people who have started using this and have been using it for other projects, including spending a lot of time on custom code, so it is definitely being used by other people, which is great. That's what I say. You already indicated, towards the end, something like Web App Builder would do the same thing,

but more complicated. Before IAG went on and made this investment, did they do some kind of analysis of what other off-the-shelf tools would be available that they might use and what the pros and cons were? Things like geocortex come to mind,

and if so, what was the compelling reason to go down this road? It's kind of veering into political territory, which I'm probably not qualified to answer. Hugh and Ed are both here from IAG. It's probably better to talk to them about their reasoning. I'm also, we're an ESRI business partner,

so I have to be careful what I say. I'm not an ESRI partner. Yeah, we looked at geocortex, great tool for complicated workflows, workflows that were too complicated for us, as far as we were concerned, and the amount of work required to set them up was beyond what we needed. We also looked at CartoView, which is an open source framework

that manages the way you ingest the data and has widgets and that sort of thing, and we weren't sure where that was going as a platform. Yeah, we worked with Leaflet in its raw form and open layers and those sorts of things, and we didn't have the skills to create a framework

like Steve built from those raw ingredients.