|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.
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.
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.
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.