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@collabora.co.uk] Gesendet: Dienstag, 17. November 2015 11:46 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; devel@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@lists.apertis.org] Im Auftrag von Philip Withnall Gesendet: Donnerstag, 12. November 2015 17:40 An: devel@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