App Store Mention: Santa's Big Helper

The whole point of doing WhirlyGlobe is for developers to use it.  I had in my mind a couple of types of developers who might find it useful:  People who just want to toss some info up on the globe and hard core globe centric app developers.

They're both really interesting groups, but for very different reasons.

Hard Core Interactive Globes

I wasn't expecting to attract this group right off the bat.  I have, though, and that's both good and bad.  On the good side, they push really hard for new features.  On the bad side, they push really hard for new features.  It's great to see that WhirlyGlobe is useful to them, but I'm not as responsive as I'd like to be.

Mobile development is an interesting place full of really excited people trying out lots of great ideas.  Which is to say, the failure rate is pretty high.  I've worked with a number of projects that have collapsed under the weight of their own ambitions.  Others have just slowed considerably after the initial burst of excitement.  In software engineering parlance that's called "normal".

One of the big issues that confounds these projects is data collection and manipulation.

GIS Is Harder Than You Think

Getting the right data for your project is much more difficult than people realize.  Any number of projects I'm involved with have tripped over these issues.  I warn, but I'm not doing a great job at it.

Most developers are vaguely aware of the Blue Marble imagery data set so I don't have to point it out.   The next place I'll send them is to the Natural Earth web site for vector data.  After that it gets tricky.  If you want something specific you really have to do some data processing.

You can't really do that data processing on OSX.  There are some open source tools, but they're not all that user friendly.  The major tools vendor hasn't ported to the mac and why on earth would they?  That means I can't even reliably get a client to look at their own data.  They really need a PC or they need to be pretty savvy to use the open source stuff.  Even then they're going to have to outsource the data processing.

A lot of projects bog down here.  That's why it's nice to work with simpler projects too.  These are developers who just want to bring up a globe and toss a few geolocated objects on top of it.  One of them recently shipped.

Santa's Big Helper

That's just what the developer is doing in Santa's Big Helper.  He's bringing up a globe with one of the Blue Marble composites overlaid and then dropping a few Markers on top.

These projects are a great test of how usable WhirlyGlobe is on the less complex end of things.  Obviously Santa's Big Helper is not a simple app, but the globe is a relatively straightforward application of my toolkit.

I could use more documentation, I think, but these projects are able to proceed and that makes me happy.

There are a number of interesting things they did here, actually.  There are views underlaid and overlaid, including transparency.  They look really good.

Surprisingly, the frame rate is still quite good.  I obsess about performance because that's my thing so semi-transparent overlays are something I avoid.  I may be overthinking it.

That's cool and it's great to see that WhirlyGlobe is working on the simpler end of things.  That's what it was designed to do and there are a few features in the pipeline that'll help with this sort of project.

WhirlyGlobe Version 1.2

As for the actual 1.2 release, I'm still a few weeks away.  Here's how things are going.

• Particle systems are working and scaled correctly.  
• Markers are working, but I'm still scaling them.  If you just need a handful, you're good.  If you want to toss 2000 of them up there, wait a bit.
• The Texture Atlas Builder is up and running, as is texture ID translation.  I'm pretty happy with this one as it solves a lot of problems.
• The new Selection layer is up and running.  It really simplifies label and marker selection logic.
• There's a new test app I'm using for tracking down memory and resource problems.  It needs to test a few more features before it's complete.
• Lofted polygons haven't been integrated yet.  These are what WhirlyGraph uses.
• Render Data Caching is working, but not complete.  It's also a bit slower than I'd like.
• Bitmap font support for labels has not started.  I'm wavering on this one.  It's really the last unnecessary resource hog in WhirlyGlobe 1.1, but I would like to release soon.
• Gridlines may get postponed.  No one seems to be bugging me for them.

The source tree is actually in pretty good shape right now.  If you need one of the new features, just ping me to see how well it's working.

Image Pyramid Support: MapBox Tiles

I've been planning to add support for multi-resolution images, or image pyramids, for a while.  I'm still planning on it.

Image Pyramid

An image pyramid is pretty much what it sounds like.  You take a giant image, make a version at about half the resolution, put that somewhere, made another version at half that resolution and keep going.  You stop when you either get to 1 pixel or it just gets stupid, usually the latter.

Rather than storing a big image at each level, you tend to chop these suckers up into manageable pieces.  The definition of manageable changes depending on what you're up to.  For interactive 3D the chunks tend to be less than 1M pixels in a format conducive to fast drawing.  That size might be 256 x 256 pixels and the format is PVRTC for our purposes.

Another way of looking at an image pyramid is as a quad tree.  Each node would store a single image, ideally in your optimized format, ready to be loaded.  Or, and this where it gets fun, a node might be empty.  This lets you build a sparse image pyramid and save a lot of space.

Image pyramids are easy enough to build, but you have to do something with them.

Paging Image Data

There are different ways to page an image pyramid or similar structure.  If you're displaying the image in 2D, you tend to want everything in your window at one resolution.  When the user zooms in or out, you switch resolutions.  For 3D display, you tend to use the higher resolutions close up and lower resolutions in the distance.

For a globe, it gets weirder.  You want lower resolutions when you're farther away and higher resolutions when zoomed in.  And if the user spins the damn thing really fast... well you need to not go on a paging binge.  It's similar enough to 2D and 3D display, though, that you can borrow from those approaches.  The main question is where you're pulling the data from.

There are as many tiled multi-resolution image formats as their are clever idiots to make them.  I developed one myself back in the day.  There are many, many others.  To pick one, you really have to look at the technology you're targeting and think a little about marketing.

MapBox Tiles

For WhirlyGlobe, I'm planning to implement the MapBox Tiles (MBTiles) spec.  It's got a few things going for it.

MBTiles is being actively developed.  That means an ecosystem of applications producing it and users interested in plugging things together.  The folks behind it have a pretty good open source vibe too.

It's based on currently hot technology.  You store tiles in a sqlite3 database, which is pretty much ubiquitous these days.  It can also be streamed from a remote site.  2004 here we come!

MBTiles are stored pretty flexibly, so I can mess with them.  I need to stick PVRTC image data in there, rather than PNG or JPEG.  The difference in memory is pretty big and that's what we really care about.

MapBox makes user level tools to produce MBTiles, including an iPad app (TileMill).  Data production for GIS is a bitch, so this is promising.  The dots may not all connect, but it's a start.  [Edit:  Too lazy here in my description.  The iPad app displays maps produced by TileMill, which runs on the mac, among other places.  Getting all the tools together on one platform is a problem I have with clients all the time, so this is promising.]

WhirlyGlobe Issues & Schedule

Of course, there's always work to do.  Paging imagery also means paging terrain, or in my case, making it up on the fly.  I'm already doing that in the Spherical Earth Layer, but now I'm going to have to do it differently.

Multiple resolutions of terrain means multiple resolutions of data sitting on top of the terrain... possibly.  So it gets complicated.  What fun.

MapBox Tile support will be after WhirlyGlobe 1.2.  My guess at this point is early 2012.