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.

CartoType GL

CartoType GL is the turbo-charged upgrade to the CartoType library.  We took the super fast mobile rendering from Maply and stitched it into the CartoType renderer.  

Closeup from London app

You can use the CartoType data formats, styling sheets and conversion tools, but get ultra-fast OpenGL ES rendering on mobile devices.  Why would you want that?  Well, CartoType is incredibly good at offline map display and routing.  Yes, offline routing.  And it’s really compact.

We announced this one a while ago and now it’s close to release!  First up is the iOS version, available very, very soon.  Then we’ll do Android and then the other platforms.  Contact sales@cartotype.com if you’re interested.

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.