[Devel] Updated geolocation and navigation design document

Philip Withnall philip.withnall at collabora.co.uk
Tue Nov 17 10:46:07 GMT 2015


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: 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/20151117/a2ef973b/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/20151117/a2ef973b/attachment.bin>


More information about the Devel mailing list