CartoType: Maply Mobile Renderer

Here's the short version, I've made a deal with Graham Asher at CartoType.  We're going to use the Maply renderer to speed up CartoType's map rendering.

Let's start with the basics.  What is CartoType?

CartoType

CartoType is a map rendering and routing package for iOS, Android, Windows, and other platforms.  It's largely implemented in C++ and it's used in a bunch of mobile apps.

What I really like about it is precision.  Label layout, in particular, is gorgeous.  Even the buildings and roads have a very pleasant, thoughtful, look to them.  It's also focused on offline maps, which is an underserved area, I think.

On to the details.  What are we doing?

Maply Mobile Renderer

We're interfacing CartoType to Maply using the CartoType API.  And the Maply API, obviously.

Here's how we're going to approach the development.  The first two phases will make tiled image maps work better and the third will focus on vector maps.

Phase 1: Image Tiles

This work duplicates what some of our clients have already done.  We're going to use the CartoType renderer for map tiles and hand them over to Maply.  It will look a bit like this.

CartoType Denmark

That's a snapshot from the test app, so obviously we're part way there.  What remains is to interface the two packages a little more tightly.  We can render things in the right size, deal with seams, make the label replication a little smarter and improve the caching system.

Phase 2: Image Tiles + Labels

Labels are one of the biggest problems with image based maps. When you rotate, the labels don't.  When you zoom in the labels get blurry.  We can fix that.

CartoType Denmark

In this phase we rip the labels off of the underlying map tiles and render them separately.  Maply has a rudimentary label layout module which we'll make use of.  It won't be as sophisticated as CartoType's current support, but it's adequate.

This phase will produce something people can really use, I think.

Phase 3: Vector Maps

Obviously the real goal is fully vector based rendering.  We'll support everything that Maply does that CartoType does as well.  That means labels, roads, polygons, dashed lines, and so on.

Maply Brazil

Translating these concepts into Maply will be easy in some cases, like roads, and hard in others, like label layout.  Most of the vector support exists in Maply and we'll be making use of custom shaders and textures and the new road widening capabilities.

For labels, we'll use a combination of the CartoType font rendering system and Maply's dynamic texture management.  It should be nice and fast.

Motivation & The Future

I'd run into CartoType in a number of user and client accounts.  Sometimes they had to decide if they wanted speed with Maply or precision with CartoType.  I found myself asking "Why not both?"  So here we are.

Something that interests me is label layout in a dynamic map.  It can never be as good as for a static map, but it can be much better than we do now.  I'm excited to try out some ideas and see how far we can take it.

I'm committed to keeping WhirlyGlobe-Maply open source, but I intend to build on the platform for commercial offerings.  This is a standard approach to commercial open source and I've planned to do it all along.  The Maply Mobile Renderer should be the first offering, but it won't be the last.

LocationTech Geneva Talk

I'm giving a talk in Geneva today Entitled "Open Source Geospatil and Maps on Mobile Devices."  It's an overview of what you can do with WhirlyGlobe-Maply and the sorts of apps people build for mobile devices.

As promised the slides can be found here.

Tomorrow I'm head to State Of The Map - EU in GermanyTomorrow I'm head to State Of The Map - EU in Germany. I've got a table so drop on by if you're there.

Metal & WhirlyGlobe-Maply

I'm sure I've got users who aren't glued to the WWDC announcements this week.  But then they're not sending me email.  So let's talk Metal.

Courtesy wikipedia, CC by 3.0

Metal is Apple's replacement for OpenGL ES, just to oversimplify it.  Am I going to support it?  I'm thinking about it.

Problems With OpenGL ES

If you're not neck deep in OpenGL ES, you might not really get what this is about.  I am.  It's what you people pay me to do.  Those of you that are paying me, anyway.

Ever written any OpenGL ES code?  It's pretty annoying.  You're setting things up all over the damn place and then carefully tearing them down again.  If you get it right, it's fine.  If you don't... well OpenGL has a million ways to display nothing and you just found another one.

Will Metal fix that?  Eh, probably not, but it will help with the set up and tear down problem.

OpenGL ES also has several mechanisms for moving memory around.  But it's memory... can't we just... move it around?  We can and there are extensions to make that easier.

In Support of Metal

Extension abuse is sort of the problem.  A lot of the fast paths through OpenGL are extensions and they're kinda goofy.  Even worse, OpenGL ES is by no means easy to use and it still has some cruft from the 1.0 days.  Moreover, it's diverged from the way hardware works.  Again.

If you look at the Metal docs, you can see the outline of how experienced developers use OpenGL ES, 2.0 or later.  It just all makes sense... if you do this stuff for a living.  It's about talking to the hardware in a way it expects compatible with how we actually work.

So I'm going to support it?  Maybe.

In Not So Much Support of Metal

This is about as far from a standard as you can get and no one is going to stop supporting OpenGL ES.  Because Android.

I've spent a while porting to Android.  Quite a while.  The OpenGL ES support there is.... fine.  I've had to turn off some of my favorite extensions, but it's okay, I was expecting that.  <sigh>  But this code isn't going to go away, I'm still going to support OpenGL ES indefinitely.  So will the game engines.

Metal is obviously something of an experiment.  Apple doesn't know how this is going to work out and neither do I.  OpenGL, for its flaws, has survived its imminent demise before.  I wouldn't bet on Apple.

So Will I or Won't I?

For WhirlyGlobe-Maply rendering isn't the hard part.  It's data management.  Getting all those vertices and texels into the right places is the tricky bit.  That doesn't change with Metal.  It's still the same logic, threading, and debugging.

So sure, I'd be happy to replace OpenGL ES with Metal.  And then I might turn around and port to DirectX, assuming Microsoft can ever get any mobile market share.

Here's one thing I will be doing.  I'll be discussing it with my performance minded clients and putting together estimates.  I think the chance is quite high.

Maply Android Preview

I've been hard at work on Maply for Android.  It's come along nicely and now there's something to show.

I'm not tired of that dorky Android icon yet, but that day will come.

Where to Get It

The neat thing about Android is you can install whatever you like on your device.  As an iOS developer that feels incredibly illicit.  So here's the MaplyTester app.  It shows off image and vector tile paging.

The source code is checked in to the WhirlyGlobe-Maply tree under the develop_3_0 branch.  There's a MaplyAndroidTester app that uses the Maply library.  If you're an Android developer this probably makes sense to you.  If you're not, I'd hold off.  I'm not ready to support non-experts yet.

Documentation for Maply Android is also up there.

What's it Do?

You notice I'm just calling it Maply?  It doesn't do WhirlyGlobe.  Yet.  Won't be hard to turn that on, but that's going to be client driven.

Image maps are so pretty... and also much simpler.

The test app I put up makes use of vector tiles and image basemaps.  The core rendering engine is working, as is much of the high level interface.  This is the WhirlyGlobe-Maply 2.3 engine so it's got a lot of the newer, trickier stuff.  It isn't all exposed yet, though.  That will come.

I'm happy with the state it's in.  The rendering loop could use a bit of work, the gestures need some help, and the vector fetching could use some love.  But overall, it's in decent shape.

Can you crash it?  Of course you can.  If you're looking for the easy way, just switch between display modes real quick.  The threading cleanup is still buggy.  But that's not the point... the point is...

Android Development is Open For Business

Thanks to my initial client (who would like to remain nameless) the hard part is done.  Maply works on Android, WhirlyGlobe can follow and you can get it for cheap(ish).  Trust me, this was a lot of work, whatever you need isn't going to be as big.

If you've got an app that needs a fast, cross platform map toolkit, let's talk.  You want the globe?  It's doable, let's talk.  Mapnik vector tiles?  Sure, we can port that over.  It's all possible now.