Saildrone Forecast

Is there anything cooler than shipping an app you've spent a year and a half working on?
It was a rhetorical question.  There is not.

Saildrone Forecast

Hint: It's a weather app.

Saildrone Forecast

Yup, Saildrone Forecast is a weather app.  Just watch the video.

Go download it.  I'll wait.

Technical Bits

There's a ton of stuff in Saildrone Forecast that's unique.  But there are a couple bits of interest in WhirlyGlobe-Maply itself, like the new sampler/loader architecture and offscreen render targets.  Go watch the video.

Could you make your own weather app out of the box now?  Ha ha.  Oh god no.  There's so much other stuff to do.  Not to mention the data.  But there are cool things to do with the vector maps and render targets.

Acknowledgements

I didn't do this all alone.  Heck, I didn't even write the whole app. 

Credit goes to Logical Animal for the rest of the UI.  Big thanks to the meteorology/modeling team at Saildrone for the data and putting up with stupid questions.  Thanks to the platform developers and ops for processing data and keeping it running.  And, of course, management and finance upon whom I can bestow the greatest contracting honor:  They always pay early.

Technical Advisory Committee

I'm forming a technical advisory committee.  We'll meet a few times and discuss the iOS Metal port and rendering architecture in the toolkit.

This post is for developers I'm trying to recruit to the committee.  Let's start with the basics.

What is WhirlyGlobe-Maply?

National Geographic World Atlas (RIP)

WhirlyGlobe-Maply is a real time geospatial display toolkit for iOS and Android.  It's used in a whole bunch of apps, like FlyQ EFB and a few big weather apps like Dark Sky.

Dark Sky

The toolkit's been around since 2011 and it's carved out a crazy little niche in aviation and weather.  It's not a wildly profitable business, but it doesn't lose money either.  How many can say that?

Morecast

Oh, and it's open source.  So that's fun.

WhirlyGlobe-Maply 3.0

The last version I shipped was 2.6 a few weeks.  A huge improvement for data loading on iOS and a nice upgrade to the Android build system.  I.... need to do a post on that.  But no time.

3.0 is the big upgrade.  I'm going to add iOS Metal support, redo the rendering internals and upgrade the Android port with a better shared C++ core and newer versions of OpenGL ES.

Technical Advisory Committee

So here's the deal.  I'm adding a new renderer for Metal and replumbing the internals to match.  I'd really love to discuss it with a few experts along the way.

This is an open source project so, you know, not a ton of resources.  Here's what I'm offering:

• Free lunch in a pleasant conference room at my coworking space in San Francisco
• An invitation to pontificate on real time rendering without having to do any work
• A cool entry on your resume

You do not need to know anything about geospatial or weather or aviation.  I got that covered.  Here's what I need from you:

• Work in San Francisco or nearby.  No budget for travel, sorry.
• Know something about real time rendering, iOS Metal or Android OpenGL 3.x
• Willingness to chat about real time rendering

It's your real time rendering chops I'm interested in.  So game developers most welcome!

Contact me at sjg@mousebirdconsulting.com and we'll see if you're a good fit.

MapKit Compatibility Roadmap

We get asked this one a lot:  "Why can't you be more like MapKit?"  It's a good question.

MapKit, obviously.

Internally the toolkit won't ever be more like MapKit.  But we can pretend in a couple of ways:  Overlays and Interfaces.

MapKit Overlay

MapKit provides overlay options for everything from markers to tiled image sources.  Annotations are super flexible, but very slow beyond a handful.  And don't even think about animated tile sources.  Ouch.

For some data sources it's going to be easier to render in WhirlyGlobe-Maply and slap the results on top of MapKit's UIView.

It's not topical, I just like MapKit's stations.

That's the solution.  We'll track what MapKit is up to, at least in flat map mode, and overlay our own rendering to match.  Think weather apps.

MapKit Interfaces

MapKit has a nice collection of interfaces for adding annotations, great circles, and all sorts of other good stuff.  We'll try to be more compatible with those.

Portland in MapKit.  Why not?

This means methods that take MKMapPoint or CLLocationCoordinate2D objects.  It means init calls that are similar to the MapKit equivalents.  And yes, it means working in (shudder) degrees.

The goal here is a simpler conversion from a MapKit app to a WhirlyGlobe-Maply app.

UIView vs UIViewController

This one really bugs a handful of developers.  Our main interfaces are derived from UIViewController rather than UIView.

View Controllers are nice because they have life cycle events.  You have to wire all that up yourself in a UIView.  But it's possible and we'll do it because we know you want it.

Roadmap Not Actual Size

That's the plan and this all goes in the base toolkit so it'll be free.  But we need money to do it.  Always with the money.

As with all our plans, it'll get done eventually.  Pieces will go into proposals, clients will step forward, and some of it we'll just do ourselves.

Got feedback?  Let us know.

Integration with Micello Indoor Maps

A few months ago we were approached by Micello about displaying their indoor maps in WhirlyGlobe-Maply.  They provide indoor maps to a ton of interesting companies.

Taste the Capitalism!

Seemed like an excellent idea so we went ahead and whipped up a tutorial and demo.

Micello Tutorial

Micello was kind enough to provide a few examples.  We chose the Westfield Valley Fair mall near Cupertino.  I used to live there and have a certain fondness for it.  There was also a recent story about the minimum wage change that cut right through the mall which we incorporated into the display.

If you've got a Micello account feel free to work through the tutorial and let us know if you have nay questions.

On To the Future!

Ranen put together a rather nice example app, which is what you build in the tutorial.  It shows off some fairly clever display with styles, selection and a few other things.  But we could do more for optimization, label layout, and general display flexibility.

Our example was built on the globe, but you could as easily put it on a regular map.  Doing something special for pure indoor map display is also an interesting idea, though this seems to work well enough.

WhirlyGlobe-Maply is an open source toolkit, so you can take the code and run with it.  Feel free!  But we do consulting if you've got a budget and some requirements.

Map Projections

Let's talk map features.  How about custom projections?

Does this projection make my poles look big?

Spherical Mercator (web mercator) is the most common map projection you'll see.  It's a fairly simple unraveling of the earth, but its main purpose is to annoy cartographers.  Did you know the EPSG code for Web Mercator stands for "DIAF".  True fact.  Look it up.

Our users mostly stick with web mercator, but we now let you specify your own custom projection.

Proj.4 CoordinateSystem

Like all the cool kids we use Proj.4 to represent coordinate systems.  In theory this allowed us to use a wide variety of systems.  In practice, we just used Spherical Mercator, Plate Carree and a very weak geocentric.

Recently we exposed Proj.4 directly with a MaplyProj4CoordSystem.  It's simple enough, if you're familiar with Proj.4.  Here's an example for British National Grid.

Full disclosure, there's actually a datum grid shift that goes with that for proper BNG.  We've shortened it for the example.

You can get these Proj.4 strings from spatialreference.org, among other places.  But odds are if you have the need, you already have the string.

British National Grid

The folks at Ordnance Survey were kind enough to help us sort this out.  Let's look specifically at the British National Grid, starting with a data source in BNG.

BNG tile source on spherical mercator

That's a 2D map with a base layer in web mercator (Stamen Watercolor) overlaid with a dummy tile source in BNG.  As far as these things go, that's the easy case.  Let's look at a more difficult one where the map itself in BNG.

BNG tile source on BNG map

In this one the map is in BNG with a base layer in web mercator and an overlaid dummy tile source in BNG.

That's pretty cool!  Web mercator stretches far outside the boundaries of the BNG system, so we convert the tiles to BNG and toss out any that don't overlap.  And it works!  But there's more.

BNG tile source on globe

Okay, not all that difficult as these things go but it looks cool.  We're just overlaying a dummy BNG source on the globe.

You can find all of these examples in the AutoTester app for iOS.  And there's more...

Android

This is something I hope to say a lot more in the future:  Custom map projections are also available on Android in the develop_3_0 branch!

A triptych of British National Grid

You can find these examples in the AutoTester app for Android.  I'll explain AutoTester in more detail soon, but it's already been a great help in development.

Next Up

The hard part here was tracking down the weird corner cases and systems which just don't play well with each other.  There are likely to be a few more like that, so let me know what you find.

We've got more map features in the queue, including some vector data display.  Stay tuned!

WhirlyGlobe-Maply 2.4

Version 2.4 is officially out!  It's been a while in the making.  Too long, really.

Version 2.4 is pretty.

For a list of features, go check out the list of features blog post.

If you're building a regular 'ol app using the toolkit, just grab the master branch or use the binary version, take a look at the documentation and get started.

Coming Up Next

The Cocoapod will be updated soon.  I'll edit the post.  But honestly if you're that excited to use the pod, just use the one we have in the repo.
[Edit: We've got the Podspec for version 2.4 up and running.]

We're already working on version 2.4.1.  Have been for months, really.

Annotations

In the spirit of map features, here's another new/old one.

We just added annotations in WhirlyGlobe-Maply!  Like, maybe 2 years ago.  Let's just ignore the faded "Grand Opening" sign flapping in the wind and come on in, shall we?

The finger is invisible.  Like in capitalism.

They look just like you'd expect and they work well.  Let's see how.

Tutorial

If we haven't reminded you enough, there's a fancy WhirlyGlobe-Maply site with some great tutorials.  Two of them use annotations.

The vector selection tutorial pops up an annotation on selecting a vector and the marker selection tutorial... well see if you can guess.

Technical Details

The "new" object here is a MaplyAnnotation.  It's based on the SMCalloutView by Nick Farina and exposes much of that functionality.  That gives you enough control for almost all cases.

If you need something different, there's still the old MaplyViewTracker, a much lower level interface for dragging a view around the screen.

Adding annotations is easy, with the addAnnotation: method.  To remove them, call removeAnnotation: or clearAnnotations to get rid of them all.

If you're messing with an annotation, say the user tapped on it and you need them to edit something, you can also freeze an annotation in place.

Next Up

We'll continue the map focus for a bit, but it's going to get much more interesting.

Also, WhirlyGlobe-Maply 2.4 is just about to release.  Really.

WhirlyGlobe-Maply 2.4 Features

There's a lot of cool stuff in WhirlyGlobe-Maply 2.4.  It's been about a year since 2.3, so there'd better be.

Stamen Watercolor + atmosphere = Wha?

Let's start with the popular stuff, move on to the pretty stuff and then round it up with everything else.

Basemaps

Remotely pageable image basemaps are the single most used feature in the toolkit.  Version 2.4 introduces a new way to specify them.  Rather than use the base URL and let the toolkit figure out how to add the level, x and y you can just tell it.

Give the MaplyRemoteTile source a URL with {x}, {y} and {z} in it.  We'll just replace the level {z} and the location {x} and {y} with the tile ID as required.  This means you can shove whatever other junk you need into that URL, like your access token.  Take a look at this tutorial for an example.

Cocoapods

The Podspec is back, at least in beta form.  You can find a WhirlyGlobe.podspec in the develop branch and, in combination with a tag (v2.4_beta8) you can use it right now.  I'll update the official one when we release.

Atmosphere & Night/Day Shading

You'd think I'd have done atmosphere long ago.  You'd be wrong, it's not all that useful.  But it sure looks cool!  And, okay, hardware is a lot faster now.

It does look cool, I'll admit.

There's a new shader for when you're zoomed out and one for the ground itself.  I can add the shader you need when you're zoomed way in looking toward the horizon if necessary.  And by necessary, I mean I accept cash and checks.

The night/day shading requires two sets of image basemaps.  You can see the ones I'm using the ComponentTester app.  Just turn on the "Stars and Sun" and "Night/Day Images - Remote".  Which brings us to....

Stars, Sun & Moon

That's right, you can show the sun, moon, and stars in their (maybe) correct positions.  I'm reasonably certain about the sun, less so about the moon and not so much on the stars.  It sure does look cool, though.

We're all going to die!

You might want to supply your own sun texture if mine doesn't amuse you.  It amuses me.  Consult the Component Tester app for the details.

Some of these features are cheap to run, some aren't.  For full atmosphere, you'll want some decent hardware for the fragment shaders.  Please don't overuse them.  I know you'll overuse them.

Particle Systems

We've got particle systems now!  They look awesome!  I have no examples I can show you!  Because client!

This is one of those advanced features, I'm afraid.  Drawing them is easy enough, but feeding them is work.  We're planning a nice example for the next version.

Elevation

This is another one of those cool features that people love, but rarely have money to pay for.  Well, someone finally did, so here you go.

It's just very gray right there.  Desert or something.

Specifically, this is support for Cesium's mesh terrain format.  You can get that from them and I like how it's structured.

At this point we just have elevation.  Cesium structures its terrain in a different tiling system from everything else, so we can't overlay images.  Future version, I think.

3D Models

The toolkit has support for true 3D models now, particularly Wavefront OBJ, a file format old enough to vote.  Obviously something newer would be nice.  Again, send your requests in the form of cash or check.

In addition to the model support, we can now do proper OpenGL ES based instancing.  This means you can have a bunch of these things moving around without using up all your memory.  And they can move, but more on that later.

There's also support for raw geometry.  If you can't specify your geometry through one of the standard ways, you can just start throwing triangles at the toolkit.  Obviously an advanced feature.

Shapes

3D shapes are like models, but much simpler.  This version added extruded shapes, which is nice for things like arrows.

Shading.  Is a thing that could use work.

You can control the location and orientation of shapes more precisely now too, with direct access to the matrix.  Shapes can, in some cases, be converted to models.  That's useful if you have a lot of them and want to make use of the model instancing optimizations.

Motion

Used to be you had to remove and add the same object repeatedly to make it move.  That's fine for one or two objects, but what about 2000?

Screen markers & labels in 2D and models and shapes in 3D all have Motion variants that take end points and durations.  In combination with the new fade and enable times, you can do some tricky, tricky things.

If you're moving one or two objects, don't bother with this.  If you're moving a few thousand, it's useful.  The motion is shader based, making it very efficient.

Animation State & Viewpoint Control

Controlling where the user is looking at has been annoying in the toolkit, particularly when heading and tilt are involved.  Now you can control it very precisely, even animate it.

Take a look at the WhirlyGlobeViewControllerAnimationState in the WhirlyGlobeViewController.  There are methods for getting and setting that state, as well as animating and interpolating between states.  There's even a delegate for doing your own animations.

Mapbox Vector Tiles

There's been a lot of work on Mapbox Vector Tiles, but it's advanced stuff.  I'll write up a user's guide to their vector tiles with WhirlyGlobe-Maply... one of these days.  You can use them, with a lot of caveats.

Courtesy National Geographic.

As a transport mechanism, the toolkit can handle some pretty interesting stuff, like vectors and images.  We're doing that with National Geographic World Atlas.

Styles are more complex.  Right now you can specify a style sheet with Mapnik XML, which is a little hard to work with.  Mapbox GL Style sheets are partially implemented, but that format is in flux right now.

It's very much for advanced users at the moment.  I'd like to change that in the future.

Performance & Twiddly Stuff

There are a bunch of features which, while important, are very boring if you're not writing a big, complicated app.  Course, those are my customers, so let's dive in.

Texture atlases have been in there for a while, but now they're exposed at the high level.  Take a look at the addTexture:desc:mode: method in the WhirlyGlobeBaseViewController.  That's a rather flexible way to add textures standalone or to the atlas and replaces all the other addTexture methods.  And texture atlases are very, very fast.

Billboards have been in there for a while, but can now be specified with a MaplyScreenObject. With that, you control the layout and use text that taps directly into the glyph engine.  Fast & memory efficient.  Expect to see more use of MaplyScreenObjects in the future.

Getting close to the ground has always been a problem, but it should be no more.  There were a variety of centering and offset fixes for a variety of visible features.

Selection supports absolutely everything now, from moving labels to polytopes to 3D model instances.  Not a lot of fun to write, but important.

Most objects now support vertex attributes.  You can send these along for the ride through the system and then read them in your own custom MaplyShaders.  For the handful of you that write custom shaders, use it for passing in things like height and then shading based on elevation.

Widened vectors have been in there a while, but they're not heavily used outside of vector tiled maps.  There are some improvements and bug fixes that should help.

Screen based texture application is now available.  That makes texture application for an areal feature look logical in the 2D display.

Absolutely everything is thread safe (probably).  My high end users make heavy, heavy use of dispatch queues so you can hit the toolkit from just about anywhere now.  If you're chasing performance, do your adding and removal in a dispatch queue, or several.  The toolkit can handle it and it works well on anything newer than an iPhone4.

Crashes & Bug Fixes

Version 2.4 includes a veritable metric ton of fixes for layer teardown, view controller teardown, dispatch queue teardown (or lack thereof) and all sorts of other weird corner cases.  Thanks to everyone who gave me access to their Crashlytics accounts!  Yes, I know it's called Fabric now, but that's a dumb name.

One bug a lot of you had seen is the BigDrawable crash.  Turns out that was related to running low on memory, but was not caused by running out of memory.  Despite my attempts to deny it, it was real and it's now fixed.

Conclusion

That's about it for 2.4.  It's a huge release and it's taken far too long for me to get it out.  Let's see if we can do better next year, eh?

And the best way to make that happen is to buy a Support Contract!  If I get a few more signups, I'll start doing nightly builds and try out monthly releases.

Cesium.js Terrain Support

We've been adding support for one of Cesium's terrain formats recently.  Cesium, if you don't know it, is similar to WhirlyGlobe-Maply, but for the web.

Our toolkit has its own gridded terrain format, but I'd rather use someone else's.  Cesium has a better thought out and much more expansive set of terrain formats and tools available.

I was recently invited to discuss it at a Cesium meeting in Los Angeles.

SIGGRAPH Presentation

I used to attend to SIGGRAPH religiously, but I haven't been back in years.  It was a blast to walk the exhibition and see what's new.  Lots, of course, but a lot still looks the same.  Heck, it still smells the same.  No no, not that way.  It's the air conditioning and the projection displays.

Anyway, I gave a short presentation at Cesium's Birds of a Feather meeting last week.  Slides can be found here.

The Short Version

But what you're probably wondering (if you're still reading) is how well does the Cesium terrain work?

It's a start

Cesium has a funky way of representing terrain tiles that don't match to your standard TMS/Google/OpenStreetMap/Mapbox view of the world.  So we can't overlay those data sets on top.  This is limiting.

The Future!

Obviously, I'd like to fix that.  We'll need to do some resampling of image tiles as they come in to match the Cesium terrain.  It'll be a bit slower, but simple enough for the user.

So for now, you can show Cesium terrain, but without images on top.  If you'd like to fix that, hey it's open source, go for it.  Or you can wait until someone pays us to do that.  I suspect it'll happen in the next few months.

Revisiting Support for WhirlyGlobe-Maply

A few months ago I introduced a support contract for WhirlyGlobe-Maply.  $600 USD for all the questions and bug fixes on the iOS version.

Nice 'stache, Australia

I like how support has turned out, but I need to make some tweaks.  But first up, who uses the toolkit?

Who Are The Users Anyway?

I had the image of a lone hobbyist beavering away at their personal project.  Yeah... not so much.  There are a few hobbyists, and they're cool, but they're rare.

So who is using it?  It's the serious app developers.  People doing it for a living, often part of a big corporation or at least something with revenue.  Organizations, if you will, who can afford to pay for things.

So You're Raising Prices?

Oh yeah.  I'm raising prices.  I'm spending more hours on support than I'm getting back in revenue and I'm not getting the overhead time I was after.

Support will now be $950/year.  I came up with that number by looking at hours spent, the number of contracts, and the desire to keep it a three digit number.

The support thing is working out well in every other way.  Seeing what people need and how they use it is really great.  And I've learned something really vital: people can write apps without me.

Wait?  The Toolkit Actually Works?

I know, right?  You could always write simple apps without me.  Now you can write big, complex ones without me.  WhirlyGlobe-Maply <sniff> is all grown up </sniff>.

HTML jokes.  Right below puns on the humor scale.

But I don't mind.  Not needing me is excellent!

So You're Going Broke, Then? 

Happily, no.  mousebird consulting (inc!) has business in the queue through early 2016.  We've just passed the revenue number for 2014.  Like, just a few days ago.

To pull that off, I've found a happy medium between pure toolkit features and whole app development.  Sort of whole module development, if you will.

What About Android?

Support is just for iOS at the moment.  See, the iOS version works more or less like it claims and I can fix any bugs that crop up.  The Android version isn't there yet.

It'll get there.  I've got big clients pushing big projects out on Android.  So it'll get there.

More!  I want more!

Okay, okay.  Fine.  How about this.  If I get 10 new support contracts by the end of 2015 I will set up automatic daily builds, some simple unit tests, and try monthly releases.  We'll have to see how that last one goes.

Plus, hey, features.

2.4: Day/night Shader + Atmosphere + Stars = Daaaaaamn

WhirlyGlobe-Maply 2.4 is almost out the door.  Beta5 just went up the other day and it is a scorcher.  Wow.  The stuff that's in 2.4 is just... daunting.  To write up, anyway.  I'm way behind.

Bored Now.  Wrap it up!

If you've already started talking to me about a support contract, you're grandfathered in at the old price.  Renewals will be a bit higher, but won't go all the way up to the new price.

Everyone new pays the new price.  But look at the benefits!  People are writing actual complex apps with just the support contract.  So can you!

GeoSpatialKit - A suggestion for Apple

I spent last week at WWDC in San Francisco.  Not too much new, but I saw a lot of performance and optimization in iOS9.  I spend a lot of time on those myself, so I approve.

But Apple's geospatial support is still... mediocre, particular given what they must be paying for the map.  I got to thinking:  What would make geospatial display work better on iOS and OS/X?

First, what am I talking about?

Geospatial Is....

Geospatial data display is maps and globes.  A weather app is a geospatial app, as is any sort of map app and so is an Atlas.

Globe, map.  Map, globe.  Same thing.

Geospatial is what I do.   I make a popular toolkit for map and globe data display on iOS (and <cough> Android </cough>).  Presenting geospatial display to developers in a way they can handle is what I do.

And that leads to the important question:  What's wrong with the way Apple does it now?

The Current Situation on iOS (and OS/X)

Let's use weather as an example.  Everyone loves (or hates) their weather app.  In any case, they have an opinion.  So how do you make a serious weather app, with animated radar and such?

You build a serious weather app in one of two ways:  Core Graphics or OpenGL ES.  You can tell which was used immediately.  Is it a little weird and janky (Core Graphics) or smooth and pretty (OpenGL)?

Why that is has a little to do with rendering and a lot to do with data management.  The way you display 20 pins in UIViews is not the way you render 20 layers of animated streaming radar data.

And okay, that's a hard case, but it's also plain old map apps that are kind of 'meh' under Core Graphics.  There's another reason for that.

MapKit Under Glass

The Maps App is a big, capable and (I imagine) very expensive system.  It does a lot and it's pretty good at it.  MapKit looks to be a sort of wrapper on top of it.  That's a problem.

Hands up.  Who's reimplemented that compass?

You can't change the bulk of what MapKit is displaying.  Sure, you've got a few knobs to twiddle and you can toss a little of your data on top, but only grudgingly.   But there's an even bigger issue.  MapKit was obviously (obviously!) written with OpenGL ES, but none of that infrastructure is available to the rest of us.

So here's the question.  If you scooped out MapKit's brains and made neat little piles, what would that (unfortunate metaphor) look like?

CATiledLayer Revisited

I think you'd start with CATiledLayer, the go-to data structure for the pre-OpenGL map era.  As a reminder, CATiledLayer will break the world into little pieces and tell you when to load those pieces.

Something like this

A new CATiledLayer is a good place to start, but it's probably a bit low level and it's missing one giant thing: A Spatial Reference System.

Adding an SRS to a CATiledLayer(-like thing) would solve the first set of problems.  Your data could exist in one system while displaying in another.  I'd also make the levels and loading strategies explicit with budgets for tiles and such.  And threads everywhere.  EVERYWHERE.

One tile loading strategy

That helps with loading, but what do you do once you've got that little image or basket of vectors for a tile.  How do you render it fast?

With Core Graphics, you really don't render it fast.  And the layer based image solutions are kind of weak.  It's time to drill a hole in UIKit and plunge into the icy waters of OpenGL ES.

Images, Vectors, and Shaders - Oh My!

Most of what you want to display on a map is pretty simple:  Image tiles, symbols, text, lines, and polygons.  All pretty easy to display slow, but hard to render fast.

Sometimes a map is just a map

Here's what you do.  You develop a little system for abstracting those object types to hand to a renderer.  Then let the system manage them, batch them and move them around.  Essentially you've moved the developers job off into other threads:  Just load the data and let the system handle it.

This is suspiciously similar to what I do in WhirlyGlobe-Maply.

What About The Globe?

Well, yes, everyone loves the globe; even developers who should know better.  User interaction with a globe is just different from a map and switching between the two makes life harder than it needs to be (looking at you MapKit).

Globe + Weather = Awesome

But the globe is cool, so where do you put it?  SceneKit.  SceneKit is where you put it.

Pull the tile loading logic from CATiledLayer++ above, make a nice globe surface and voila!  You can reuse most of what you build for the 2D maps.  Sure, it's a little more work to set up SceneKit and live in OpenGL-land.  But globe.

Aaaaand back to MapKit

Okay, so you've built up a nice rendering infrastructure for map tiles, vectors, symbols and other such stuff.  It gets along with both UIViews and SceneKit.  But does it use anything from MapKit?  It also begs the question:  Should you rewrite MapKit in this stuff?  

No.  Good grief, no.  Only interns and the criminally insane rewrite working systems for the hell of it.  Instead, you steal data from the map.

Nothing personal, Santa Rosa

Apple Maps has a number of interesting data layers it would be fantastic to reuse in other apps:  Roads, water, symbols, land, parks, and labels to name a few.  Especially labels, which would make one of my dreams come true:  Putting the @%&#@ labels on top of the animated radar.

Map Data Reuse

Mere mortals can't reuse Apple Maps data... but Apple could.  If they started teasing it apart and tossing it into a system like I've described above, it would make maps apps that much more interesting.  And yes, the label thing, which bugs me a lot.  Seriously, that's annoying.

Missouri?  Maybe?

This would also let us mix and match data from varying sources.  There are some excellent map tiles out there and I'm sure Apple could come up with a few more of its own that don't quite belong in what they've got now.

Wrapping it Up

I've skipped over a few details, but here's the basic story.

• Add a Spatial Reference System for selected layers
• Soup up CATiledLayer for some serious tile management
• Drill a hole down to OpenGL ES (and/or Metal) for some decent primitive display.
• Globe meet SceneKit.  SceneKit, globe.
• Start pulling data layers out of the map source.

Do that, Apple, and you've got yourself some seriously reusable geospatial display support.  It would be interesting to see what came of it.

Actually, feel free to not do that.  It would put a crimp in my WhirlyGlobe-Maply business.