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.

Data Paging Layers

We load a lot of data sources in WhirlyGlobe-Maply, usually over the network.  Images are relatively easy, but how do you deal with things like vector tiles?

Ye olde vector tile example

That would be the job of the Paging Layer.

Quadtree Structured Data Paging

It all starts with a quadtree, a simple enough data structure.  It's here that we decide what's visible and what needs to be loaded.

Quadtree courtesy wikipedia

The quadtree for a data source can be in any proj.4 supported coordinate system, but most people use Spherical Mercator which is... what they use.  No judgement.

In deciding what to load, we start at the top node (0: 0,0), projecting a box into the view and then recursing if the box is visible.  It's not all that expensive, because quadtree.  But does get a bit tricky when using the globe or multiple coordinate systems.

For image layers, the toolkit has its own complex logic for loading image tiles and frames and handling failure and so on.  We provide similar logic for vector tiles, but for anything else, the logic is you.

Quad Paging Layer

You've got a data source, sqlite file full of points, let's say.  You want to turn them into markers, but there's too many to load at once.

Here's where the QuadPagingLayer (Android) or MaplyQuadPagingLayer (iOS) comes in.  Set up one of these babies with the coordinate system and extents of your data source and it'll figure out what to load.

You have to create the visible objects and that's where the PagingInterface (Android) and MaplyPagingDelegate (iOS) come in.  The paging layer calls you back when it's time to load a tile's worth of data.

Mt. St. Helens LIDAR

We love our threading in WhirlyGlobe-Maply and it was ever so hard to implement.  So use it.  Try a dispatch queue on iOS or use a worker thread on Android.  But don't hold up the paging layer.  It has other things to do.

When you make a visible object (marker, label, etc) tell the paging layer what you created with the addData (iOS, Android) method and call tileDidLoad (Android, iOS) when you're finished.

That's enough information for the paging layer to do the rest, which includes...

Cleanup on Node (12: 129,1304)

One of the trickier bits here is deciding when to delete something.  Luckily, you don't have to.

You told the paging layer what you created and it'll delete it for you.  There's even a callback if you really, really want to know it did that.

Paging Layers are Awesome

There it is, one of the key pieces of WhirlyGlobe-Maply: the paging layer.  We use it all over the place and if we don't support your data type, you'll use it too.

WhirlyGlobe-Maply 2.5 Release

Version 2.5 is out for both iOS and Android.

Location Tracking

You can get v2.5 off of the build page or from the master branch.  We'll update the master Podspec for Cocoapods soonish.

As usual, getting this version out the door took way too long.  But here it is and it's really good.

Big Changes in Version 2.5

Android.  Without a doubt.  We now have a good Android version with a bunch of deployed Android apps.  Millions of people are using WhirlyGlobe-Maply on Android.  Crazy, right?

We started doing automated builds.  I can't over stress how useful those have been.

Both iOS and Android have AutoTester apps; individual test cases presented in a list format.  Useful both for testing and user examples.

We upgraded to Swift 3.0 and kept pace with all the new Xcode versions and UIKit deprecations.

Ripped out AFNetworking and Boost.  Respect to both packages, but AFNetworking was interfering with users' own version and we eliminated Boost with C++11.

Vector (tiled and not) support got fancier with Styled Layer Descriptor format and the Simple Styles approach for building your own.

True 3D interaction got fancier in support of LIDAR.  There's an example in the AutoTester so check it out.

We added user location tracking and display.  A relatively simple change, but a popular one for map users.

Important but Boring Stuff

We made an enormous number of small fixes, efficiency improvements and minor functionality tweaks.  Also a lot of new tests for things that are (no longer) broken.  Here's a partial list in a boring format no one is going to look at.

Maps now have ViewState animations like the globe.  Feature selection is smarter with individual and group features.  Widened vectors is faster, smaller, and better.  We've got a 3D model builder for things like airstrips.  Elevation support is better and more flexible.  Stars and atmosphere work better.  Vector tiles kept up with new versions and added more style options.  Particle systems work better.  Internal coordinates are now double everywhere for getting really close to things.  3D support includes the ability to "grab" objects via the IntersectionManager.  Removed Mapbox GL Style Sheet support and then put it back.  Single level loading works on the globe now for both vector and image layers.  Screen Label layout works correctly for all modes.  Great circles work in 2D across the date line.  And much, much more.

What's Next

We're going to make some internal changes to the source tree, like unify the Android and iOS branches.  Then we'll move to git-flow methodology to hopefully speed up minor releases.

In terms of functionality, I've been rolling out statements of intent for things like Windows, True 3D support, MapKit, and Mapbox support.  We've also got the Imagery Pro toolkit for weather apps and another one in the pipeline.  Much of this requires money, so let me know if you have some.

Windows? Really?

We recently put together an estimate for a Windows 10 port.  And you may be thinking to yourself... WHY?

The Surface Pro 4?  Maybe?  Dunno.  Sure looks cool.

It's not the phone.  Oh my no, not the phone.  It's about the Surface.

Delicious Schadenfreude

If you were working during the 90's or early 00's Microsoft's diminished circumstances are amusing.  Unless you work for Microsoft, I guess.  I made a living writing Windows software back then and I loved the development environment.

But watching Microsoft face plant in the mobile market has been glorious.  Truly.  Undeniably.  Glorious.

Back to the Point

Ignoring the Windows Phone (and who doesn't?).  Okay, okay, no more cheap shots.

Ignoring the Windows Phone, the Surface is kind of cool.  MS has typically muddled the lineup and the naming,  but it's settled down to a beefy line of devices running Windows 10.

Now that the WhirlyGlobe-Maply Android version is solid, we can start thinking about another port.  How hard would Windows be?

Porting to Windows 10

First, a quick review of the Android port.  WhirlyGlobe-Maply has a chewy C++ core which we ported over and then coated in a Java shell.  All the rendering and data management is in C++.  The networking, threading, and interface is in Java.  It was painful, but the results are fast and easy to use.

On Windows, we'd follow a similar path.  The C++ core goes first, then a C# interface on top.  Interfacing C++ to C# is easier than the NDK on Java (it's a low bar).  That just leaves the graphics API.

We use OpenGL ES on Android and iOS, but Windows uses DirectX.  Google makes the ANGLE library which should do the trick.  If not, we'll have to fall back to new shaders and new graphics code.

Who Wants This?

Microsoft is really good at selling Surfaces to big companies.  Airlines and aircraft manufacturers are big companies.  A lot of our customers are in those industries.  Connect the dots.

This is by no means a sure thing.  We've worked up the estimate and sent it out to a few people, but it's not cheap.  Consider this notice that we're willing to do a Windows port if you've got the cash.

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.

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.

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.

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.

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 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.

We're Still Here

One of my competitors, Nutiteq just got bought by a partner company, CartoDB.  This is cause for some reflection.

Did you know WhirlyGlobe-Maply recently turned five?  That's right, I wrote the first of it in the winter of 2011.  Since then it's grown to more than 100,000 lines on two mobile platforms.

The 2 and the 3 D

The SDK is now a full time job for me and a part time job for a number of excellent contractors.  It's used in a wide variety really great apps and burns battery of tens of millions of devices.

So how did we get here?

Business and the Plans Thereof

I designed the SDK to be open source from the first.  This means cheap marketing which we parlay into contracting dollars.  It's a plan that's worked well, but it does have some drawbacks.

I'm excellent at tracking down new customers, but I'm awful at making third party deals.  Those are complex and require real business development, which is time consuming.  So we focus on the users and ignore the BizDev.  It does make us independent.

About Nutiteq

I'm sure reassuring emails are going out to Nutiteq customers right now.  It's going to be fine going forward, not to worry.  And it is a great move.  I commend CartoDB for their acquisition.

But if you're using Nutiteq's mobile SDK's you've got to be worried.  CartoDB is a venture backed company and they have plans they must execute.  Do you think those plans include your SDK license?

Switching to WhirlyGlobe-Maply

The danger with open source is that it won't do enough of what you want.  We're way past that point with WhirlyGlobe-Maply.  It's time to consider switching.

Our SDK is fantastic on iOS and has come along nicely on Android.  If you're a nervous Nutiteq customer, take a look.  You'll be pleasantly surprised.

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 Beta #8

The latest beta (#8) of 2.4 is available.

You have no chance to survive make your time.

You can get this one of three ways.

• The binary release can be gotten there.
• Cocoapods can be had directly from this URL or with the tag v2.4_beta8
• You can just use the repo with the tag v2.4_beta8

That's just the framework.  I'll put together the test app and its data when the release is ready.

"Did I miss betas number 1 through 7?" you may be thinking.  Yeah, pretty much.  I made them for clients, but haven't been aggressively pushing them on users.

What's New In Beta #8

Well, it's all new to 2.4, so go check out the announcement post.

I am repeating myself, yes.

The pretty stuff is pretty, but the stability of 2.4 is really profound.  We've been integrating with a number of high traffic apps and have cleared up a lot of edge, corner, and middle cases.  This is a great release.

How Many More Betas

Probably just the one more beta.  Things are nicely stable and I've got a pretty short list of bugs I want to fix.  

After that, it's WhirlyGlobe-Maply 2.4.1 which... okay I'm already working on.

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.