Tomorrow I’m meeting with the Open Geospatial Consortium (OGC) to talk about the MBTiles specification, the format we use to store map tiles from TileMill and serve them from TileStream. It’s a very simple specification built upon the open-source database SQLite and enhanced with compression behind the scenes.

In the course of creating MapBox’s toolset of map tile servers, clients, styling tools and languages, and a whole lot more, we’ve written a lot of new code and designed short, compact new standards — of which MBTiles is just one. While using appropriate caution to avoid reinventing the wheel, we needed formats that would allow us quickly serve, share, and transfer thousands of map tiles.

Where these standards came from

With our map design studio TileMill, we needed a fast stylesheet language with error handling and other new features, so designed Carto, a riff off of Cascadenik. Carto is the language of TileMill styles, and in that purpose it works well. Similarly when we started to implement map sharing in TileStream, TileJSON was born. It’s a format for describing tiled maps that you can also use to auto-configure maps in Wax.

After struggling with file-based tilesets with Maps on a Stick, Justin created MBTiles, a format that stores tiles in SQLite, to support tilesets on the MapBox iPad app. MBTiles opened the door for better moving and managing of tilesets, supporting compression, and lots more.

And so in the course of our rather fast development cycles, we’ve come up with several standards. They’re in various states of standardization — MBTiles and TileJSON are well-described in specs while Carto’s standardization has just begun. What we’re doing is born of the web — using JSON in place of XML, and making performance a priority at every turn.

Where MBTiles, Carto, and TileJSON are headed

We want to work harder to make our work open and compatible. We also want to make it easier to combine maps and swap out parts of the stack as much as you want. We’ve made some progress here, with the the MBTiles spec having been adopted by quite a few projects so far, but there’s more to do.

The OGC is well known for popularizing WMS, WFS, and other well-established standards. The organization could take the role played by the w3 or WHATWG in web standards for mapping technology. Right now the ecosystem is undecided — split between independent specifications like GeoJSON,standards that are managed by the OGC, and de-facto conventions like OpenStreetMap’s slippy map tilenames.

So there’s a lot more to learn as far as standardization. We’re trying to push the boundaries of mapping in the web space and elsewhere, but we don’t want our tools to be the only choice, or anyone’s data to be locked-in.

For more background on the OGC and this meeting, check out its website and the meeting schedule.