Works pretty well, actually. The data set I'm using there is in Spherical Mercator to match the map tiles coming from MapBox. There's one 32x32 sample tile for each image and the data is stored locally in an sqlite database. More about the tools later.
Component Support
If the elevation data is stored in a sqlite database, we obviously have to get it out. We use a MaplyElevationDatabase to do that. That object implements the MaplyElevationSourceDelegate protocol, which you can use to query individual tiles.
You can also implement your own elevation database, perhaps one which fetches data remotely. Just implement the MaplyElevationSourceDelegate protocol. Don't worry, you're called in another thread so go ahead and block on the network calls.
We hand the elevation database over to a MaplyBaseViewController, which is the parent of both globe and map view controllers. Though that object doesn't use it, it does pass it on to layers that care about elevation. At present, that's just the MaplyQuadImageTilesLayer, which now handles all of the local and remote image tile paging.
Here's what that all looks like, from the WhirlyGlobeComponentTester app.
Here's what that all looks like, from the WhirlyGlobeComponentTester app.
How active could that volcano be? |
Elevation Pyramid Generator
Getting terrain support in the toolkit wasn't actually all that difficult. I know kind of a lot about this stuff. No, the real problem is how to generate the data.
From past experience I knew I couldn't just throw this functionality out there and expect users to pick it up. I needed to provide a tool.
This one's just gratuitious |
The Fine Print
It's cool and it works! But there are some caveats.
Elevation data adds complexity. We can no longer predict where the surface of the earth is at any given point and, even worse, it moves between levels of detail. That means features are hard to place.
The settings panel. Titillating! |
You can do vectors, labels, markers, and all that good stuff in this mode, but they won't work well. Markers and labels might, actually, but vectors certainly won't. Why not? Because topology.
We've got a different version of the surface for each level of detail, and there are 14 levels in the example. That means whatever you stick on top of the earth needs to move around as those levels of detail swap in and out. It's not impossible, but it does require some work. Work that, frankly, a client can pay for.
The Conclusion
It works pretty well and it's in the develop branch on github. Go have fun. I'm sure more features will be forthcoming, but I'm going to see what clients want to do.
No comments:
Post a Comment