Pros and cons of using Mapbox for your project

These days, there's so many mapping platforms out there that it can be a real hassle deciding what to use. Between Google Maps API, Leaflet, Mapbox, OpenStreetMaps, arcGIS and more, it's too much to figure out if you're not in the know.

So I'm here to help you out a bit -- at least with Mapbox. Mapbox has recently (as in, in the past year or so) rolled out a total revision to the way their mapping is done. Now data must flow in a very managed fashion through datasets to tiles and styles. It's a little confusing at first, and I'll give you a bird's-eye perspective on Mapbox's strengths and weaknesses in relation to a few typical projects.

Quick strengths

• Standardized data flow for large organized projects
• Very fast loading due to custom tile generation
• Relative ease of customization of map tiles
• Access to data
• Beautiful base maps that can be modified via click-editing
• Documentation is quite extensive

Quick weaknesses

• System is too complex for simple projects or maps
• Has a steep learning curve for developers used to other APIs
• Not a free service (see Mapbox Pricing)
• Strict data standardization can pose extra difficulties
• Documentation examples are sometimes inadequate for understanding

Sample Project One: the contact page map

A very common map that almost every web designer has run into is the standard contact page map. This shows a location, or possibly a few locations, with basic markers and perhaps some information in an infobox when clicked. This might also stand in for any map with a few simple locations marked out.

For this kind of map, using Mapbox would be too much work and complication. Your developer would need to make a Mapbox account, figure out how to work the datasets and map tiles, export the whole thing, and then finally go about setting up the actual Javascript on the webpage and the hover events and all of that.

It would be far more time efficient and would achieve virtually the same result to use Google Maps API or Leaflet. Your developer can copy over some of the example code from the documentation and can immediately begin adding markers and interactivity.

A possible exception to this may be for a very elegant website that requires particular styling. While Snazzy Maps can offer beautiful skinning for Google Maps API, and Leaflet has all kinds of available providers, it's hard to beat Mapbox's smooth scrolling and totally customizable layers.

• Mapbox too complicated for such simple data
• Can be good for a pretty, customized look and feel
• Simpler mapping APIs are available

Sample Project Two: the searchable map

This project is a level of difficulty higher than the contact page. You may want a few filters for live searching using text, checkboxes, or geographic radii. In any case, this map requires interactive features to be programmed in, but falls short of having users directly affect the maps themselves.

Carefully look at the kind of data you're going to be dealing with. Is the dataset extremely large or very complex? Are there multiple people handling the data? If you are working with an unusually large number of geographic objects (usually over ten thousand of any kind of polygon, point, etc), then be aware of the difficulty of achieving good performance in your map.

If your dataset is very large, Mapbox is your solution. Since Mapbox allows tile set rendering, it can handle datasets far above interactive maps that need to load files like geoJSONs directly. Mapbox GL JS also avoids repeatedly looping (a common issue in interactive maps) by using rendered layers and Mapbox GL JS functions to access specific features.

However, it is important to be aware that Mapbox's layer-only interactivity in Mapbox GL JS functions somewhat differently from other mapping APIs. If your developer is coming from other mapping APIs, learning the back-and-forth between the Mapbox data management and Mapbox GL JS can be a challenge!

If the data set is complex or if it has multiple people working on it, Mapbox is again useful, but the data standardization required can be a burden at tiems. Because Mapbox requires geographic data to follow strict rules, geoJSONs that will load using Google Maps API may need reformatting to work in Mapbox. Ensure that you establish standardized data modification procedures to reduce the pain of getting the data uploaded. If you manage to sort this out, however, data is ultimately handled more professionally through Mapbox's system than simply using a set of non-standardized geoJSONs.

• Great for loading large amounts data
• Good interactivity, but harder for developers coming from other mapping APIs. Documentation is good but requires some work to understand
• Ultimately dependent on your data process and needs

Sample Project Three: the interactive map

Finally, in the realm of the most complex kinds of maps, Mapbox is again worth considering. Because Mapbox GL JS is still fairly new to developers, there will inevitably be a steep learning curve at first in getting a handle on how data flows and can be manipulated across Mapbox's services.

This kind of map is one that would allow users to draw and post shapes, or save geographical features that affects the data shown on the map to other users, as well as incorporating various filters or overlay interfaces.

Again, if speed is a priority and you have large amounts of data to deal with, then Mapbox is almost certainly the right solution. Otherwise, the most important considerations come down to your data flow and how you want to manage data on your map.

Mapbox does have an API that you can use to manipulate your geographic datasets stored in Mapbox, which is very cool. However, this could upset the way that you currently manage data - perhaps you write directly to geoJSON files, or to a backend that spits out a CSV from a databases. Trying to integrate Mapbox's data flow and API into your process may be introducing unnecessary difficulties and would most likely require major backend changes.

If you are starting from scratch, and you don't have a plan to be storing your geographic data in your database, then the Datasets API actually provides some good opportunities. It will help to standardize your data, and you can manage IDs from your backend that can match up with dataset IDs, thereby allowing you to still have a fully interactive map.

Mapbox's integrated drawing tools are also great to drop into your map if you are allowing users to create features -- but similar tools exist for Google Maps API and Leaflet, so focus on your data and process needs above all for this kind of map.

• Mapbox again great for large amounts of data and staying organized
• May interfere with existing backend processes or geographic data generation
• Great for starting from scratch or for a major version revamp for the sake of storing data on Mapbox instead

Conclusion

In general, if you are looking for a simple map, Mapbox is too much. But the more complex your data management becomes and the more custom your solution needs to be, the more Mapbox is useful -- to a point. When you start developing your own backends for routing or geographic data, then involving Mapbox may be an unnecessary complication unless you build it in from the start. But be aware that tightly joining to any service means you are bound to it forever, and you will need continue to change with it!

It is certainly possible to generate your own mapping tiles and have a server to avoid using a service like Mapbox, but this goes beyond most casual mapping projects, even complex ones. Mapbox is a great way to access the power of custom base layers without becoming a tile expert.

Mapbox shines when it comes to mapping out clean and concise data, with a medium-to-high level of complexity. Plus, it looks freaking good. And at the end, who doesn't love a beautiful map?

PS: If you're trying to learn how to use Mapbox, check out my course on it.