[Devel] Updated geolocation and navigation design document

[Barkowski Andre (CM-CI1/PRM1)]

Hi Philip,

I feel we are still not fully on the same page. We closed some gaps lately (in regard to the assist-window), but it seems to me that we still have a gap in regard to POI handling itself.

So summarize, let me go one step back and start with 
-	POI service is _not_ equal to route-list.
I am talking about a route list, you are talking about a central poi service.

Let me add: 
-	we do _not_ need a central POI service, or vice versa I am not aware about a related requirement.

We do have the already mentioned 3 Use cases and the mechanisms discussed covers the use-cases already perfectly
1) for in app UI browsing: libchamlain. We have it, fine.
2) for app import / handover: Pull mode for various types of content – also TPEG based POI data -  https://wiki.apertis.org/Points_of_interest 
(For completion there is also a push mode for various types of content – so far no need for TPEG support -  https://wiki.apertis.org/Data_sharing )
again, we have it designed already.
3) now we add the route-list to the SDK-API, where I also ask to provide capabilities to add POIs to it (independent from the navi-app)
In any case we do need the route list, it has originally nothing to do with the POI discussion. Apps shall be able to consume information about the current route and to create some functionality. That the purpose of the route list essentially. 

Based on that scope, I am asking for the additional functionality to add Metadata/Content from Apps directly to it, especially POIs. Its neither a first priority nor will it dramatically change the design. Its simple an add-on. We can even decide to implement it later.

Similar stuff is valid for the guidance & assist window discussion. The APIs for the “guidance”  (which is “just another notification style API for a dedicated purpose”) as also the assist window (which is just another system chrome application where for example the data exposed via the guidance notification style SDK-API lands in) are optional and don’t have side effects to other SDK-APIs. So we can implementation wise realize it in a later step, its not of first priority. However, I like to have a common understanding about the overall scope early. 

If we provide capabilities to add metadata into an available route-list to Apps, other Apps (than the navi app) can add additional content/ additional metadata to available content, for example POIs into a currently shared route list. Since we have already libchamplain and also the Point_of_interest and sharing mechanisms design, My focus is on just one more method for that route-list. I am _not_ talking about any big thing, especially not about a central POI service. 

I would like to propose we serialize the discussion. How about first finalizing the solution for the route list, including POIs into it from Apps via an SDK API.
Then reflect, for what a central POI service could be beneficial ?

I have embedded some comments below in green.

Rgds
Andre



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

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.

Andre: like said, lets skip the central POI service for now. We do have https://wiki.apertis.org/Points_of_interest.
I hope we are inline in regard of its functionality and do not have a mismatch there: There is a control flow with an OS service validating if a data flow is allowed, then a pipe gets established with proper access rights for producer App and consumer app. That’s it. The provider App forwards POI data in TPEG format, the policy which data gets forwarded is in responsibility of the provider App. The consumer App gets no way to influence it. Its all in the scope of the producing app. It has its policy, its user interface etc. The consumer App handles the data validity in its own scope (persistence storage, duplicate detection, validity, etc), it “imports” the provided data. In addition all pipes are dedicated, so we have multiple dedicated (and private) provider / consumer connections, and all consumers gets the same data. This fits to an app centric approach. Even though the first interaction is based on dbus, its not a “client server model way” where parameters / request can be defined and the data gets centrally stored.

Even though it is a pull mode, it is finally controlled by the User (by allowing connections via settings, as also selecting the provider of choice if there are multiple and with that also the policy he likes)

Beside the stuff said for Inter-App Communication, there is an additional sink – again used by other Apps as they consume the Route List but also for the optional Assist Window. This data runs via the route list, so the Provider App can implement a policy which decides a  subset to be provided into the Route List. 

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

Andre: to be honest, this all is optional. A navi app developer can decide to implement the guidance in its local app-bundle scope. Then the UI appears within its own App Screen Area. 
However, since it is beneficial (independent from the POI or Assist Window Discussion) that the guidance portion is separated from the rest of the full-fledge App (because it enables us to handle a separated executable with its own lifecycle, which means we can keep only that part running in background instead of the Full App) we should ask for an Agent for it. The App developer can decide to do so or not. So the requirement for isolating the Guidance into an Agent is already valid w/o all the discussion about POIs and/or Assist Window.
On top of that we like to also support an assist window solution as part of our system. Therefore we will provide a notification style similar API for driver related information. Guidance data will be covered by it, and if a Navi App developer decided to use this SDK-API, the guidance information will land there (but also information from route list will land in such an assist window). Similar like mentioned above, we like to ask the developer to provide an agent for the guidance data. However, the assist window (the UI for the guidance) is finally a system chrome element and not deployed with the App bundle. It belongs to the OS and gets distributed with it. 


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.

Andre: like said, its not the “points_of_interest” API, its from the route-list 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.

Andre: 
to be honest, the use-cases behind that stuff is _not_ that another app will do something similar like the guidance UI.
Other Apps uses information form that API for their essential service, e.g. if an App of a weather service does know intermediate destinations from the route list, it may decides to show entries on top of the stored locations for current destination and intermediate destinations (in todays list you have the current positon for example as a default, this app could extend that approach depending on stuff from the route list).

Or if a gasoline station app adds a refueling stop into the route list for a location to be reached at a time where the car runs low on fuel, a restaurant app may uses this information to add recommended cafeterias into the route list to align the breaks for the driver. 

Or if a restaurant app decides to add restaurant POIs as recommendations into the route list for a location to be reached at a time where a break would be wise, a installed “coupon” app may add available discounts available at this location.  

etc. 


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

Andre: like said, it’s the route list, not a central poi-service I am talking about.
To be honest, I am stressing this because data in that scope is not limited to POI. 
POIs are belonging to it, but its not only point, also lines, turns, attributes, etc 
But Yes, adding POIs from an App into this list other than the navigation can be added later.


> 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.
Andre: agreed. But we have to provide awareness, recommend separate agent for this interaction, and may test it (if they participate at the “sharing mechanism” for exposed data types, during validation we have to test that it is instantiable.

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

Andre: I see, but the only motivation for this POI data is its relation to the route, (and the knowledge the neighborhood). 

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

Andre: navigation UI is in App responsibility, there we do not need recommendations for it.

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160122/8380356b/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/20160122/8380356b/attachment-0001.bin>