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.

Styled Layer Descriptor and Metro Extracts

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

Belfast, it seems.

Let's start with the data.

Metro Extracts

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

Courtesy Mapzen

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

Styled Layer Descriptor

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

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

Example & Tutorial

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

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

Up Next

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

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

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.

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.