Hi Andre,
I think Simon is correct in that we were not clear on terminology. Due to the fact that the navigation application bundle is provided as a black box, I was using the term ‘navigation application’ to mean all of: • a navigation UI for choosing a destination and planning a route; • a guidance UI for providing guidance for that route while driving, potentially also showing points of interest along the way; and • a navigation service which provides the (non-SDK) APIs used by the two UIs, and can act as a backend for the various SDK geo-APIs.
These two UIs may be part of the same application, or may be separate applications (for example with the guidance UI as part of the system chrome). The navigation service may be a separate process, or may be combined with one or both of the UI processes.
The navigation service might communicate with systems in the automotive domain to provide its functionality.
Essentially, I have been viewing the ‘navigation application’ as a black box which provides UIs and (non-SDK) services related to navigation, and hence have not been differentiating the term.
I believe you were thinking I was using ‘navigation application’ to mean just the navigation UI.
I will reply to your other e-mail with this in mind.
Philip
On Tue, 2016-01-19 at 14:58 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
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.
-- Simon McVittie Collabora Ltd. http://www.collabora.com/
Devel mailing list Devel@lists.apertis.org https://lists.apertis.org/listinfo/devel _______________________________________________ Devel mailing list Devel@lists.apertis.org https://lists.apertis.org/listinfo/devel