[Devel] Updated geolocation and navigation design document

Wed Nov 18 13:39:25 GMT 2015

Hi Philip,

please find enclosed some answers in green
After having done this iteration, I will now review the document an send afterwards some feedback. 

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.

Andre: ok

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

Andre: creating navi-apps from scratch (fully relying on SDK-API exposed functionalities) are not in focus.
(I have send a separate mail for this topic) 

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.
Andre: There is eventually a certain level (functional scope) of navigation app achievable using exposed SDK-APIs with 
Backends based on cloud solutions deployed as default, but like said its simple not our focus. 
If someone is willing to create its own Navi-App cased on it, he is free to go for it. And he is also free to substitute functionality over time with build in ones, but we do not take care that its functionality is well done. 

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

Andre: yes, but before we remove them lets reflect vice versa from LBS-App point of view, if this is scenario e.g. from consumer point of view which is worse to mention.

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 <mailto: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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.apertis.org/pipermail/devel/attachments/20151118/0f8a7c62/attachment-0001.html>
-------------- 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/0f8a7c62/attachment-0001.bin>