Part 1: Existing 3D Support in WhirlyGlobe-Maply

We've got a two parter for you.  First up we'll look at the existing 3D support in WhirlyGlobe-Maply.  Next time we'll lay out the roadmap for 3D in the future.

So let's start with the question:  Isn't WhirlyGlobe-Maply already 3D?

3D Minus 1D Equals 2D

Everything WhirlyGlobe-Maply does is 3D, but we hide it most of the time.  Look at some of the more prominent apps, even ones that use the globe.

Dark Sky, Gaia GPS, NatGeo World Atlas

The giveaway is the gestures.  Can you tilt?  Nope.  And we're not hiding some wealth of information.  If you did tilt toward the horizon you'd see.... nothing much.

To be truly 3D an app needs to turn on the 3D gestures and it needs data with real 3D structure.  There are a few that do it and we provide a lot of functionality to support them.

LIDAR Point Clouds

Did you know WhirlyGlobe-Maply supports LIDAR in a pageable sqlite format?  It does and it's pretty cool.

Available on both iOS and Android in 2.5 this is an essential use of 3D.  You couldn't see all that much in 2D... well okay you can, but it's better in 3D.

Truly 3D Terrain

We've been able to do true 3D terrain for years.  Aviation apps use it.

FlyQ EFB Synthetic Vision Mode

Why don't you see that more?  Well, it's useful for aviation and.... um, games maybe?  Users tend to be specialized.

Models, Markers, Billboards, Labels & Lines

The toolkit can display 3D models in Wavefront OBJ, a data format old enough to vote, but it works well enough.

We can also do billboards, which are like a 3D version of markers and, of course, labels.  Here's what you'd use that for.

NATS Airspace Explorer

Inspired to make your own 3D traffic app?  Of course you are, but it's a lot of work to get the display right and the data is expensive.

General 3D Geometry

Lots of our users make stuff up on the fly.  Why?  Because if there was a pre-packaged version of it, they wouldn't be making an app.

Fake airstrips are fake.  Do not try to land.

For stuff like this we've got a model generator.  You build up your special snowflake of a model polygon by text by line as needed.

If you've already got 3D geometry, you can hand the triangles over to the renderer.  Hard core, but useful in a few cases.

Lofted Polygons and Extrusions

On the easier side are a couple of features that let you think in 2D and tack on a height.

Downright candy colored

Lofted polygons have been around a long time and work well on the globe.  They're nice for showing relative height... and they just look cool.

Extrusions are a way of whipping up a model without having to do, like, math.  You can slap together an arrow, for example, to point at things.

Where We're Heading

WhirlyGlobe-Maply has extensive 3D support and real apps (mostly aviation) have been using it for years.  It's all rather do-it-yourself though, particularly on the data side.

There are a number of good data sources for 3D coming on line recently.  In the next post we'll discuss how we'd like to use them and where we'd like to go.

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.

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.

Android Tutorials

We have tutorials!  For Android!  Yay!

Screen shot of a web page?  I'm not proud.

A big thanks to Nicholas for putting these together.  And to José for doing the binary AAR examples.

Getting Set Up

The first few tutorials focus on setting up a really basic project and getting the WhirlyGlobe-Maply library included.  We now have three ways of doing this from least Android-y to most Android-y.

• Build from source
• Download a nightly build
• Include the AAR from JCenter

Yes, we're doing nightly builds for Android and we have the JCenter/Maven thing set up.  Once you've got the toolkit included, you can peruse the tutorials on actually doing stuff.

Enough With the Typing

There's nothing more to say.  Go check out the tutorials if you're doing Android development with WhirlyGlobe-Maply.

If you'd like more tutorials on iOS or Android, open up an Issue.  That's how we communicate.

We can thank the Support Customers for this since it came out of their budget.  More support contracts means a bigger budget.  It's all spent on stuff like this.

Mapzen Vector Tile Service

We're going to support Mapzen's Vector Tile Service.  Currently that means we read their vector tiles.  In the future we'll support their style sheets.

Courtesy Mapzen

Let's do a little background and then get to the details.

Vector What Now?

We've been slinging around vectors for years in WhirlyGlobe-Maply so vector tiles weren't a huge diversion.  We even had our own format for a while.

These days vector tiles means Mapbox Vector Tile format, but it implies two other things:

• A curated version of OpenStreetMap suitable for web and mobile map display
• One or more style sheets to describe the visual representation

You might call this a Vector Tile Service if you were so inclined.  Developers want to shove a map underneath the thing their app is actually doing.

It's a trivial, seamless process with an image tile service.  We're going to make it just as easy for a vector tile service.

Here is our roadmap to get there.

Mapzen Vector Tile Service

We can parse and display Mapzen's vector tiles just fine in either GeoJSON or Mapbox Vector Tile format.  But we use really simple style sheets.

Must be night or something

That looks kind of meh.  For a real map we need better.  There are a number of ways to do style sheets, but I'd like something that requires minimal upkeep.

Mapzen has a Javascript/C++/Java based renderer called Tangram.  It's got it's own style sheet format.  That format is.... very specific to Tangram. 

I've been on the fence about their style format.  Some discussion was in order.

Data Formats & Common Usage

Data formats have crazy parts.  Go look at PDF (better yet, don't).  You have to decide what's common usage and what parts you ignore, at least for a while.

The Mapzen folks were kind enough to host a meeting where we could explore this.  It looks like the common usage among their various style sheets is blunting the weirdness.  They've got professional cartographers using it, in addition to engineers, which is a big plus.

In short, when we see some deep_Tangram_weirdness we can substitute minor_WG-Maply_weirdness and it'll look pretty similar.  Good enough. 

There's Open and Then There's Open

The most attractive thing about the Mapzen Vector Tile Service is the terms of service.  You can use the data in any API and in a variety of ways.  As long as you're not completely rude.

Best of all, you can mix online and offline databases without violating the license.  That makes it perfect to slip into a WhirlyGlobe-Maply app and in our test apps.

That's not a knock on other services.  I get that the API and data are often tightly linked by a license.  That's how you make money.  And speaking of money...

Roadmap and Funding

The vector tile part works just fine in WhirlyGlobe-Maply now.  We still need to implement the Tangram style format.  We're just wrapping up Styled Layer Descriptor support so it shouldn't be all that difficult.

It does require money.

That's the roadmap.  If you're interested in any part of it, speak up.  I get asked about this a lot, so it'll get paid for eventually.

State Of the Map - Brussels

I'll be at State Of the Map this year in Brussels.  SOTM is running from September 23 through the 25th.

Apparently purple is the thing this year.

This is something of a convenient detour.  We're heading to the Meteorological Technology World Expo that next week in Madrid.

I've got a table and I'll be showing off the usual stuff.  Given the crowd, I'll lean more on the map apps.

If you're going to be there, drop by and say hello!

Announcing WhirlyGlobe-Maply Imagery Pro

Today I'm delighted to announce the first option on top of the WhirlyGlobe-Maply toolkit: Imagery Pro.

The red's moving away so that's good.

Up to now everything has gone into the free toolkit or client apps.  This marks the first time we're keeping something to ourselves and, yes, charging for it.

Who's This For?

We love all our users equally.  Okay, maybe we love the ones who pay support a little bit more.  But you're all cool.  Honest.

We've attracted a lot of weather and aviation users.  It makes sense.  They have pretty serious data display needs and only a passing interest in street maps.

Imagery Pro is for them.  We're taking what we've learned and pushing way beyond.

What's In It?

It's all in the marketing, but the basics are like so:

• Efficient data transport
• Fancy shaders
• Getting rid of the !#*$& seams
• Easier particles

I do love my animated gifs

All good stuff if you do weather and/or aviation.

So what about WhirlyGlobe-Maply?

That's right.  My five year plan to give away massive amounts of geospatial code is finally coming to fruition!

But no, the base toolkit is all good.  Imagery Pro is about expansion into a couple of markets that want much more right now and they're willing to pay for it.

We're continuing to expand WhirlyGlobe-Maply with iOS (2.5) and Android releases in the pipeline.  That's not going to change.

Build System

We've wanted a more formal build system with WhirlyGlobe-Maply for quite some time.  Thanks to José we've finally got one!

Nightly and on-demand builds are now available!

Binary Versions

It turns out not everyone wants to build the toolkit from source every time.  Weird, right?

So for those strange people we've had a binary distribution.  You can see it linked off the main site and it got updated... you know... sometimes.  Well now we're doing better.

If you go to the Builds tab on the WhirlyGlobe-Maply site you'll see this.

That's the filtered output from our Jenkins server, a Mac Mini sitting in the corner of my office.  I expect it to last several years before filling up with dust and catching fire.

You can just use the binary framework directly on iOS.  On Android it's an AAR file with every frickin' architecture.

Binary Cocoapod

If you're a Cocoapods user the iOS zip files contain a Podspec.  That makes it a self extracting Pod.  To use it, all you have to do is this.


If we've pointed you at a specific feature build, you just use the URL for that one.

Continuous Integration

We're also triggering builds for commits to certain branches.  For now that's just develop_2_4_1 (aka version 2.5) and develop_3_0 (Android).  We'll add more as we go.

This is nice internally and it's already caught a few commit mistakes, but we plan to go further. The goal is to hook up our test apps and run them on attached Android and iOS devices.

All this work was done under the guise of WhirlyGlobe-Maply support.  You support customers paid for it.  Thanks!

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.

Digital Globe Tutorial

We put together a tutorial for Digital Globe layers.

Alaska is pretty

Digital Globe has a pretty nice API based off of Mapbox technology.  Or administered by Mapbox?  Not totally clear on that.  Anyway, it's good.

The Tutorial

All the good stuff is in the tutorial.  I suggest you go check that out.  Here's another picture.

Trippy.  Or elevation.  One of those

Anyway, Digital Globe is a great source of high resolution timely satellite imagery.  Because of course it is.  That's what they do.

Swift Support

It's new, it's trendy, it's the latest thing: Swift support in WhirlyGlobe-Maply!

Swift has been in there since 2.4.1 (soon 2.5), but we haven't really pointed it out.

Why Swift?

I'm not the audience for Swift.  My favorite language is a mixture of C++ and Objective-C.  You get STL containers, blocks, and ARC.  It's awesome.  Why are you backing away?  Let me tell you more!

This is why I work with other humans.  José was quite interested in Swift and did the bulk of the work.

Swift Interfaces & Documentation

The main issue was Swift bindings for all the various methods.  Swift can interface to Objective-C just fine, but if you want to make it pleasant, it should look like this.

He did that everywhere and tested it out.  The result is a nice, pleasant Swift interface to the main library.  But we didn't stop there.

Feel the learning!

The tutorials have tabs for Objective-C and Swift!

Swift Tests

In the new AutoTester app (post forthcoming) José wrote a bunch of Swift test cases.  These have a pleasing rhythm to them.

Swift-ly into the Future

We're getting user submitted github Issues in Swift now.  Not about Swift mind you, just in Swift.  So that seems to be working.

As Apple changes the language we'll keep up and I think a few new WhirlyGlobe-Maply apps may be written in Swift.

Dark Sky for Android

They launched a few weeks ago, but we haven't talked about it yet (here).  Dark Sky for Android!

That's some weather.

Man, that was a lot of work.

Weather Apps Are Popular Apps

The service, the UI, the data, notifications, and the globe are the big pieces of Dark Sky.  We make the globe.

Dark Sky is really popular and has a particularly loyal following.  In just about any group I meet, there's a good percentage who use it regularly.  I'm not reticent about using that fact.

So Much Android So Little Time

The Android port took a while on my end.  I could have done a hacky version, but that wouldn't work for everyone else.  No, we had to port the toolkit in a way Android developers would find friendly.

Totally not a screenshot from Keynote.

The C++ core, which does the rendering and manages the low level objects is (will be) the same on iOS and Android.  But everything above that level had to be new.

Developers expect their toolkits to be familiar on the local platforms.  That means Swift interfaces and dispatch queues for iOS, Runnables and integer colors for Android.  And lots and lots of other things.  This takes time.

Back To Dark Sky

For Dark Sky Android we ported the parts they needed and filled out the underpinnings.  This was by far the biggest app yet released with WhirlyGlobe-Maply on Android.

That's some more weather.

Dark Sky launched on Android with a subscription model.  Apple totally thought of that first and recently announced a similar one.  I'd love to see that take off on both platforms.

In the mean time, go buy it!

Welcome to wetter.com!

I'm proud to welcome the German wetter.com iOS app to the WhirlyGlobe-Maply family.

The wetter.com app presents regional weather, including predictions, on a map.

Details, details, details

It's funny to celebrate a flat map when the toolkit does a globe.  But for a regional app, the globe doesn't make sense.  The flat map simplifies things for the user and lets us optimize the data transport.  All the good stuff we do on the globe works on the map.

The app itself shows current predictions, recent radar, and cloud cover.  As well as some other cool non-map related stuff like weather cams.

Are those labels on top of the weather?  Oh my!

Mobile hardware is really good these days.  Since we're no longer planning for the iPad2 we can do some really great OpenGL ES shader work.  If you zoom in close, you'll see some great spatial and temporal interpolation.

The Inevitable Marketing Push

There are a lot of regional weather apps for iOS and Android.  Not so much in the United States where almost all the data comes from NOAA.

In the rest of the world weather data tends to be less free and more complicated.  Add to that language and local preference and you get a lot of interesting, distinct regional weather apps.  If you make one of those and want to upgrade your graphics, let's talk!

Android Support Contract

The Android version of WhirlyGlobe-Maply is coming along really well.  So well that we're ready to introduce a support contract.

Support is a tricky proposition.  Like any product, we're betting we'll bring in more than it costs to make.  In this case, that means the cost of fixing bugs.

How Does Support Work?

It's pretty basic.  You ask questions and we answer them.  You find bugs and we fix them.  Oh and you pay money.  That's important.

We've had the iOS support program going for more than a year now and I like it!  It's helped move a number of projects forward.  Users feel free to ask deep questions, get stuck less, and we get a sense of what's hard and what's not.  Oh, and we spend some of that money on boring features.

You can communicate with us via Slack or Github Issues or just email directly if you're being all stealthy.

Shut Up and Take My Money

Android support for WhirlyGlobe-Maply is $1200 (USD) per year.  For comparison, iOS support is $850.  Yeah, Android is more money.  We're totally 100% behind the Android version, but it is just more work.

I've been secretly selling the Android Support Contract for months now and it's going well.  Get yours while the offer lasts!  [It'll last a long time.]

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.

Integration with AerisWeather

We're delighted to announce integration with AerisWeather and the WhirlyGlobe-Maply mobile toolkit.

Florida: A reliable source of interesting weather

AerisWeather makes a variety of weather related products, like radar and satellite overlays.  We've done some simple integration to make those easier to use.

A Little Background

If you're coming from the AerisWeather site, you probably don't know who we (mousebird consulting inc) are.  We do high performance mobile data display.

Globe & Map

We make the WhirlyGlobe-Maply open source geospatial toolkit for iOS and Android.  It's a mobile first SDK used in a variety of weather, aerospace, map, and education apps.  It's easy to integrate, free to use, and imposes no extra costs on your app.

What We Did with AerisWeather

Our toolkit already supported a wide variety of weather and aviation apps so there was nothing difficult to add.  We just made it easier to fetch AerisWeather data layers.

There are a few new MaplyAeris objects in the toolkit.  These take your AerisWeather key, interrogate the available layers and set up the necessary WG-Maply objects.

There's a nice tutorial for iOS, so go check that out.  Ideally, use your own AerisWeather key.  Ours is just the boring demo account.

What's Next?

Our technology is used in some really ambitious weather apps.  We'd love to move a few of those techniques over to a broader base.

AerisWeater Weather Satellite Layer

AerisWeather layers are nice, but they're pure visual, like you'd use in a web browser.  Mobile devices are smarter and we know how to feed them better data.

So here's the deal.  If you're an AerisWeather user on mobile we've made it easier to use those layers in our toolkit.  That's great, but if you'd like to make it faster, smaller, and prettier, let's see what we can do together.

International Space Apps Challenge

This weekend I'm participating in the International Space Apps Challenge.  I'm going to build an app I've been thinking about for years, but has no commercial viability whatsoever.

That's right, it's a NASA earth data set browser.  Obviously, just a subset of earth data.  Like, the stuff that's easy to access.

Global Imagery Browser Service

NASA provides a really nice back end for accessing some of their (near) real-time data sets for the earth.  You can get a fair bit of historical data too.  And they provide a really nice web interface.  Check out NASA WorldView.

There are only two problems with this otherwise awesome web app.  First, it's a web app so mediocre on mobile devices.  Second, it's not a globe.  Because globe.

Worldview for Mobile

And that's the goal for this weekend's hackathon:  A Worldview clone for iOS devices on a globe.  We won't call it that, obviously, but I do plan to borrow its configuration files.  Because open source.  And lazy.

Now you might say "The globe and the images and... that looks hard!"  Actually, no.  I make a toolkit that does all of that.  This is going to be an exercise in user interface and add ons.  I'll deal with the user interface and...

Other People

If anyone wants to join my team, you are welcome.  It's going to be an exercise in software engineering, I'm afraid.  I can't think of much that isn't software development here, but I'm open to ideas.

I'm going to concentrate on the main user interface for iPad and iPhone.  I can think of a few other features that might be very cool and (best of all) largely separate.

• Star field:  The toolkit has one, but I've never verified that it makes any sense.  You could make it look better, update it based on the time and verify that it's correct.
• Planets: We're using the AA+ toolkit for sun and moon positions.  You could add the planets.
• Sun & Moon: The existing sun and moon are there, but they could look better.  Phase of the moon would be cool.
• Satellites: All of the satellites that contribute data have predictable positions.  It'd be cool to see their locations at any given time and perhaps their tracks.
• Other data sets: Got other earth data sets you'd like to see?  Might be easy enough to add.

Anything you can think of is fair game too, of course.

The app itself will be released open source and, if we get something good, published to the app store after a little testing.

Map Features in WhirlyGlobe-Maply

I'm going to discuss map related features of the WhirlyGlobe-Maply toolkit. The SDK is an open source, mobile centric geospatial display toolkit. It’s used in a variety of weather, aviation, geography and map apps.

Two of the more prominent examples are Dark Sky, a weather app and National Geographic World Atlas, which is exactly what it sounds like.

NatGeo World Atlas & Dark Sky

The globe apps are best known, but WhirlyGlobe-Maply has huge support for traditional 2D map apps too.  We're going to talk about some of those features, but let's start with map apps in general and one in particular.

Map Apps

Mapping is one of the more popular categories in the app stores. Both Apple and Google have their own map offerings and toolkits, but they're poor if you have your own data? That’s where toolkits like WhirlyGlobe-Maply come in and we’ve built a number of features specifically for those sorts of apps.

One of the more capable map apps that uses the toolkit is Gaia GPS.

Fact: 30% of hiking app screenshots are Yosemite.

Gaia GPS displays a variety of image and vector based data sources. It’s popular among the backpacking and off roading communities.  It can work without a network and is very careful with battery.

Let’s move on to one of the key features for nearly every map app: Image Tiles.

Image Tiles

A basic feature required for map display is loading and rendering of image tiles. We’ve moved well beyond Web Map Service on mobile devices and we now expect tiles. This might be a Web Map Tile Service (WMTS), but is more likely to be a fixed quad tree of tiles like that coming from Google Maps or OpenStreetMap.

Efficient image tile loading is a tricky problem. Mobile devices have network constraints and we want to make careful use of data caching. WG-Maply can handle this for both globe and map, but there’s an interesting variant for the map case.

In the example we’re loading three levels of tiles based on the current window. We start with an extremely low resolution, then overlay that with slightly higher resolution and finally toss in the proper resolution. It gives the user something to look at while the system loads the good stuff.

Tricks like these are important to efficient map display on mobile, but let’s take a quick detour through some really basic functionality.

Vectors, Labels and Markers

Any credible map toolkit should be able to display some basic features and WhirlyGlobe-Maply is no exception. These include vectors for areal and linear features, labels for points and of course markers.

All very simple to us.  Vectors, for example can be consumed from a variety of data sources, like GeoJSON or (ESRI Shapefile). Labels and markers are 2D features and can interact through an adaptive layout engine.  All of them provide selection feedback too.

It’s what the developers do with these features that gets interesting. That leads us to a complex modern feature: vector tiles.

Vector Tiles

Mapbox has popularized vector tiles with their OpenStreetMap data set. Theirs is a Google Protobuf based format, which is as complex as it sounds. The fundamental ideas are simpler.

Vector tiles are to image tiles as vectors are to images. They are just chopped up geometry representing what’s in each map tile. You can use them much more flexibly than images.

A very custom example of vector tiles.

Believe it or not, National Geographic World Atlas uses vector tiles hosted by Mapbox.  The rest of it is completely custom.  And, okay, it's technically a globe.  But if National Geographic doesn’t have some cartographic street cred, nothing does.

A more normal use of vector tiles.

The Gaia GPS developers use vector tiles they generate themselves to draw contour lines. The data is styled using Mapnik XML which is associated with the Mapnik map renderer.  Gaia GPS also has a street layer based on the same approach.

WhirlyGlobe-Maply has vector tile support down solid, but style support is still in flux and likely to be for a while. We can support older style formats like Mapnik XML and developers can always go off on their own. Newer formats like Mapbox GL Style Sheets are not fully supported yet. We also hope to add in Styled Layer Descriptor since it's an actual standard.

Vector Tiles are a bit trippy so let’s go back to some more basic map features.

Wide Vectors

Widened vectors are one of those obvious things that require some work to implement.  OpenGL ES has a basic line implementation, but it looks kind of... meh.  If you want lines that have smooth edges and neat little joins, you need something more.

WhirlyGlobe-Maply's implementation involves a custom OpenGL ES shader and a bit of math.  Line intersections are calculated on the fly (sort of) and width can be varied as needed.  Typically this just looks like constant width lines as the user moves in and out.

Look deep into my shader

Oh, and you can do dashed lines and other effects.  Wide vectors work both on the flat map and the globe, but they're primarily a map feature, just like the next one: clustering.

Marker Clustering

Clustering markers is a pretty simple idea. When you have a lot of markers on your map, it can look bad. Best to gather them up into groups and display the groups.

Simple enough, but our maps move so we have to do something more. As the user zooms in, the groups come apart and as zoom move out, the groups form. It’s tricky to implement, but looks quite nice.

In truth, clustering can be used on both the globe and the map even it’s nominally a map feature. Let’s look at something purely from the 2D map.

Infinite Scrolling

For certain types of map projections, the extreme west and east extents represent the same point (really, line). This means the user expects to move the map and have it wrap around.

Bonus question: What about wrapping top to bottom?

Infinite scrolling is simple in concept, but tricky to implement. The rendering isn’t bad, but when you add in feature selection and overlaid data it gets interesting. You know what else is interesting? Map projections.

Map Projections

The real test of a map toolkit is whether it handles explicit map projections. Actually, that’s not true. Plenty of map toolkits only work in a simple map projection, known as web mercator. But if you want to hold your head high in a room full of cartographers, you should have map projection support.

Does this projection make my poles look big?

Web mercator, shown here, is the most common projection in use on mobile. It has its problems, particularly near the poles. We can thank Google Maps’ dominance for this affront to cartography.  There's data in plenty of other projections and good reason to use them.

From left to right we’ve got:

• A data source in British National Grid overlaid on a web mercator map.
• The same data source overlaid on a British National Grid map. The web mercator data source is being reprojected.
• The same thing on a globe. Because it looks cool.

Though the vast majority of our users will always use web mercator, WhirlyGlobe-Maply can do more. It uses the Proj.4 coordinate system package internally and can handle a variety of useful map projections.

Conclusion

Map toolkits for mobile devices are hot right now. There are a number of excellent ones, though most are tied to specific data services like Apple or Google or are proprietary or both.  A few are open source, like WhirlyGlobe-Maply.

We’ve discussed some basic features and a few advanced ones we consider essential for map display on mobile. If you’re looking to build an app, we hope you’ll look beyond the proprietary services to something like WhirlyGlobe-Maply.

Special thanks to Stamen for the Stamen Watercolor map tiles, derived from OpenStreetMap data, used in many of these examples.