Friday, June 21, 2013

Android Port: Begging for Money

I'm getting a lot of queries about an Android port.  Just to recap, I make the WhirlyGlobe-Maply toolkit, an open source 3D interactive globe and map display toolkit for iPad and iPhone.

Globe                            3D Map                         2D Map
Most of the development I do is incremental.  If I add, say, font based text rendering it doesn't cost all that much and one client can pay for it.  Everyone else gets the benefit and that's how open source works.

The Money


Some things are just too big for that model.  An Android port isn't like a feature request, it's big.  How big?  About $50k (USD).

Normally I'd approach this one of two ways:

  1. Do it myself.  I absorb the cost of lots of features no one really wants to pay for.
  2. Wait until a big client needs it.  Pretty likely, but could take a while.
This is just too big for the former.  Remember, I give this stuff away.  The latter will probably happen... eventually.

What if I could speed that up?

The Engineering


I've bid an Android port on several projects now and worked out the details.  Here's how it would go.

The core rendering modules of WhirlyGlobe-Maply are largely C++. We would be making heavy use of the NDK on Android to port the rendering engine.  

The first step would be to move more of the rendering modules into pure C++ on iOS. This has the virtue of being easily testable with the current toolkit.

The next step would be a direct port of the rendering engine modules to the Android NDK.  After that we would rewrite the threading and messaging logic in Java for Android as well as the various interface logic to go between Java and the rendering engine.

Lastly, we would rewrite the high level interface in Java. This would correspond to the Component level on iOS. These objects need to be native Java and function in ways Android developers expect, just as the Component on iOS is native Objective-C. 


The Appeal


A lot of companies are interested in an Android port of WhirlyGlobe-Maply.  Some are using the globe, but most want to do custom map display on both platforms.  Mine is probably the best open source toolkit for that and superior to a lot of the commercial solutions.

So, I'm talking to you guys here:
How much would you kick in for an Android port?

Drop me an email and let me know.  If I hit a certain threshold, I'll come back to you for details.

Monday, June 17, 2013

CartoDB Example

I whipped up a guest blog post over at the CartoDB blog.

France!
That's a simple app that queries country outlines from their spatial database service.  Lot of interesting possibilities there, go check it out.

Saturday, June 8, 2013

State Of The Map - San Francisco 2013

I'm giving a talk this year's at State Of The Map (US) in San Francisco.  This is unrelated to the fact that I live in San Francisco, but convenient nonetheless.

The Talk


It's all about vector display on iOS devices using OpenStreetMap data.  Scintillating.

The green is marijuana cultivation.
You can go grab the slides there.

The talk is based on my toolkit, WhirlyGlobe-Maply, unsurprisingly, and an app I built for fetching vector tiles from the US OpenStreetMap server and displaying them.

The App


The app, called osmmobilevectors, is on github and you can clone the repository, build it and put it on your own device.  I mean, you're set up to do that, right?  Of course you are.

Lots of interesting little bits and pieces went into the WhirlyGlobe-Maply toolkit to make this happen.  I'll break it down for all three of my loyal readers next week.

Friday, June 7, 2013

OpenStreetMap Vectors

I've got a talk tomorrow at the State Of the Map US conference in San Francisco.  It's about paging tiled vectors straight form the US OpenStreetMap server.

Naturally, there's new functionality in WhirlyGlobe-Maply to support this stuff.  Here's a teaser.

There are no clouds in California.  Be serious.

That's a base map overlaid with vector roads, which is one of the options I'll be talking about.

I'll put the talk up next week along with a deeper technical explanation.

Friday, May 17, 2013

GeoData Display for Mobile Devices with OpenGL ES


I gave a talk last night at the San Francisco Bay Area GeoMeetup.  This one was timed to coincide with Google I/O.

The talks were the 5 minute Ignite format and, just to be different, I went deep technical.  I pulled a couple algorithms out of WhirlyGlobe-Maply and explained them.  I like how it turned out.



The video has audio and, hey, it's short.

The slides, sans video, can be found here.

Wednesday, May 15, 2013

MapBox Earth

It's been a busy month for MapBox.  Their new OpenStreetMap editor launched, for one thing, and now they've published a pretty little app to show off their satellite data sets.

In English, yes.
Actual picture of the earth.  NASA photoshops out the labels.


It's WhirlyGlobe-Maply powering that app and, indeed, the whole thing is open source.

How It Happened


I approached MapBox about doing this one a few weeks ago.  It's basically advertising for me and it was really simple to write.  Take a look at the source code, it's just not that big.

Once I put the first version together, Justin@MapBox cleaned it up and generally made the UI elements work better.  That stuff takes more time than you realize.

Then we shipped it and now you can play with.

Future of MapBox Earth


The app's goals were to show off MapBox's lovely satellite data sets and advertise WhirlyGlobe-Maply.  I'd say we're good on both of those.  What's next depends on what people want to do with it.

Since the app itself is open source and the toolkit is open source... you can do whatever you like (within the constraints of an Apache 2.0 license).  Or you can pay me to do whatever you like, which is kind of how I make my living.

We'll see how that goes.  In the mean time there are other interesting things afoot with MapBox and mousebird consulting.

Thursday, May 2, 2013

route-me and Maply

I like route-me.  It's open source, it's been around a while, lots of people use it, and it works.  Heck, I used it on a project once.

For those in the dark, route-me is a free toolkit for displaying custom slippy maps with overlaid shape, marker and other features on iOS.

Anyway, I like route-me, which puts me in an awkward position.  I want to replace it.

Maply


I make an open source toolkit called WhirlyGlobe-Maply.  There are three ways you can use it.

3D Interactive Globe   -   Interactive 3D map with tilt   -   Interactive flat (2D) map

The WhirlyGlobe part is the globe, the Maply part is the other two.  I've done a bit with the interactive 3D map and it's a blast, but it's not what most people want to do.  They want a true flat map.

Okay, so great, I can do a flat map.  But why bother?  If you want Apple's data, you use MapKit, if you want Google's data you use their iOS API.  If you want your own data, you buy a commercial toolkit or you use route-me.  Do I really have anything to offer over route-me?

I do.  WhirlyGlobe-Maply is based on OpenGL ES.  My toolkit is in the same class of "stupid fast" as Apple's, Google's, and the commercial alternatives.  I can't beat them feature for feature, but then I don't have to.  Mine is open source.

That's a fun bit of self aggrandizement, but it really needs to lead somewhere.  I think it's only worth matching route-me's features if someone's paying.  There's money out there for this kind of thing and it's welcome to look me up.  And it did.

MapBox


The MapBox guys, Justin particularly, have their own route-me variant they call the MapBox iOS SDK.  It's really nice, with a lot of functionality filled in and tons of documentation and examples, things that open source projects often lack (cough).

Very cool, but route-me uses Quartz, the technology behind UIKit (kind of).  That's what you're supposed to do, but it's not as fast as the new Apple Maps.  They're obviously not using Quartz, they're using OpenGL ES.  Maply uses OpenGL ES so...

MapBox is paying me to jack up their version of route-me and stick Maply underneath.



route-me + Maply = What?


The idea is pretty simple.  Accelerate route-me's tile display with Maply, then see if we can do anything with annotations.  In theory it looks pretty good.  The initial experiment looks good too, but we've got a ways to go.

If everything goes well, the standard route-me app might be able to switch over seamlessly.  Your custom Quartz rendering will still be Quartz, but anything you represented in route-me tile sources and annotations could be handled by Maply.  Or not.  It's an experiment, we'll see.