[Devel] Updated geolocation and navigation design document

[Barkowski Andre (CM-CI1/PRM1)]

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 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.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

_______________________________________________
Devel mailing list
Devel at lists.apertis.org
https://lists.apertis.org/listinfo/devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 03_MRS_AssistWindow_AltDest1_2010.01.06.png
Type: image/png
Size: 144641 bytes
Desc: 03_MRS_AssistWindow_AltDest1_2010.01.06.png
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160119/71b631ad/attachment-0001.png>