[Devel] Updated geolocation and navigation design document

[Philip Withnall]

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 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
> _______________________________________________
> Devel mailing list
> Devel at lists.apertis.org
> https://lists.apertis.org/listinfo/devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160120/efe89131/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5445 bytes
Desc: not available
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160120/efe89131/attachment.bin>