Hi Simon,
i agree, we have to align our understanding of the scopes.
We do have a an "App-Bundle" for Navigation. Its more than the "service". Beside the "services" like positioning, route calculation etc, it also covers HMI for destination input, and also the map rendering including the rendering the route in its navi map. And to make is also concrete, the App-Bundle can decide not to use libchmplain for it, its their internal stuff rendered once the App is in foreground.
The only thing I am talking about is the "guidance". That’s an additional separated scope compared to the once mentioned above.
For sure this can also be handled in the black box internal scope of the App-bundle, that’s not forbidden. Since this does not need any further APIs we do not need to discuss this setup in more detail. But I like to push the limits and not to restrict it to a build-in solution only. So this special part I like to separate and to put an SDK-API in-between and to request an Agent to be delivered by the App-Developer to expose data to it.
The visual representation of this data gets realized by some system chrome software belonging to the OS.
In the picture enclosed, the map shown on the right part is rendered by the app-bundle, based on their own technology of choice (including data received via a pipe from 3rd party apps). The Assist window shown on the left part is rendered by the OS, based on data received via SDK-APIs from various Apps. In between we see a minimized part of the App-Launcher, which can be used to switch between Apps.
Rgds Andre
-----Ursprüngliche Nachricht----- Von: Devel [mailto:devel-bounces@lists.apertis.org] Im Auftrag von Simon McVittie Gesendet: Dienstag, 19. Januar 2016 15:33 An: devel@lists.apertis.org Betreff: Re: [Devel] Updated geolocation and navigation design document
On 19/01/16 14:13, Barkowski Andre (CM-CI1/PRM1) wrote:
no, we still have a fundamental mismatch, the purposes are very different. I feel its hard to discuss all that via email, but lets try:
I think you and Philip are using the term "navigation app" to mean different things, which has led to some confusion.
It sounds as though we have two components:
* The navigation service (possibly in the automotive domain), which receives location and a limited set of POI, plots routes, etc.
* The assistance window (navigation UI), which draws the route provided by the navigation service
I think when Philip and I have talked about "the navigation app", we've mostly been thinking of the assistance window. When you talk about "the navigation app", are you primarily referring to what I've called the "navigation service" here?
Which one do you intend to be potentially end-user-swappable, for instance via an app store - the navigation service, or the assistance window, or both?
I suggest we try to avoid "navigation app" as a term if it's going to be this confusing, and find a more precise description of each part that needs to be a separate entity.
