[Devel] Updated geolocation and navigation design document

[Philip Withnall]

Hi Andre,

With our clarification of the term ‘navigation application’ in mind
(see my e-mail from earlier today in this thread), I think we are on
the same page about these points. I’ve replied inline below, and will
send out a new version (0.3.1) of the design shortly, which will
hopefully clarify some of the ideas I refer to a little more.

On Tue, 2016-01-19 at 14:13 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
> Andre:  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:
> With the referred APIs (point_of_interest) we hand over data
> _responsibility_ form one (source-app) to another (sink-app).
> The “navigation app” imports that data, from that point in time any
> further data management (duplicate handling, persistence storage,
> validity, usage in various embedded services like destination input,
> route calculation, etc) in in their internal (black box)
> responsibility. The mechanism is simple a point-to-point data pipe,
> deliver and forget.
> We do not flood the navigation app by providing to it all information
> available, only information which shall be handed over into their
> responsibility, so typically which shall influence their routing. We
> do _not_ import all mac-donalds data into the navi app. This stays in
> the mac-donalds app, it gets browsed within this app etc.

The points of interest API supports filtering the set or stream of PoIs
which an application receives, so if the navigation UI needs to show a
specific set of PoIs (fuel stations, for example), it can request from
the PoI service to only receive those.

> Please keep also in mind, that the navigation app itself is somehow
> special in regard to their output. Beside provides some UI to control
> its functions like all the other apps (e.g. media player), the “route
> guidance” information is very special. In addition to a black box
> build-in solution for the route guidance - like all the smartphone
> Smartphone solutions realizing today – (on prompt the guidance is
> only acoustic or an app-change transition to the navigation app
> appears) we will go a step forward for this driver related
> information. The guidance will be presented to the user independent
> of the current App in use in foreground. So you can “leave” the navi-
> app but the guidance shall continue. In fact we influence the
> internal design by requesting an agent to be provided by the app-
> developer to deliver these data. And that’s not only an acoustical
> prompt, its also data which gets finally a visual representation
> (turn icons, lane information, etc). In this approach via an SDK-API
> the rendering gets done by some system service. Its more like a
> “notification”/“dialog-box”/“status framework” stuff (please have a
> look to the running status framework and the relation to assist
> framework too). So the navigation App provides its data as output to
> some SDK-API. In fact part of this is the route list, which finally
> land in that guidance dialog. Lets call it assistance window – driver
> related information.

I see. The way I would recommend doing this in the design is to
implement the guidance UI separately from the navigation UI. It could
potentially be part of the same application bundle, or part of a
different one, or even implemented as part of the system chrome.

The guidance UI would take data from the SDK points of interest API,
and from the SDK navigation route guidance API (§7.6). This would allow
it to render the route (from the guidance API), and points of interest
along the way (from the PoI API).

The navigation UI (where the driver chooses their destination and plans
the route) may retrieve points of interest from the SDK, or may choose
not to if the developer thinks they will be distracting.

i.e. The SDK API you are suggesting for the data from the guidance UI
is effectively the points of interest API plus the navigation route
guidance API.

> To this route list, other apps can directly add further data. This is
> _not_ forwarded to the navi-app, it does not modify the route list
> nor does it gets stored by the navi-app. The navi app don’t has any
> interest in getting and managing it. This data, gets provided by the
> source app to the rout–list and with that finally rendered to the
> user by some system service (assist window). On the other hand, other
> apps can consume this enriched route list again for their build-in
> functions and policies. Its all outside the navigation, the navi only
> provides the initial foundation.

That’s possible due to the split between the navigation UI and the
guidance UI. The navigation UI can choose to not query for points of
interest, or can heavily filter the PoI requests it makes. Conversely,
the guidance UI can query for lots of PoIs.

If other applications want to display something similar to the guidance
UI, they must make the same navigation route guidance API and PoI API
queries as made by the guidance UI. This should be simple to do, and
allows each application to further customise the points of interest
they display.

> Specifically, depending on the answers to the questions in that
> design
> about the relative bandwidth of the POI streams, this can be
> implemented by:
>  • the navigation app queries POIs from a publish/subscribe POI
> service
> and displays them on the calculated route as appropriate; or
>  • the navigation app sends the calculated route as a query to a POI
> query interface (§(Consumer-initiated pull via a stream)); or
>  • the POI apps send their POIs to the navigation app which then
> chooses which ones to display on the calculated route (§(Provider-
> initiated push via a stream)).
> Andre: like said, we are not restricted to an App-App relation (even
> though we support this limited approach too), I am talking about a
> system service in-between. On the one hand this is handling all
> driver related notifications like guidance, but hazard sport
> warnings, speed limits etc, and the navigation App is only one out of
> many providing this data, on the other hand it’s the data
> responsibility, which does mean Points_of_interest API gets used to
> handover the responsibility and this will be done only for a very
> small subset (relevant for route calculation)

I think this is covered by my points above. If it becomes necessary to
add a PoI service to cache points of interest queries between
applications, I believe that can be done much later without affecting
the PoI design significantly. There is no need to add one from a
security point of view, which is the normal requirement for adding a
service.

> The other suggested data sharing models are also possible here,
> depending on the bandwidth needed.
> If it’s also about changing the behaviour of other applications to
> display data pertaining to the calculated route, then we will need
> another API for exposing that data, and it would be entirely
> unrelated
> to POI sharing.
> Andre: yes, that’s part of the scope.

Right. That API is the navigation route guidance API, and is at section
7.6 of the latest design.

> > > - add UseCase: to add something into a route list (e.g.
> restaurants
> > > along the route from restaurant app) and this based on own
> interest
> > > of the user, specified in this app (e.g. via favorites) and under
> > > control of User by enabling this participation via settings.
> >  
> > Do you mean automatically? What is the user's participation in this
> > use
> > case: are they specifically interacting with a restaurant app and
> ask
> > it to book them into a restaurant and add it as a navigation
> > waypoint;
> > or do they just want to see nearby restaurants highlighted on the
> map
> > as they travel through an area?
> >  
> > Andre: like said above, information from the route list will find
> its
> > way to the
> > route guidance (we sometime call this driver assistance
> information).
> > So its not about reservation, its about information. A Restaurant
> App
> > could
> > provide recommendations for a rest stop, fitting to the driving
> time
> > (e.g. a location
> > area reached after 2 hours of drive), the day time (afternoon,
> > evening, etc => coffee break, dinner, etc),
> > the user preferences (Italian, vegetarian, etc) etc.
> >  
> > In relation the use-case above “add UseCase: to share/subscribe
> > (updated) route-information”
> > The App subscribes for changes in route list, and provides new POIs
> > inc ae the path has
> > been changed.
> I guess I am not quite clear about the user experience here. With
> this
> restaurant use case, are you expecting the restaurant app itself to
> provide the recommendations //as part of its interface//; or are you
> expecting it to export them as POIs which will be displayed //by the
> navigation app as part of its interface//?
> Andre: like explained above, please don’t see the Navi app as the
> final sink. It has a relation to a system service to expose its
> notification to the driver.
> <<...>> <<...>> <<...>>
> The “user interface” is part of a system chrome, we call it “assist
> window”. Its like a notification center, but for driver centric
> information. The navi-app provides data to it, but other apps too.
> For each product variant, we implement a UI customization for the
> look & feel of this “driver notification center”. Once the user tap
> on an object in that view, the related app gets launched. There can
> even be a second instance of that information exposed to the
> instrument cluster, but that happens behind the scene with some
> Interdomain communication.  There can also be “POI data” w/o any
> active navigation (route guidance). In case there is no destination
> set (and with that no route list) apps can provide POIs surrounding
> the current geo position (e.g. hazard sport warnings, touristic info,
> etc). The user can define via system settings if an app is allowed to
> expose data to this center (like in a usual notification center)

I think this is covered by my points above.

> > Please add this to the right place – the right proposal - as take
> > care that our design fits to it.
> To be sure I understand you, you’re talking about ensuring that a
> task
> which is started by an application which is then sent to the
> background, is completed rather than (for example) being paused? Even
> while another application is in the foreground?
> Andre: My focus is less the completion in background, my focus is
> independence (or vice versa side-effects) caused by remote calls.
> It’s a kind of “multi-threading”, even w/o multi-user capabilities.
> But to skip the software terminology, think about having a user
> driven path (assume you start writing an email in email client) and
> an inter-app communication (user interrupts email writing, leaves the
> app, [email state in background is still in editing mode of the last
> mail], launches browser, jumps to a url and renders the page, and
> then he gets in mind to “share” that page with some friend, initiates
> sharing mechanism, selects via email, an editing view of email slides
> in with the given url embedded). This task shall _not_ irrevocable
> destroy the background mode of the email app, which is still in
> editing mode of new mail. The user can even switch to email, and
> continue writing it, because the new one is executed on behalf of
> browser. If the user switches back to browser, he gets the sharing
> screen on top, etc. Its typical iOS behavior, so you can reflect it
> quite easy.

I think that is the behaviour we are aiming for, although it depends to
a certain extent on application developers implementing their
applications to behave correctly when focus changes and another
activation request comes in.

> > In an app centric solution we would like to enable freedom for Apps
> > to present it accordant to its needs. So
> > the App can define the size of the map widget, its position in the
> > screen, it can add animated transitions to the whole widget
> > (e.g. a backflip animation of the map, showing some preferences on
> > the back side), and can also define the look & feel of
> > Data added to the map (e.g. appearance animation of added POIs,
> i.e.
> > own clutter actors).
> OK, that’s all possible. What would not be easily possible is to
> allow
> the application to define how the map itself is rendered (for
> example,
> what colours are used for different grades of road), as libchamplain
> typically uses pre-rendered image tiles for its map, whose rendering
> we
> cannot affect.
> Andre: yes, the tiles are ok. I referred to freedom for data _added
> by the App_
> That’s not the tiles, but additional icons, points, polygons, etc.
> Even for these we can prepare some fitting well to the overall
> look&feel, e.g. “blue pin falling from sky” for POIs, but an app my
> create on own clutter actor for its POIs and use them for the
> representation of its additional data.

Definitely all possible (and easy) with libchamplain.

> In all three cases here, I think the POIs are coming from the same
> pool
> of sources. The differences arise in how long the sinks keep the POI
> data, how they process it, and which of the POIs they consider
> interesting. Am I following your thinking correctly?
> Andre: to be honest, I am thinking in another direction. Its driven
> by responsibility and data management.
> In regard to the first topic: There is stuff which gets embedded into
> libchamplain which stays completely in the App responsibility. Its
> for User Interaction, nothing else. It uses libchamplain APIs
> (clutter) to embed POIs. The user can interact with it and
> libchamplain informs the App about content selected which has been
> included by it. So nothing from a central POI service in that regard.
> In regard to the last topic: There is stuff which gets imported into
> some other App. Data responsibility gets forwarded. This is the “some
> App streams data into the navigation” via a pipe solution. Nothing
> central in between for the data flow, only for the control flow some
> SDK-API has been used.

My suggested design for implementing the guidance UI avoids the need
for tunnelling points of interest, by keeping the points of interest
API separate from the navigation route guidance API. If the two were
combined (i.e. PoI data nearby to the route was provided as part of the
navigation route guidance API), then we would potentially have problems
with data ownership and freshness. Keeping the APIs separate means that
each application which queries for points of interest gets up to date
ones.

> Finally the is the route list, where Apps can decide to embed data
> for the driver. I have explained above that stuff more in detail.
> Again a different thing to the 2 above. The validity of this data is
> only during runtime. The system service does not store the data
> persistently.

I don’t think there are any recommendations for any of the software
we’ve discussed (the navigation UI, guidance UI, or other applications)
to persistently store points of interest which have come from the PoI
API. I would expect any application (or part of the system chrome)
which uses PoI data to re-query it at appropriate intervals, and
certainly every time the application starts up.

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/20160120/821b4788/attachment-0001.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/821b4788/attachment-0001.bin>