Wednesday, July 9, 2014

WhirlyGlobe-Maply 2.3 Beta 2

It's finally time to release WhirlyGlobe-Maply 2.3 into the wild.  I've been using it for some time and, sure, you could have always switched to the develop branch, but hey, release!

Courtesy Gravitystorm

Thanks go out to the contributors on this version.  This one's seen the biggest set of contributions from people other than me.

Let's get to it.

Where to Get WhirlyGlobe-Maply 2.3


For the source distribution, head over to github, clone the repository and switch to the develop_2_3 branch.  Be sure to update your submodules.

You can also download the binary distribution.

Documentation for 2.3 can be found here.

What's new In WhirlyGlobe-Maply 2.3


It's a huge list of new features.  I'll be working my way through blog posts for the next several weeks.  For now, here's the short version grouped for my own amusement.

Housekeeping


Here's the stuff that doesn't fit well into another theme.
  • 64 bit device support.
  • Xcode 5.1 is supported.
  • OpenGL ES 3.0 is supported.
  • Tessellation bugs are now fixed.
  • EAC/ETC2 texture compression was added.
  • High resolution jiggliness was fixed in images, vectors, annotations and screen objects
  • Resources submodule is smaller
  • Background CPU usage is much lower for paging layers.
  • Screen shapshots are now possible
  • MaplyTexture was added for explicit texture management
  • Animation is available through the startChanges/endChanges methods.

Maps / Maply


How about features that are useful in flat maps?  This version saw a lot of improvements to the Maply side of things.  It's quite the credible map toolkit now. 
  • Wrapping across the date line, for data display, selection, gestures, and overlay.
  • Vector tile support
  • Mapnik vector tile support
  • New gestures for 2D
  • Screen importance logic is short circuited (e.g. faster) for 2D

Gestures & Feedback


This version saw a host of new gestures, particularly for 2D and improvements in the feedback methods for delegates.
  • Heading control
  • North up panning in the globe
  • Double tap, two finger tap, tap hold and drag.
  • Location animation control via delegate.
  • Feedback with the didStartMoving/didStopMoving/willStoopMoving methods
  • Screen to geo and geo to screen calculations
  • Viewing bounds calculations for setting height to show a set of features
  • MaplyAnnotation added.
    • These are nice annotations based on the SMCalloutView library

Quadtree Paging Layers


The paging layers, both for general features and for imagery saw a ton of changes.  These are the things that handle vector tile and image based paging.

  • Single and multi-level loading.
    • This means you don't have to always load from level 0
  • Animation in quad image layer and the multiplex loader.  Think weather.
  • Changing color, enabling/disabling, reset/reload, changing tile sources.
  • Switched to AFNetworking, handles lots of requests better.
  • Broke the remote source from the tile info.
  • WMS improvements
  • Background overhead is much lower.

Wrapup


This was a big release.  Hard to believe I'm also working on 3.0 for Android.  At some point those will be merged, but there's no real hurry for the iOS users.

I'd like to do more documentation for this version.  I've got someone working on getting started examples for a globe and map.  We'll see if those help.

Anyway, 2.3 is pretty well tested.  I'll put it out there for a week or so to see what turns up and then make it official.

Next up, more blog posts describing what's in it.

Tuesday, July 8, 2014

Thunderforest Lighting Vector Tiles

Let's take a look at another set of Mapnik vector tiles, this time from Gravitystorm.  The data set covers London and is focused heavily on transit.  Andy Allan has been doing this sort of thing for years and has a great feel for OpenStreetMap data.



Thoughts on the Gravitystorm Transit Layer


First off, it looks great.  The transit features pop out and I'd love to see his other styles running in Maply as well.  Andy is putting a lot of data into his tiles and for mobile devices I might suggest backing off on that a bit.  Adding another level might work too.


On a recent mobile device the rendering is fine, though the loading is slower than I'd like.  On older devices I could see thinning the data out a bit or just sticking with image tiles if that's easiest.

There's room for improvement, but given that these weren't designed for mobile devices (!) it's amazing how well they work.  The styles come through nice and sharp.  For a customer I might tweak the line widths and such, but overall it's lovely.

How About Maply?


Of course, I do these things to test WhirlyGlobe-Maply.  The vector tiles were delivered as an MBTiles file rather than being paged from a server.  Now the toolkit supports that.  I found a few color related bugs, a few parsing problems, and some features in the Mapnik XML I wasn't supporting correctly.  Those are fixed, but I do see a few others things that could be done.


Overall I'm pleased with how Maply renders these tiles.  You could build a credible map app with the Gravitystorm vector tiles on iOS using Maply.  Perhaps you'd like to give it a try.  :-)

Mapnik vector tile support is in WhirlyGlobe-Maply 2.3.

Monday, July 7, 2014

Taking Mapbox Vectors for a Spin

I've been working on the vector tile support in Maply for months now, including Mapnik vector tiles.  The biggest proponent of Mapnik style vector tiles is Mapbox.  So let's look at Mapbox's Mapnik Vector Tiles, shall we?


Thoughts on MapBox's Vector Tiles


They're nice.  The servers are fast and the content is good.  Given that these aren't explicitly designed for mobile use, they work pretty well anyway.


If it were me, I'd add another couple of levels in dense areas.  Newer hardware can power through the level 14 tiles, but it tends to strain older devices.

Can I Use These?


No.  Mapbox hasn't released the tiles and there's no way to pay for them.  You shouldn't make an app with them.  Don't be that guy.  No one likes that guy.


Nonetheless, they work great in Maply and if you were a big enough customer I'm sure you could work something out with Mapbox.

Why did I bother?  Believe it or not, this isn't the first set of Mapnik vector tiles I've supported.

Maply Vector Tile Support


Other people are doing their own Mapnik vector tiles, standing up their own servers, and generally doing their own thing.  Some of them are my customers and some of them have even shipped apps.



The Maply support for vector maps is in good shape, but there are a few things I'd like to improve.  Labels could be better, particularly the font twiddling and layout modes and there are some bugs worth tracking down.

Mapnik vector tile paging is in WhirlyGlobe-Maply 2.3.

Tuesday, July 1, 2014

Ericsson Texture Compression

I recently added support for the new OpenGL ES 3.0 compressed texture formats, ETC2 and EAC.

Now with Animated GIF technology.  2002 here we come!

Compressed Textures?


Compressed textures have been in OpenGL ES on iOS for quite a while.  What they let you do is represent a texture in less memory.  The hardware will do a little bit of math as it fetches a pixel, giving you a real RGBA value in the shader.

This is nice if you're short on memory when doing animation and we animate a lot when doing weather.

Sure, I wanted to animate this one too.  You're welcome.

Before 3.0, iOS hardware supported PVRTC through an extension.  That's a fine format, but it suffers from one big flaw:  You can't load just a piece of a PVRTC texture, you have to load the whole thing.  WhirlyGlobe-Maply makes heavy use of dynamic textures, so that was a non-starter.

The ETC2/EAC Compressed Formats


PVRTC is clever, but clever can be overrated.  The new formats, ETC2 and EAC are less clever, but their support is much deeper.  Most importantly, they support glTexSubImage2d().

I rely on that command for the dynamic texture atlases. Since textures can come in at any time, via map tiles or font glyphs, I can't pre-construct the atlases; I have to do it dynamically.  PVRTC didn't support modifications to textures.  ETC2 and EAC do.

ETC2 / EAC Display Support


You'll find support for 7 of the compressed formats in WG-Maply 2.3.  The first three are immediately useful, the rest are a bit obscure.

  • MaplyImageETC2RGB8 - Nominally 8 bits per channel RGB.  This is compressed roughly 8:1 from the naive 32 bit RGB.
  • MaplyImageETC2RGBA8 - RGBA, 8 bits per channel.  Compressed 4:1 from naive 32 bit RGBA.
  • MaplyImageETC2RGBPA8 - RGB plus a single bit Alpha.
  • MaplyImageEACR11 - Single channel, nominally 16 bits.
  • MaplyImageEACR11S - Signed single channel.
  • MaplyImageEACRG11 - Two channel, nominally 16 bits.
  • MaplyImageEACRG11S - Two channel, signed.
The first one, RGB8, is useful for your full color basemap and the second one, RGBA8, is decent for full color transparent overlays.  The rest have their uses, but get weirder.

And I should Care Because....?


Let's do a little math.  WG-Maply likes to allocate 2048x2048 texel maps for its dynamic texture atlases.  For an RGBA texture, that takes up 16MB.  Now there are simple textures formats that just chop the lower bits out.  For some data sets that'll work in 8MB.  With ETC2 RGB8 you can represent the same data in 2MB.  That's either 8:1 or 4:1 depending on the data set and ETC2 looks much better.

The new texture formats are part of the OpenGL ES 3.0 standard.  Only a few devices support 3.0 at the moment, but that list is getting bigger every day.  For some apps, it's a huge win.

Great, so How Do I Serve These?


Mention anything other than JPG or PNG to server developers and they look at you with a mix of loathing and fear.  You can't really compress these efficiently on the client side, so the server's got to serve them.

There's a free program called etcpack that will do the conversion for you.  I've run some tests myself (at the behest of a client) and found conversion to ETC2 RGB8 and RGBA8 pretty easy.  You still have to store the images, of course, but disk is cheap.  Right?

Conclusion


For certain kinds of apps ETC2 and EAC are a huge win.  If you use a lot of image overlays and you find yourself low on memory, they're worth a look.  Full support is in WhirlyGlobe-Maply 2.3.

Thursday, June 12, 2014

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.

Wednesday, June 11, 2014

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.

Tuesday, June 3, 2014

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.