May an extension read the offline map store, and is there a supported way to get the road network ahead?
I built a coaching extension that computes per-segment power and speed targets from rider physics. Using karoo-ext 1.1.9, OnNavigationState gives me everything I need while a route is loaded: polyline, routeElevationPolyline and climbs all work well on a Karoo 2.
Many riders using it don't load a route. For them I'd like the road network ahead of the rider so I can look ahead to the next junction and estimate gradient. Two questions:
-
The offline maps live on shared storage at /storage/self/primary/offline/maps/*.map in standard Mapsforge format, readable with the normal storage permission. Is an extension permitted to read those files? Is that location something you'd consider stable across firmware updates, or should I treat it as private and not rely on it?
-
Is there a supported or planned karoo-ext API for the roads or elevation near the rider without navigation running, similar to what NavigatingRoute provides once a route is loaded? Even an elevation-along-heading lookup would cover my case.
If reading the map store is not something you want extensions doing, I'd rather know now and build my own road and elevation data instead. Thanks.
-
I think the Mapsforge data does not contain elevation if I remember correctly, as it's not required to draw the map (The recently added contour lines are precalculated polylines stored elsewhere I think). It does contain other useful data like surface types though.
It would be amazing if HH added access to the predicted route and its elevation to extensions as you suggest. Or even better, low level access to the routine engine and its data. They have not added new features to the SDK for more than a year or so though, and seem to be happy with what is there currently. They generally do not engage with third party developers here or on the defunct github issue tracker.
-
Thanks, that matches what I found. I opened the Karoo's ontario.map with mapsforge-map-reader: it has highway type, name, surface, tracktype, cycleway and oneway, but no elevation, as you say.
Two things others may find useful. First, the routing tiles beside the map (
.gph.gz, Valhalla format) do carry elevation per edge. I compared their per-edge mean elevation with my own surveyed profile along a 45 km ride and it agrees within a few metres, though a long rural edge gives only one value, so the shape inside the edge is lost.Second, karoo-ext 1.1.9 already gives an extension the loaded route's elevation: subscribe to OnNavigationState and the NavigatingRoute carries routeElevationPolyline, a 30 m profile of the whole route, plus the climbs list. On my Karoo 2 that worked, with the caveat that the state is delivered on subscribe and not pushed when navigation starts later, which I filed as karoo-ext issue #81. So the gap is only free riding without a loaded route.
Has anyone here parsed the Valhalla tiles on-device, or heard whether reading the offline map store is tolerated by Hammerhead? I would rather build on something supported than on files that may change.
-
Hi David, some progress, but not from the Karoo's own map data. The elevation in it turned out too coarse for what I need, and Hammerhead hasn't replied about access. So I went the other way and built my own road and elevation data. Elevation ahead without a loaded route is now running on a few test Karoos and looks promising so far.
What are you hoping to use it for?
-
Are you sure the karoo's own elevation data is too coarse? The karoo climber feature works fully offline without a loaded route so I thought the data has to be there. I did some tinkering with the routing data, and the data is reasonably easy to access with the nice valhalla-mobile project, which provides a jni binding and statically linked android library build of valhalla; I only patched in the valhalla locate api endpoint and some landmark handling where it crashed out before (not sure why). Map matching the route with trace_attributes allows to sample the elevation in a fixed interval, and the data looks good to me (I'd think this is the exact same data karoo-ext supplies in the elevation polyline when a route is loaded or you are navigation to a pindrop).
I prototyped elevation lookahead without a loaded route for my routegraph extension, but am not happy with the path prediction algorithm so far. I use the trace_attributes valhalla api with recent gps measurements to get the current way_id, and then use the locate api to look up the current edge's path and from then on, the next edge at each upcoming intersection, assuming the user continues to ride on the same road or does the least required turning if the current road ends.
It is not stable enough yet though; it snaps to adjacent roads too frequently and sometimes does not pick the correct edge at intersections.
The routing data also contains other useful stuff (surface conditions, tunnels, ferries, bridges) that are nice to have and show.
-
I come from wahoo and used the elevation profile ahead all the time. Imo it was super handy to know for descends or rolling terrain, etc, when I did not have a loaded route. In Wahoo you had 2km or so ahead predicted. More than enough to give you an idea of what was coming.
Please count me in for any testing. I really miss this feature so much. I find it odd that not more people are asking Hammerhead for it. Specially because it shouldn't be a big deal for them to implement it or let others do it.
-
@timklge thanks, that’s helpful, and you’re right that the data is there. Reading the tiles with Valhalla, we get per-edge elevation and grade, which is clearly what Climber uses.
“Too coarse” was about our use, not climb detection. Against 1 m LiDAR ground data the per-edge heights were typically a couple of metres off. That’s fine for spotting a climb ahead, but not for metre-level grade on short stretches.
One question: on the desktop, sampling at a fixed interval (elevation_interval) gave us no usable per-point heights, only the per-edge values. Which Valhalla version do you use in valhalla-mobile, and do you get real per-sample heights?
@Hammerhead, the original question still stands: is reading /sdcard/offline/nav from an extension permitted, and will the tile format and location stay stable across firmware updates?
Please sign in to leave a comment.
Comments
11 comments