[Devel] Updated geolocation and navigation design document - navi

Wed Nov 18 13:14:59 GMT 2015

Hi Philip,

let me focus on "navigation apps" in this answer (I will follow up on the other topics mentioned below in a separate email).

" I was operating on the assumption that navigation apps would use the
SDK (with the caveat that OEM-provided navigation apps may additionally
use out-of-band data from OEM-specific APIs in the automotive domain).
Is that not the case?"

Let me try to explain, hope its possible to get the essential part from it.

I said, let's look from an LBS-App point of view, which is not a navigation application (e.g. Hotel, Restaurants, Weather, etc).

These Apps mainly use SDK-APIs from a _data consumer_ point of view, e.g. geoposition, route-info, map, reverse geocoding api, geofancing, etc similar like it also uses TTS-API etc.
In contrast, the Navi App is special, because it fulfills the role as a "data producer", e g. providing map data for libchamplain, the route data for route-info API, or a geoposition with higher accuracy for geoclue, or even as a backend for "type-ahaed search and address completion" or "reverse geocoding".
The build in functionality (the route calculation, the map rendering, the destination input, the street data, etc) is all "black box" internal stuff carried by the App itself. So if we for example ship our own BOSCH Navi as an App, or a TomTom one, or a NavIt one or whatever 3rd party Navi solution, it will bring its own binaries an data formats. We don’t care about it, its in the responsibility of the App-Developer. In addition, the Navi App requires a set of APIs to get functional at all, - mostly a subset of the ones needed by LBS Apps mentioned above (e.g. geoposition, TTS-API, may be some data from sensors and actuators design like vehicle speed, etc). If this APIs are not available, the Navi-App itself will not work well. Once this has been archived, there is an additional set of APIs, where a Navi App can decide (via manifest) if it interacts with. These are APIs, where the Navi-App itself fulfils the role as "data producer" - e.g. replacing other backends in use so far (or being the first producer at all). The data produced gets then shared via SDK-APIs to other Apps (samples mentioned above).
That’s the usecases which we would like to cover.
It is a non-usecase, that someones starts to create a navi solution from scratch fully based on the functionality exposed via SDP-API only (i.e. map rendering is based on libchamplain only, positioning is based on geoclue only, destination input is based on " type-ahaed search and address completion",  route calculation is based on "route-info") etc. 

Do you see the difference ?

Scope is
- development of LBS-APPs
- packaging and deployment of Navi App 
- Navi-App as data producer
And independent of that
- exchangeable Backends

Rgds
Andre

-----Ursprüngliche Nachricht-----
Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk] 
Gesendet: Dienstag, 17. November 2015 11:46
An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>; devel at lists.apertis.org
Betreff: Re: AW: [Devel] Updated geolocation and navigation design document

Hi Andre,

On Mon, 2015-11-16 at 17:20 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
> thx for the updated document.
> After having read the document and before I start providing deeper
> feedback, I was wondering about the UseCases covered in that
> document. We have used the pattern (from Usecases to Requirements,
> reflection of existing solutions and coming to a proposed approach)
> already multiple times, but this time I was really wondering, when do
> we pick up a use-case to be mentioned ?

That’s a good question. Picking up use cases seems to be the hardest
part of producing these design documents. Personally, the way I have
been doing it is to make up what I think are reasonable use cases for
such a system (based on my experience of using similar systems), and to
add in use cases I have received from other parties. When the document
undergoes review (either internally or externally), I add more use
cases extracted from the feedback, and iterate until everyone seems to
be happy.

I am working on the assumption that if anybody spots a use case which
is missing – or one which they think we should //not// design for –
they will comment on that in their reviews.

> One of my primary intentions is to define the SDK-API. So from that
> point of view I reflect, what kind of use-case exists for a "non-
> navigation app" to deal with location based information (e.g.
> Weather, Hotels, etc). That’s an App-Developer point of view. 

I was operating on the assumption that navigation apps would use the
SDK (with the caveat that OEM-provided navigation apps may additionally
use out-of-band data from OEM-specific APIs in the automotive domain).
Is that not the case?

Certainly, using my phone as an example, I have a variety of navigation
apps available to download, all of which use the Android geo-APIs.

> Another set of use-cases comes from flexibility in system setups,
> that’s influencing things behind the scene and is more a System
> Integrator point of view.

Agreed.

> In contrast, I do _not_ take into account what an developer of a
> navigation App would like to do. That’s all internal stuff, without
> dependency to the SDK. 
> I do have the feeling, there are uses cases included only relevant
> for Navigation internal implementation. Lets call them Navi-features. 
> But I am not sure. Things like "Deviating off a navigation route",
> "Resuming a navigation route" or "cancelling a navigation route",
> aren't they full App-Internal ? Its seems to me like we would discuss
> that a phone call needs to have the capability to be canceled. That
> for sure right, but I miss why its important for our context. 

These particular use cases were specifically aimed at navigation apps,
yes. In this case I may have been too verbose, as those use cases did
not translate into requirements for the routing API — they could be
implemented entirely internally in a navigation app, as you say.

Philip

> Or the description is misleading, e.g. an App would like to subscribe
> for a new route (for example caused by deviating off a navigation
> route, but also caused by other reasons like a new (intermediate)
> destination has been set). In that case the description / and the use
> case would more focus on consuming the new-route information and to
> generate some great service from it instead of "that the calculated
> route must be radically different", and "recalculation should happen
> within a short time period". 
> 
> Hope you get what I mean.
>   
> Rgds
> Andre
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Devel [mailto:devel-bounces at lists.apertis.org] Im Auftrag von
> Philip Withnall
> Gesendet: Donnerstag, 12. November 2015 17:40
> An: devel at lists.apertis.org
> Betreff: [Devel] Updated geolocation and navigation design document
> 
> Hi all,
> 
> Please find attached version 0.2.1 of the geolocation and navigation
> design document. This version incorporates feedback about swappable
> backends and the ability to back any of the APIs by an implementation
> in the automotive domain.
> 
> I have uploaded this version to the wiki as a draft. Further feedback
> is welcome and will be incorporated as normal.
> 
> https://wiki.apertis.org/File:Apertis-geolocation-navigation-design-0
> .2
> .1.pdf
> 
> Thanks,
> Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6749 bytes
Desc: not available
URL: <http://lists.apertis.org/pipermail/devel/attachments/20151118/6aa43b8c/attachment.bin>