There are three types of Augmented Reality (AR): marker-based (CV detects known objects and replaces them with CG objects); markerless (CV detects flat surfaces and places objects on them); geographic (using GPS and sensors location). Many point-of-interest AR apps exist already, but most are proprietary. One little-explored area is country-side navigation, using AR to navigate while hiking, possibly cycling.
Navigation helps can be either signposts pointing to landmarks in the neighbourhood, or an indication of where the path should go.
App uses Camera2 for image, Location, Sensor API for positioning, OpenGL for rendering, OSM for geodata. Elevation data is also critical to render pathways, otherwise they will be rendered either underground or floating in the air. This is one of the more difficult challenges, not just to get the data, but also to render things correctly.
Hikar was originally developed in 2013, mostly by Nick. Original elevation sources were Ornance Survey (UK national geographic agency) and NASA.
The map data is downloaded from Geofabrik, filtered with osmosis to get roads, footpaths and some POIs. Import into postgis with osm2pgsql. Data is served by a PHP-based web API that serves GeoJSON, and cached on the device. But Nick’s server only contains data from Britain, Ireland and Greece - due to server cost constraints.
Terrain tiles are retrieved from Mapzen which is hosted on Amazon S3. It is encoded in Terrarium PNG which encodes elevation as an alpha channel.
For signposts, a graph is generated from the OSM data by finding the junction nodes and make vertexes out of them. Edges are the OSM ways, weighted by their actual length. JGraphT is used for routing. A signpost is generated whenever you’re near a junction. The arms are generated based on the bearing of the ways corresponding to the outgoing edges. But only footpaths are selected. Then, the POIs in a 5km distance are selected and the route to each of them is computed. Then, each POIs is taken based on the bearing of the first segment on that route. POIs are weighted by type and distance and only the two most important ones are retained. Since POIs may not be at a junction (e.g. a hilltop), then use the nearest junction instead.
A future plan is to use CV to put the paths down accurately, not just based on the z-coordinate but on the actual visible paths.
Some of the approaches taken here are more general than just hiking, e.g. city guides, POI information. So one plan is to split off a HikarLib that contains the common parts.
Nick teaches Android and Web development and is a long-term OSM contributor.