[Devel] Updated geolocation and navigation design document
Barkowski Andre (CM-CI1/PRM1)
Andre.Barkowski at de.bosch.com
Tue Jan 19 14:58:25 GMT 2016
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.
Von: Devel [mailto:devel-bounces at lists.apertis.org] Im Auftrag von Simon McVittie
Gesendet: Dienstag, 19. Januar 2016 15:33
An: devel at 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.
Collabora Ltd. <http://www.collabora.com/>
Devel mailing list
Devel at lists.apertis.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 144641 bytes
More information about the Devel