Requirements
If you're going to work on WhirlyGlobe-Maply, you need an Apple Mac running OS X. And you will at least need Xcode 5.1 or better. You can run on the simulator without an account, but if you want to run on hardware (and you should), you may need an Apple developer account. Please discuss this with your professor first.
Though WG-Maply does have an Android version, it's not yet mature and I'm not willing to support students using it yet. Perhaps next year.
Possible projects
Here are a few projects that I think would be interesting for a computer science student with some exposure to mobile development. Most of these focus on open standards and some on open data.
These projects will go into the contributed area of the WG-Maply project. None of them require internal changes to the toolkit (a good thing) so they can sit outside the main library.
Keyhole Markup Language (KML)
KML has an interesting history. It's basically the internal format for Google Earth, but due to its ubiquity it's turned into something of an interchange standard. It's ill suited for this, but you'll find that happens a lot. Might as well roll with it.
This project would be adding KML support to WG-Maply. There are several parts to it.
- Read KML - There's an API, so that's not too bad. It's C++, though, so you need to know C++.
- Interpret KML - This is where the C++ comes into play. The API was written with Design Patterns very much in mind. It'll be less annoying if you've had some exposure to that (but it will still be annoying).
- Convert KML to WG-Maply concepts - The last bit isn't too bad. Convert their markers into WG-Maply markers and so on. The concepts don't map 1:1 which is what makes it interesting.
There are abundant KML examples out there for testing. We'll find you a few.
I'd recommend starting with the static KML data. If you're feeling ambitious, you can move on to the dynamic stuff.
Web Feature Service Support
WFS is one the OpenGeospatial Consortium (OGC) standards. It's for expressing features, by which they mean points, lines, polygons, that sort of thing. This is basically map data and can be overlaid on a map or globe in WG-Maply. Or both. Up to you, really. The project is to display WFS in WG-Maply.
Using WFS requires a server. I'll find you one or set up a GeoServer myself, if need be. Once you've got an end point to talk to, there are three parts to this:
- Form the query for what to fetch. This will be XML, but there are XML libraries for Objective C that work pretty well. This will take longer than you think it ought to.
- Parse the Geospatial Markup Language (GML) that comes back. I don't know of a good Objective-C parser for GML, but we'll look. In any case it's XML underneath, so you may need to interpret that.
- Convert the GML concepts into WG-Maply data structures.
The goal here would be to talk to a GeoServer and display the features it sends back for a certain area. For bonus points, hook this into the MaplyQuadPagingLayer. We use that for fetching data as we need it, rather than all at once.
MapCSS Support
Turning vector features into a readable map is an ongoing problem. There are lots of ways to do it, but most of them are at least a little complex. And for good reason, the problem is complex. But it would be nice to have some simpler alternatives.
Right now the most common way users style their maps in WG-Maply is with Mapnik XML. They usually produce this with CartoCSS in TileMill. There are other approaches supported by other tools, such as MapCSS.
The project is to implement a decent MapCSS parser in Objective-C (or at least a wrapper). Test it by displaying MapCSS styled maps in WG-Maply. This would pair nicely with the GeoPackage support below, but I wouldn't recommend taking on both.
TopoJSON Support
There are a couple of newish standards out there that went around (e.g. ignored) the traditional geospatial standards process. This makes them a little wonky in places, but also a lot easier to implement. The first one is GeoJSON, which is well supported in WG-Maply. The second is TopoJSON, which is not.
The goal of this project is to implement TopoJSON support. This is not as complex as the other projects, but is pretty valuable. Lots of people use these standards.
You'll need to parse the JSON itself, which is pretty easy on iOS. Then you'll need to reform the topology and turn it into MaplyVectorObjects to display in WG-Maply.
If you're feeling ambitious, write an editor. Since TopoJSON preserves topology, moving individual points around can be done without destroying the larger structures they're part of. If you do this, you'll also want to write the TopoJSON back out.
GeoPackage Support
Let's get back to the official standards. GeoPackage is a newer one from OGC that's meant to be used on mobile devices. I don't run into it much yet, so let's see if we can help it along.
GeoPackage is simpler than it sounds. It's based on SQLite which we use constantly on mobile devices and is well supported. GeoPackage encodes features (e.g. points, lines, polygons and so forth) and provides for spatial searches. That last bit is important on mobile devices, as we can only display so much at once.
The project is to support GeoPackage in WG-Maply. I'd recommend doing this in two steps:
- Support the vector features it encodes. You can use the Spatialite toolkit to read them, apparently.
- Make spatial queries in conjunction with the MaplyQuadPagingLayer. That's how we load only the data we need to keep from overloading the display.
There are GeoPackage samples out there and tools for looking at the contents. The goal would be to support as much as possible, with a minimum of getting the traditional point, linear, areal features displayed.
This project would pair nicely with the MapCSS project or you could try styling the data with Mapnik XML. Consider that the advanced part.
NASA Geospatial Imagery Browse Service
In an effort to make some of their data sets more accessible NASA has come up with GIBS. It's a service that converts a few timely data sets into tiled data sets, covering much of the earth. They provide simplified forms, such as Google's (and OpenStreetMap's) TMS. That makes it easier for dumber systems (like mine) to display the data.
Actually displaying one of their data sets is too easy. We already do that with the MaplyQuadImageTileLayer. This project is to make a browser for the GIBS data sets. That is, to show the user what is available and let them decide what to display.
In addition to the simple TMS end points, GIBS also provides Web Map Service support. This is a more complex standard (and how) with a lot more flexibility. It can tell you a lot more about what's actually available.
The project is to talk to the NASA GIBS service and build a browser for it using WG-Maply. This would consist of the following steps.
- Talk to the GIBS service using WMS. You'll need to make a capabilities request and then parse the results. There's an existing WMS parser in WG-Maply you can start with. NASA has added a lot more specific information to their WMS return so you'll need to interpret it. This will take longer than you think.
- Build a display for what you get back. Sort the results into base and overlay layers and then let the user select them. A couple of UITableViews will work well for this.
This project will look really cool, but it's balanced by the complexity of WMS.
Wrapup
Those are my proposed projects. Some are trickier than others, but they all require Mac OSX and some iOS hardware. If any of my users have other project ideas, feel free to chime in. Remember that the purpose of internships like these is to teach, not to try and get free labor, so write accordingly.
If you're a student considering one of these projects, feel free to ask questions. I'll be happy to provide more details.
No comments:
Post a Comment