Styled Layer Descriptor and Metro Extracts

In WhirlyGlobe-Maply 2.5 we added support for the Styled Layer Descriptor format.  We also added an example in the AutoTester and a tutorial.

Belfast, it seems.

Let's start with the data.

Metro Extracts

Mapzen provides regular extracts of OpenStreetMap data.  These are available in a variety of formats; useful if you just want a little OSM data.

Courtesy Mapzen

We chose Belfast in GeoJSON for our own example.  This is just data, though, so how do we make it visual?

Styled Layer Descriptor

The Styled Layer Descriptor format is an OGC standard used to style data into map images.  It's a bit crusty but, you know, standard.  We edit it in QGIS and export it for use in our toolkit.

WhirlyGlobe-Maply reads SLD and uses it to style Shapefiles, GeoJSON, or Mapbox Vector Tiles.  Any vector data, basically.  So let's put it all together.

Example & Tutorial

Rather than blather about it here, we put a nice example in the AutoTester app for iOS.  In Swift!

Ranen put together a tutorial that walks you through the process.  You can start with a Metro Extract and modify the SLD styles to your heart's content.

Up Next

We're picking up SLD users for the toolkit at a steady clip.  There's a lot more to SLD we could support, so let us know how you like it.

We'd also like to circle back and improve the Mapbox GL Style Sheet support and implement Mapzen's Tangram format.  But we need customers for those.  Speak up if you're interested.

Part 2: Future 3D Support in WhirlyGlobe-Maply

Last time we looked at WhirlyGlobe-Maply's existing 3D support.  It's considerable, but often hard to use.

FlyQ EFB and NATS Airspace Explorer

Now we'll talk about where we're heading.  It's all about the data sources.

Putting the 3D's in Data

Most of our users have fairly limited data processing capabilities.  Say you want to add elevation to an app.  We'd say:

• Gather all the elevation data you need.  USGS is a good source.
• Stitch it all into a single giant image in Spherical Mercator
• Chop that image up into tiles using this random tool we have on github
• Load the resulting sqlite file onto the device.

Easy enough, right?

Yeah, not so much.  That's why you see so few WG-Maply apps with elevation.

It's not just us, you know.  OpenStreetMap data is much easier to use when you move from Planet Files to Metro Extracts and Vector Tiles.

Structured 3D Data Sources

What developers really want is web services that they can plug into their apps.  Also pizza that lifts itself into your mouth.  Pizza robot.  Patent pending.

People want to point their app at an elevation, 3D building, or vector tile service and stuff just happens.  So let's look at some of those services and the formats they support.

Two New Styles of Elevation

Elevation tiles are an obvious thing.  We already support Cesium's elevation, but there are others out there now.

Mapzen came out with a straight up elevation tile service a few months ago.  There are a few minor technical hurdles, but it could be made to work well with the toolkit.

Mapzen Elevation Example

Mapbox came out with their own elevation tile service shortly thereafter.  It's a different approach, with similar problems in 3D but could also be made to work.

Courtesy Mapbox terrain-rgb post

So there you go.  We'd like to support Mapzen & Mapbox elevation data for 3D.

Buildings with Height

OpenStreetMap buildings have height (usually, mostly).  Mapbox has been showing this off lately in their APIs and Mapzen has been doing it for a while in Tangram.

Mapbox Data w/ Mapbox GL

We'd like to support height in vector tile data.  Not too difficult, obviously, but cool.

Now for the harder stuff.  Let's start with a detour into data formats.

GL Transmission Format (glTF)

The 3D file format we support right now, Wavefront OBJ, is old and weird.  We need to move to something new and... less weird.

glTF is backed by the Khronos  Group with lots of work from the Cesium folks.  It's a new, relatively simple optimized model transmission format.  Easy to read, fast to transmit, it solves a lot of problems for models like these.

And it enables some even crazier stuff.

3D Tiles

The Cesium folks have a 3D Tiles proposal out that looks great.  It's open, they've got example implementations, and they're trying to make it an OGC standard.

3D Tile data displayed with CesiumJS

That approach is well suited for mobile.  We can't display as much as a desktop can, but we can display a lot.

Naturally, we'd love to support this in WhirlyGlobe-Maply.

Point Clouds

We already support point cloud display for things like LIDAR.  It's restricted to a Sqlite based format read on the device.  Hey, it's what the customer needed at the time.

San Simeon LIDAR

We'd love to extend this to services like Greyhound, an open source streaming data server.  We'd also like to add support for the GeoPackage point cloud extension.

Summary

There's a ton of explicit 3D support in WhirlyGlobe-Maply for interaction, model construction, and motion.  We'll continue to push in these areas and others we haven't talked about, like 3D weather.  But that stuff is driven by high end client needs.

NATS Airspace Explorer

What we'd really like to do is support these newer services for our regular users.  If you have other services you'd like to see or, better yet, some budget, please let us know.

The Return of Mapbox Streets

A few weeks ago we withdrew support for Mapbox GL Style Sheets.  You can read about our reasoning if you like.

Courtesy Mapbox

That's all changed!  Mapbox is opening up their mobile license for WhirlyGlobe-Maply users and offering competitive mobile pricing.  We're responding by making it easier to use their data.

License and Pricing

WhirlyGlobe-Maply developers will be treated just like Mapbox GL devs for tracking and billing purposes.  You should email enterprise@mapbox.com to get an amended license that will look a bit like this.

If you want to use Mapbox vector tiles on more than 50,000 devices or you're doing device tracking, talk to them.  That's all standard stuff in their agreement.  If you want the mobile pricing, talk to the sales department.

Telemetry & Offline Use

We're being treated as an equal to Mapbox GL here and that is great, but there are responsibilities. Mapbox GL sends back telemetry to improve OpenStreetMap and do traffic stuff.  We'll have to do the same.

The standalone telemetry library isn't ready and we're proceeding without it.  When it's ready, we'll integrate it with WhirlyGlobe-Maply.  It'll be on only for Mapbox data sources.

As for offline Mapbox Streets use, you're subject to the same rules as Mapbox GL.  If you ask how to work around that, I'll be happy to refer you to Mapbox's terms of service.

Who's This For?

WhirlyGlobe-Maply occupies a niche in real time data display.  We're big in weather and aviation apps, with a smattering of other specialized users.  And developers who just want a globe, obviously.

I see the biggest potential in two kinds of base maps.  First up, Mapbox Satellite Streets.  This fills in a nice hole in apps that want an optional satellite mode with a sprinkling of transportation.

Also Mapbox

Next up, a stripped down variant of Mapbox Streets suitable for data overlay.  They have a few starting points here and we can tweak a bit.

Schedule & Shout Out

WhirlyGlobe-Maply 2.5 is getting close to release so we're not going to hold it up for this.  We'll put the Mapbox GL Style Sheet support back in 2.5.1 and do a bit of testing.

Lastly, a shout out to the folks at Mapbox.  We thought you'd gone all Mapquest on us, but you haven't!  Cool.

Deprecating Mapbox GL Style Sheet Support

For an update on the situation go read the latest.  Short version:  We're putting it all back.

If you follow the open source mapping world (and why would you?), there's been some interesting rumblings about Mapbox Intellectual Property of late.

I don't totally understand this, but Mapbox is unhappy with the stated goal of copying Mapbox Streets.

Is Mapbox Wrong?

Legally, I haven't a clue.  Ethically, they're probably quite right.  Their participation in the community earns them the benefit of the doubt.

So then, if we take them at their word, the word is "Thou shalt not copy Mapbox Streets".

It's an interesting word and it kicked off a bit of examination of my project.  Am I using any Mapbox IP and what are the consequences?

Mapbox Now and Mapbox Future

Is this really a big deal?  Mapbox is a good open source citizen and they're clearly trying to be very gentle.

But here's the thing, Mapbox took venture capital.  A sale is a likely outcome and those people aren't going to be as nice.  Think Oracle and Java.

So, what Mapbox IP do we use and what should I do about it?

Mapbox Vector Tiles

My users do use vector tiles.  Some Mapbox hosted, but always their own custom data.  Some users even have their own services.  Both cases are fine.

Vector tiles are undeniably open.  They've stated so any number of times and data formats are well understood in IP law.  I think we're good there.

Mapbox GL Style Sheets

This one's dodgier.  Though the format itself is open, there are restrictions on the style sheets we can use.  I can follow those restrictions, but will my users?  Ha!

Most open source users consider anything publicly available to be fair game.  The Mapbox Streets styles are the best out there.  There's no way they won't borrow from them.

So now we've got a style format that's tempting you to cheat.  That's strike one.

Data formats encode technical thinking.  If I implement OpenGL ES shaders to support Mapbox GL Styles then how different are those from Mapbox's own shaders?  It's a question that gives me pause.  That's strike two.

Goodbye to Mapbox GL Style Sheets

The style sheet format is cool, but it's too dangerous.  I'm ripping it out of the toolkit for version 2.5.  If you're using it, grab the code and make your own copy.

We do have Styled Layer Descriptor format support coming out soon.  Not as cool, but a nice safe OGC standard.

Mapzen Vector Tile Service

Let's take a look at Mapzen's vector tile service.  They've recently announced a developer program and done a lot of work behind the scenes.

Sea levels aren't rising!  Shut up!

Vector Tiles

Mapzen is processing the OpenStreetMap planet file into nicely addressable vector tiles.  They provide the recipes for doing this yourself, but my attitude is better their Amazon account than mine.

Of the formats they offer, WhirlyGlobe-Maply supports two:  GeoJSON and PBF (aka Mapbox Vector Tiles).  I prefer the latter.

PBF (or MVT) contains compressed vector data with general attribution.  To make something visual, you have to match the attributes to a style.  In the past I've used Mapnik XML for this, but this time I've gone with something different.

Mapbox GL Style Sheet

Mapbox has been busily developing (yet another) styling format for their vector tiles.  The new format is nicely tuned to display rather than offline rendering.

The main disadvantage with the new format is there's no way to generate the damn things; you just have to edit the JSON directly.  I imagine we're all hoping they'll update Mapbox Studio one of these days.

OSM loves footpaths

But I like the format and it's clearly where this part of the open source community is going.  So I added a parser to WhirlyGlobe-Maply.

Mapzen Data + Mapbox Style + WhirlyGlobe-Maply

We've got the vector data from Mapzen, a style sheet in the Mapbox format and a big real time rendering toolkit.  How hard is it to put it all together?

Not hard at all.  There's a standard tiling loader (not shown) that will read it on the fly (in multiple threads).  We just have to set up the MapzenSource which involves..

• Reading the MapzenGLStyle file.  It's in the local bundle.
• Setting up the cache directory, so we're not always hitting Mapzen.
• Specifying the base URL and API key for forming the Mapzen URL.
• Picking the layers we want.  All of them in this case, but we could be selective.
• Using PBF (MVT) for the source and Mapbox GL for the style.

Yup, it really is that simple.  I've been messing around with vector tiles for years now.  I've got it down.

This code is in the WhirlyGlobeComponentTester app in the develop branch on github.  I suggest using it in 2D mode.  Things get a little weird on the globe at lower resolutions.

Performance & Next Steps

It's pretty good on the device.  You could use this in a shipping product.  The style is a little bland, but it's fine for a demo.  Rendering performance is decent, but could be optimized.

Needs more labels

Mapzen's set things up so you can fetch individual layers.  I think it would be interesting to use, say the symbol and labels on top of one of NASA's live data sets.  Somebody go do that and let me know how it looks.

New App: National Geographic World Atlas

WhirlyGlobe-Maply is now at the heart of the National Geographic's World Atlas iOS app.

And why not Belgium? (tm)

I plan on being insufferable for a week and then smug for another two months.

The App

It's gorgeous, just go buy it.  You may already have it, lots of people do.  NatGeo provided 4.0 as an update, which is really nice of them actually.

The Technology

There's some really interesting stuff going on with the globe.  For instance doesn't that text look suspiciously... sharp?

Did you know Vatican City is its own country?  Of course you did

We'll talk more about the process later, but let's just say it involves: PDF, Mapbox, hybrid raster/vector tiles, on-device font glyph rendering and lots of math.  Getting that classic NatGeo map look on mobile, but better, was interesting.

The People

I just did the globe.  Rally Interactive did the bulk of the user interface and it's gorgeous.  Mapbox helped out on the data processing and storage side.  National Geographic did some of the development and all the data (of course) as well as the project management.  That last one was some serious work.

That'd hurt if you picked it up.

It was a pleasure working with Rally and NGS.  It's a hell of an app and I hope the users love it.

eLLaWalk - Maply Android App

I'm excited to announce the very first shipping Android app using the Maply toolkit.

eLLa Walk App

The eLLa Walk app for Android (did I mention Android?) is a promotional tie-in with the eLLa fragrance from Victorinox.

The app is tied to their web site where users assemble their Instagram photos into short hikes.   They can share the hikes, search for interesting ones and generally do social networking stuff.

The development agency was coANDco in the UK and they were a delight to work with (translation: paid on time).  I did the map.  That's what I do.  Maps.

Custom Map

They're using a custom map for their app (and the site).  Built with Mapbox tools, it's a great example of branding your map tiles.

The map functionality they otherwise needed was fairly basic.  There were screen markers for the pictures, remote tile paging, some specialized caching and a full range of finger gestures.

This being Maply it's threaded to the gills.  Even if we're only adding 20 markers, we're not going to slow the main thread or the rendering thread.  Otherwise, fairly normal stuff.

Maply For Android

As I mentioned in a recent post, Maply for Android is in Beta.  The official beta #1 is out and now there's a real shipping app on the Google Play store.

Next up, some cleanup, some documentation and more Android app projects.

Tile Loading

WhirlyGlobe-Maply 2.3 saw some significant improvements in tile loading.  Most of this was focused on maps. Let's take a look at how it used to work and what's available now.

Images and tile numbers

Loading From the Top: Globe

WhirlyGlobe-Maply is called that because the globe came first.  It's often used as a whole globe with the user starting zoomed way out.

Mapbox Terrain Style

The image tile loading worked like this.

• Start at the the lowest resolution tile (e.g. [0: 0,0])
• While there are tiles to load
• Load the current most important tile.
• Did it fail?  Okay we're done here
• Did it succeed?  Great, add the four children to the list.

Who doesn't love pseudo-code?  Let's just see what that looks like.

By the numbers

That approach had some advantages.  Tile sources can be sparse and it's a little resistant to network failure.  Most important (to me), there are never any holes in the globe.  There's always something to look at, even if it's blurry.

Loading From the Top: Map

One secret of WhirlyGlobe-Maply is that the globe and map share most of their code.  So when I got the map working, I used the same tile loading scheme.

Loading from the Top with Mapbox imagery

That worked okay, but if you start out zoomed in to the map you're waiting a long time to see the right tiles.  There's a whole lot of blurry for far too long.  It gets worse the farther you're zoomed in.  Here's how that looks with tile numbers.

Loading from the top by the numbers

The flashy colors at the beginning are low res tiles we can't see the numbers for.  I could probably argue there are cases where that works well.  But not for a map.

Loading the Current Zoom Level

The obvious thing to do for a map is to load the zoom level we need for the area we're looking at.  If it's a flat (2D) map, that's actually pretty easy.

Single level load with imagery

Simple, but I don't like it.  You're looking at too much blank screen.  For a retina display and a remote tile source this is irritating.

Still, there are cases where this may be appropriate and it's easy enough to activate.  When you set up your MaplyQuadImageTilesLayer set useTargetZoomLevel and singleLevelLoading to YES.

Single level load by the numbers

And again, the tile loading with numbers.  Fine for some cases, like a weather overlay.  But we can do better.

Loading Multiple Zoom Levels

Focusing on a single zoom level is great for performance, but bad for display.  I'd rather have a hybrid that loads a few low res tiles and then fills in the rest.  Like this.

Multi-level load with Mapbox imagery

That's nice.  We've got something reasonable to look at almost immediately, then we get some detail.  When the highest resolution comes in we probably didn't realize it wasn't already sharp.

Multi-level load by the numbers

Pretty good, but the levels you want to load may depend on your tile source.  Luckily, it's configurable.  When you create your MaplyQuadImageTilesLayer set useTargetZoomLevel and singleLevelLoading to YES and then assign an array of numbers to multiLevelLoads.

For example, try @[-4,-2] in multiLevelLoads.  If the user should be looking at level 22 data, then the layer will start out loading level 18, then work on level 20 and then fill in level 22.

Summary

The old tile loading logic could feel out a sparse tile source efficiently.  The new tile logic can do it too, but wow was that complicated.  And perhaps less efficient.  If you've got a normal tile source, it shouldn't be a problem.

I like the multi level loading approach.  But it does cost more memory and rendering time than the single level approach.  Use it thoughtfully and test it in your app.

This is all available in WhirlyGlobe-Maply 2.3.

Taking Mapbox Vectors for a Spin

I've been working on the vector tile support in Maply for months now, including Mapnik vector tiles.  The biggest proponent of Mapnik style vector tiles is Mapbox.  So let's look at Mapbox's Mapnik Vector Tiles, shall we?

Thoughts on MapBox's Vector Tiles

They're nice.  The servers are fast and the content is good.  Given that these aren't explicitly designed for mobile use, they work pretty well anyway.

If it were me, I'd add another couple of levels in dense areas.  Newer hardware can power through the level 14 tiles, but it tends to strain older devices.

Can I Use These?

No.  Mapbox hasn't released the tiles and there's no way to pay for them.  You shouldn't make an app with them.  Don't be that guy.  No one likes that guy.

Nonetheless, they work great in Maply and if you were a big enough customer I'm sure you could work something out with Mapbox.

Why did I bother?  Believe it or not, this isn't the first set of Mapnik vector tiles I've supported.

Maply Vector Tile Support

Other people are doing their own Mapnik vector tiles, standing up their own servers, and generally doing their own thing.  Some of them are my customers and some of them have even shipped apps.

The Maply support for vector maps is in good shape, but there are a few things I'd like to improve.  Labels could be better, particularly the font twiddling and layout modes and there are some bugs worth tracking down.

Mapnik vector tile paging is in WhirlyGlobe-Maply 2.3.

MapBox Vector Tiles

I am delighted to announce support for MapBox Vector Tiles.

Vectors, vectors everywhere!

Maply 2.3 supports MapBox Vector Tiles natively.  You'll see this in the develop branch in the next couple of weeks.

Gaia GPS 9.0

The folks who make Gaia GPS have been busily switching to Maply for their display.  It's great to have them test out the map focused features and they've been steadily contributing back.

Contours!

And how they've been contributing!  Jesse Crocker put the MapBox Vector support together crazy fast.  It shares a bit of DNA with the Maply Vector Tile loader, but it's definitely it's own thing.

So can you use it?  Sure, but there are details...

MapBox Pricing

We seem to have outrun MapBox's pricing scheme on this one.  The Gaia GPS folks are in contact with MapBox so it's all copacetic, but before the app goes into production they'll be having discussions.

What that means to you, my users, is that you too need to sort it out with MapBox before you ship.  Don't be that guy.  No one likes that guy.

Odds & Ends

There's plenty more work to do here.  Jesse put together the styles Gaia GPS cares about, not the ones you care about.  That topo style is awesome, but it's not ideal for driving or walking in a city or whatever your app may do.

This one is just gratuitous

If only there were some way to get us to... oh wait!  We're contractors!  That's right, you can pay us to add Maply features or even write your app.

Jesse and I will be at State Of The Map in DC this weekend.  Drop on by the Maply table and we'll be happy to show this off.

WhirlyViz Demo

The other day I was planning to give a short talk on WhirlyViz at the San Francisco GeoMeetup.  Due to equipment problems it never happened.

Rather than let slides go to waste, here's the talk in video form.

You can get WhirlyViz on the app store.

The URLs I use as examples can be found in a previous blog post.

GeoData Display for Mobile Devices with OpenGL ES

I gave a talk last night at the San Francisco Bay Area GeoMeetup.  This one was timed to coincide with Google I/O.

The talks were the 5 minute Ignite format and, just to be different, I went deep technical.  I pulled a couple algorithms out of WhirlyGlobe-Maply and explained them.  I like how it turned out.



The video has audio and, hey, it's short.

The slides, sans video, can be found here.

MapBox Earth

It's been a busy month for MapBox.  Their new OpenStreetMap editor launched, for one thing, and now they've published a pretty little app to show off their satellite data sets.

Actual picture of the earth.  NASA photoshops out the labels.

It's WhirlyGlobe-Maply powering that app and, indeed, the whole thing is open source.

How It Happened

I approached MapBox about doing this one a few weeks ago.  It's basically advertising for me and it was really simple to write.  Take a look at the source code, it's just not that big.

Once I put the first version together, Justin@MapBox cleaned it up and generally made the UI elements work better.  That stuff takes more time than you realize.

Then we shipped it and now you can play with.

Future of MapBox Earth

The app's goals were to show off MapBox's lovely satellite data sets and advertise WhirlyGlobe-Maply.  I'd say we're good on both of those.  What's next depends on what people want to do with it.

Since the app itself is open source and the toolkit is open source... you can do whatever you like (within the constraints of an Apache 2.0 license).  Or you can pay me to do whatever you like, which is kind of how I make my living.

We'll see how that goes.  In the mean time there are other interesting things afoot with MapBox and mousebird consulting.

route-me and Maply

I like route-me.  It's open source, it's been around a while, lots of people use it, and it works.  Heck, I used it on a project once.

For those in the dark, route-me is a free toolkit for displaying custom slippy maps with overlaid shape, marker and other features on iOS.

Anyway, I like route-me, which puts me in an awkward position.  I want to replace it.

Maply

I make an open source toolkit called WhirlyGlobe-Maply.  There are three ways you can use it.

3D Interactive Globe   -   Interactive 3D map with tilt   -   Interactive flat (2D) map

The WhirlyGlobe part is the globe, the Maply part is the other two.  I've done a bit with the interactive 3D map and it's a blast, but it's not what most people want to do.  They want a true flat map.

Okay, so great, I can do a flat map.  But why bother?  If you want Apple's data, you use MapKit, if you want Google's data you use their iOS API.  If you want your own data, you buy a commercial toolkit or you use route-me.  Do I really have anything to offer over route-me?

I do.  WhirlyGlobe-Maply is based on OpenGL ES.  My toolkit is in the same class of "stupid fast" as Apple's, Google's, and the commercial alternatives.  I can't beat them feature for feature, but then I don't have to.  Mine is open source.

That's a fun bit of self aggrandizement, but it really needs to lead somewhere.  I think it's only worth matching route-me's features if someone's paying.  There's money out there for this kind of thing and it's welcome to look me up.  And it did.

MapBox

The MapBox guys, Justin particularly, have their own route-me variant they call the MapBox iOS SDK.  It's really nice, with a lot of functionality filled in and tons of documentation and examples, things that open source projects often lack (cough).

Very cool, but route-me uses Quartz, the technology behind UIKit (kind of).  That's what you're supposed to do, but it's not as fast as the new Apple Maps.  They're obviously not using Quartz, they're using OpenGL ES.  Maply uses OpenGL ES so...

MapBox is paying me to jack up their version of route-me and stick Maply underneath.

route-me + Maply = What?

The idea is pretty simple.  Accelerate route-me's tile display with Maply, then see if we can do anything with annotations.  In theory it looks pretty good.  The initial experiment looks good too, but we've got a ways to go.

If everything goes well, the standard route-me app might be able to switch over seamlessly.  Your custom Quartz rendering will still be Quartz, but anything you represented in route-me tile sources and annotations could be handled by Maply.  Or not.  It's an experiment, we'll see.

San Francisco GeoMeetup

I'm speaking at the Bay Area April GeoMeetup tonight.  I'll be talking a little bit about WhirlyGlobe-Maply and how my users consume OpenStreetMap data.

As promised (at the talk) here are my slides.

Image Paging & MapBox Data Sets

Large image dataset paging has been in WhirlyGlobe for several versions now.  With 2.1, it's gotten a lot more efficient.  In this video I discuss some of the improvements and play around with a couple of neat MapBox data sets.

Interfacing With MapBox

The WhirlyGlobe Component has had remote tile support for a while.  Just provide a base URL and it'll start fetching images in a standard tiling scheme.  In honor of the new MapBox data sets, I decided to make this even simpler.

Some data providers will put a TileJSON file at the top level of their data sets.  MapBox does this, of course, and it provides a little extra bit of information and makes the developer's job simpler.

I added support for parsing TileJSON files to the WhirlyGlobe Component.  With a little help from AFNetworking, we can make the code incredibly easy.

// globeViewC is our WhirlyGlobeViewController
// jsonTileSpec is the full URL for the tile spec
// thisCacheDir is a local directory where we'll cache images
NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:jsonTileSpec]];
        
AFJSONRequestOperation *operation =
[AFJSONRequestOperation JSONRequestOperationWithRequest:request
  success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON)
  {
       // Add a quad earth paging layer based on the tile spec we just fetched
       [globeViewC addQuadEarthLayerWithRemoteSource:JSON cache:thisCacheDir];
  }
  failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id JSON)
  {
       NSLog(@"Failed to reach JSON tile spec at: %@",jsonTileSpec);
  }
];
        
[operation start];

There are blocks involved, so the syntax is a bit horrid, but the result is pretty simple.

• We send out a request for the top level TileJSON file.  
• When it comes back we hand it over to the addQuadEarthLayerWithRemoteSource: method on our globe view controller.  
• WhirlyGlobe does the rest.

WhirlyGlobe 2.1

You can find the new functionality and performance improvements in WhirlyGlobe 2.1.  That version is in beta at the moment, but it's quite stable.

I'm adding a few more minor features, mostly based on requests, and that'll be the release version.  Look for a comprehensive feature video soon.