Hi Philip,
even though - from my past experience in regard to navigation - I would prefer a design processing the common part in a backend once instead of doing it many times in (the process scope of) each App, I am willing to keep freedom for internal designs and to follow other proposal due to the following reasons: - using a library as primary API set to be used by Apps is not an issue by itself (its like an API binding, it can also encapsulate message based backends) - we can change the backend implementation in future releases (also to a more centralized approach), w/o any impact to the library based API (SDK-API) for client access (and with that without impact to already created Apps) - the initial functional scope of "horizon" API will be limited, further extension will come over time in future - my preference is founded on my experience of navigation based algorithms and data structure only, no detailed analysis has been done.
So even though I am very convinced that a backend based approach fits better, - the app-centric approach is ensured - the impact is reduced - I like to respect duties - I like to conclude
That said, for me its somehow similar like the media solution, with some grillo / library based SDK-API providing access to a central dataset.
some final notes supporting a centralized approach: beside the resources (I/O, CPU, Memory) needed to process things multiple times instead of once - we ran in past also often into inconsistencies (e.g. based by missing deterministic within the algorithm itself) or based on asynchronous/parallel processing. This leads to confusion, because the user gets something presented in App 1 but something different in App2 in scopes which should identical.
From my point of view, you underestimate the effort, complexity and runtime dependencies for map-matching algorithms.
At least the following 2 features further support a central approach. These feature should - at least over the time via roadmap - not be forgotten - creating the horizon is also needed outside of Apps system chrome applications (in contrast to User Apps) - will also need access to this data/horizon. There will be an "Assist Window" - somehow - comparable to a notification center - where this horizon is provided to the User at some central place (outside the scope of Apps). For that, the library providing that code runs already and at every time linked to the system chrome process. - the requested capability to iteratively/recursively enrich the common data set seems not possible (at least not practically/efficiently, only theoretically) in a locally processed approach. However, since (like said above) the initial functional scope of "horizon" API can be limited, this limitation will appear first once we extend it over time in future. Sio the initial impact is limited.
So to conclude, I am very convinced that a backend based approach fits better, but I do not have any issues with a client-side library for the SDK-API. The remaining thing which makes me feel uncomfortable is, that I like to make things right from the beginning and do not like to waste time and effort e.g. caused by unnecessary refactoring. This slows down our progress, because it reduces our budget (and even more important time to market) for new features.
Rgds Andre
-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Montag, 15. Februar 2016 17:37 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; devel@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document
Hi Andre,
I think, if you agree with my reasoning below about choosing a library over a service/daemon, then we agree about everything and I can update the design to include the results of all this discussion. If so, I will try and get it done and internally reviewed by the end of this week.
On Thu, 2016-02-11 at 15:09 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
ok, again a step closer to each other. The discussion how is something realized (as library or with a dbus api), is of second level detail for me. I still try to clarify the first level interests, which is functional deployment & related responsibility of code, and if you say something like "Apps are merging POIs with the route list", then I understand that this is part of their code- responsibility. But know you clarified, that you intended to provide a library for them, so you are more looking from process point of view. That is a different level compared to my point of view, so we talk past each other a little. All that aspects, process boundaries, implementation decisions (library vs messaging) etc, are out of my focus at this point in time. Please try to keep that in mind in our future discussion. So independent if based on a library or dbus (lets discuss that later), there is a prepared central solution exposed via an SDK-API which applications can use to access aggregated data (POI merged into route list). In your current thinking, the solution would be a library and internally call the SDK route list API and peer to peer POI APIs
Correct.
At this point the remaining thing of interest for me is, if based on this 2 API types (route list & POI) all functionality to be provided can be covered. Then to prevent misunderstanding:
- we can push the aggregation capabilities of the central service
w/o impact to app-code / responsibilities
- we can optionally tune the aggregation policies / algorithms
accordant to OEM requirements per product
These are things which I thought we were explicitly avoiding? As I understand it, you want the //providers// of POIs to be in control
of
which of their POIs are added to the route or sent to other applications. It’s certainly possible for a central service to do this instead,
but it means moving some or all of the responsibility for deciding which POIs are shown from POI providers to this centralised service. Yes, but please distinguish between both parts: its like 2 steps, first the Providing App decides with its build in policy what to send. That right and good to see that you keep an eye on it. But its up to the consuming App to process it with its build in algorithms, and in that regard there is a second step where a policy is implemented, deciding which of the received content (POIs) to consider how. Since the aggregation takes place in this central component, this implementation decides who to deal with duplicates, etc so with the final result. This implementation can be tuned, in regard to capabilities as also OEM specific policy. So I do not mean to shift things completely away out of the App scope, its simple 2 steps, Providers decide what to provide, consumers decide how to process and about the final result.
OK, that’s possible in the design, regardless of whether the aggregation is implemented as a library or as a service. If you want the aggregation to be //enforced//, then it must be implemented as a service, not a library.
If applications accessed the POI API through an aggregation library, it could implement any aggregation policy you wish — but if the application wanted to bypass this policy, it could use the POI API directly to get the full, unfiltered stream of POIs.
I suspect you do not want the aggregation to be enforced, however, and want to follow our normal approach of giving the application a high- level API which does what 90% of applications want (a library which implements the recommended POI aggregation policy) but allow the 10% of applications which need special behaviour to use the SDK POI API directly and perform their own aggregation. (In fact, you’ve said that below: “where ever we have higher level APIs, we recommend to use them instead of the low-level ones”, so I’m satisfied.)
And to follow up with the next topic: yes, we want the ability to display the routelist (but no POIs) as an overlay on a libchamplain map. That’s unchanged and thx that you keep an eye on it.
OK.
From my point of view, we now have a common understanding for the (high level) scope which I was looking at.
Yes, I feel that too.
So the remaining discussion now gets reduced to the implementation detail of the “horizon component” - which aggregates the low level data (route list and POIs) - if it should be a library or a dbus- service. … I like to ask you to reflect and discuss the various aspects of both approaches again and to follow up afterwards.
As Simon has said, this is partially a performance matter, and partially a privilege separation matter.
If we consider memory usage, I think that using a service/daemon for the aggregation would actually increase memory usage, as each POI would have to be stored fin the service’s memory for aggregation, plus also in the memory of each consumer application which is displaying the POI in its UI. In contrast, a point-to-point implementation only stores the POIs in the memory of each consumer application. (Both implementations may also require a copy in the memory of each //producer// application, depending on how that application produces POIs and whether it needs to retain them for later processing.)
The main advantage of using a service/daemon is that if aggregation is expensive in CPU time, or results in a large proportion of POIs being filtered out, a service means that work is only done once rather than once for each consumer application.
However, in the case of points of interest, aggregation should be simply merging points of interest with (for example) the same name and coordinates, which does not require much CPU power. I don’t expect that many points of interest would be filtered out.
In contrast, aggregating contacts in libfolks is quite a CPU-intensive process, as multiple properties need to be checked between all pairs of contacts (which may number in the thousands) — this is one reason why a service/daemon-based architecture would be a suitable alternative way of implementing libfolks.
So overall I would suggest using a library, rather than a daemon.
An one minor remark, only to take care we are on the same page in that too - like in all other app-centric concepts the User has the final control about interaction between Apps. It starts for sure with his personal selection of Apps from store – and with that with the candidates who are installed in the system - but it continues with the detailed selection out of the installed ones which are allowed to provide data (POIs) to the horizon as also to consume it. Its some kind of per App switch in the settings, if the app is allowed to provide data to it as also a switch if it is allowed to access it (similar like with access to other databases, like contact, photos, etc). And this data provider role of an app should also “run” during the app is not in foreground. And to minimize system load, we would request to provide an agent for this dedicated task, which starts with the system startup and keeps running until system shutdown with some appropriate scheduling and small resource needs. But that is nothing special for this use-case, this is a general pattern for apps interacting with OS services.
Noted.
-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Dienstag, 9. Februar 2016 15:50 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; dev el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document
I see what you mean. My thinking behind providing the route list and POIs separately are because other parts of the geolocation design require them separately — you wanted the ability to display the route list (but no POIs) as an overlay on a libchamplain map in an application, for example. So a route list API has to exist; and if that exists, and the peer-to-peer POI API already exists, why not use the two to provide the horizon to applications? Andre: yes, that needs to be supported In general I see this like higher level APIs of same kind, similar like in UI-customization where we come from raw APIs, via some building blocks up to well-prepared templates, in this scope coming from also raw entities to aggregated ones. So looks like we are on the same page for that.
Yes, indeed.
And I am not only talking about combining routes from various Sources(Apps). That’s only an example to point out challenges. So don't forget the more common case to add additional objects like
POIs
to a given Route, as also to add attributes (metadata) to already available objects.
Once this service is available, we do _not_ need any public route- list API exposed to other Apps anymore, because the route-list data is included in the horizon. So if Apps like to get route-list information, they will find them in the horizon data.
I think we’re coming at this from opposite directions: as I said above, I’m thinking about providing APIs A and B separately, and allowing applications to use either or both. You’re thinking about providing API C (which is a combination of A and B), and applications can use that and filter out what they don’t want. Andre: my understanding from your explanations above is, that you also provide the library to create C (the combination of A and B). That’s what I call centralized. So finally, its simple all supported by prepared SDK-APIs. That’s fine for me.
Correct.
So does this mean that I have misunderstood the need for a libchamplain map layer which applications can use to display //just// the route list on top of a map (with no POIs or other horizon data)? Or do you want that to be implemented by consuming the horizon API and filtering out the POIs to just leave the route list data? Andre: no, you did not misunderstood it. The functionality is needed. My focus is on the SDK-API, things which gets used by the Apps. Apps use libchamplain, so that the SDK-API in this regard. How data lands in libchamplain is out of scope of the SDK-API. So we can add the route-data (only, w/o POIs) into libchamplain, and nevertheless discuss SDK-API for horizon. So we can talk about different lines of APIs. The libchamplain integration is behind the scene. Its part of the OS, behind the SDK-API. Not in the scope which I look to right now. Don't be confused, the functionality is required. However, there are various ways to implement it, and since it is not impacting the SDK- API - it even does not have to use SDK-APIs at all - its completely in our hand to make it efficient in the one or the other way. But like I said already above, I also like to provide APIs over various "levels", so from more native to more aggregating ones, I also support to have the native APIs available at SDK-API.
OK, we agree about this then.
Philip
-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Freitag, 5. Februar 2016 15:34 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com;
dev
el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated
geolocation
and navigation design document
Hi Andre,
On Thu, 2016-02-04 at 09:56 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
since I still do not know where the blocking factor is let me
give
some range of feedback, maybe one hits the point
- Apps do not change the system scope, they do not install stuff
(e.g. backends) into the system. They may ship a backend, but all that belongs and gets installed to its black box environment. However, they may exposes data to some already available system service via some SDK-API.
We agree on this. The backends for the SDK route list API in my diagram are provided by application bundles.
- App UI (like "Fuel Station application UI" or "Navigation
UI") belongs the "application bundle"
We agree on this. I did not show that in the diagram in order to
keep
it legible.
- So the Navi is completely handled as a App-Bundle covering the
"Backend" (including route planning) as also the "UI" in its own black box.
We agree on this. Again, I did not show that in the diagram in
order
to keep it legible.
- since the "navigation UI" belongs the nav app-bundle, it is
directly connected to its backend The Navi UI can use whatever black-box internal ways to interact with its backend to create
its
UI. Same like for each other App-Bundle. The Navi is just another App. However, in addition its proprietary backend may exposes
some
data to a SDK-API service (route-list "horizon"), and the backend may also consumes aggregated data form (this) SDK-API service.
OK, I have noted the potential for an arbitrary connection between the navigation backend and navigation UI.
We agree on the rest: in the diagram, the ‘backend provided by navigation application bundle’ exposes data to the SDK route list
API
(which is actually a service/process — it’s a box in the diagram).
It
can also consume data from that API, although that’s not shown in
the
diagram. There is nothing to prevent that.
- its not like discussed for libchamplain or tts or other topics,
where the "backends" reside in the OS scope (functionality
embedded
in the OS). In these areas the backend of choice gest decided by the system integrator at point in time of product definition (it
cannot
be changed by the User). In contrast to that, for navi we enable flexibility during runtime. Installing an app changes the
"backend
used". So the Navi App Bundle ships the backend and its UI, but does not change installations in the OS. The App bundle exposes data
to
the SDK.Route List (Horizon) APIs to other Apps. So we shift the responsibility by keeping the app-centric approach - from the integrator to the user and from OS-scope to App-scope.
We agree on this.
- With that flexibility, the User has the option to decides for
the
Navi of his choice.
We agree on this.
- if the backend is located in automotive domain, then this is
coupled/bundled with one (maybe build in) "Navi App".
We agree on this.
- The rout-list "horizon" API, is not primary used to create a
User- Interface for a "Navigation" Application, neither from other Apps nor from the App bundle who provides the "backend". The primary
purpose
for the route-list API "horizon" is _not_ to serve for the navigation build-in functionality. Its for location based services/Apps.
OK, I had been assuming it could be used for the navigation UI, but if the navigation UI and backend want to use an arbitrary connection
to
communicate routes, that’s fine (as agreed a few points above).
We agree on the fact that the SDK route list API (which you call ‘route-list API "horizon"’) is used for location-based services and applications.
- POIs transferred via the pipe mechanism lands in the App
specific
local "database" (not directly at the UI), the App takes over the data responsibility/management, its like an import. The App
decides
about if and how to persistently store it, when to delete etc. These data runs like all the other local app data though its app-
specific
business logic / functionality. Its even possible that these data gets only consumed by some algorithms and never lands natively at the UI.
We agree on this, although I have not discussed the possibility of applications storing points of interest in an internal database.
What
applications do with points of interest once they have received
them
is up to the application developer — they can store the POIs in a database, display them directly in the UI without storage, or
process
them without ever putting them in a UI, as you say. That’s why I haven’t mentioned databases.
- think about a setup w/o any navigation installed. Then there is
no navi backend installed. Nevertheless, the is a route-list
"horizon"
API where Apps can consume data from and expose data to
(accordant
to their app internal functional scope).
We agree on this: the SDK route list API still exists even if no navigation applications are installed. As I said: it’s a service provided by the SDK (and hence is represented as a box in the
diagram
I sent). It can be running and providing the SDK route list API to applications and services even if no backends are available from navigation application bundles (or other bundles).
- It could even be the case that some Apps who are not being a
"navigation App" provide some most probable path information to
the
horizon. Its not a route -since no destination is set and even no navigation installed), but guessing about the way ahead. It
could
be limited in length (e.g. only until next intersection, or a little ahead of this with even multiple pathes from each intersection, etc). And this can also be added in case a route is given, adding more information about alternative links at intersection could be benefitail for some other Apps to know. So finally its not only POI.
We agree on this: such applications could provide a backend for the SDK route list API just like navigation application bundles can.
so some questions:
- which "component" represents the glue (the framework) between
the
LBS-Apps (like Navi, Restaurants, Sightseeing, etc), to receive dedicated data from individual producers (LBS Apps), creates and maintains a combined data set, and deliver the data exposed as route- list "horizon" API to consumers (its not the "backend" located in the App Bundle if a a Navi App, this backend is itself a producer
only)
?
This is a combination of the SDK route list API (and the service which provides it, which is part of the SDK and provided by Apertis), and the POI API with its peer-to-peer connections from any other
application
which provides a points of interest interface.
In the design as I see it, there is no ‘combined data set’: the SDK route list API service maintains the route list which has been set
by
one of its backends (with the backend chosen by the user; typically
a
navigation application bundle), but it does not combine different routes. It could provide multiple alternative routes from the different backends, although, I suppose.
The ‘combined data set’ of POIs is formed at each application where it receives POIs from other applications — in the diagram, this is
where
all the red arrow heads meet. The application may combine these
POIs
in a database, or do whatever else it likes with them. Typically, it would combine them with the planned navigation route, which it has
received
from the SDK route list API (via the yellow arrows in the diagram).
(Btw, a Navi Backend from a proprietary Supplier may do not has
at
all any of the capabilities needed to aggregate POI data from various sources into a combined set. )
In the design there is no need for the navigation backend to aggregate POI data — that is done by the applications which are consuming the POI data (the heads of the red arrows in the diagram).
- in which format/way gets this data forwarded to this component
?
It does not need to be the pipe based POI mechanism only because we have it. Geoclue also deals with coordinates and nevertheless uses another kind of API to exchange information with its backends. On top its not only POIs, ist also links(streets) etc to be provided to the "horizon" framework.
The design recommends (in §7.6 of version 0.3.1 of the design) a D- Bus interface for the SDK route list API which exposes each possible route as an array of (latitude, longitude) coordinates.
Are the areas in the diagram where I’ve highlighted components
which
have responsibility for making decisions correct, in your understanding? These are the blue circles in the diagram.
Philip
-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Mittwoch, 3. Februar 2016 16:18 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; dev el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document
Hi Andre,
As far as I can tell, the design I suggested in my previous e-
does match your requirements for which components have responsibility for different decisions or pieces of information: • Applications choose which POIs to advertise, and the
navigation
UI displays them unconditionally (subject to rate limiting) • The route list API is provided by the SDK, in the system, and supports multiple backends — the backend might be provided by the navigation application bundle, but might instead be in the automotive domain, or something else • The navigation UI is just another application, and has no special powers or functionality • Applications choose which waypoints to send to the route list API to be added into the route — this might result in the user being prompted ‘do you want to add this waypoint into your route’, or they might be added unconditionally
I have attached a diagram of the system as I described it in my previous e-mail, and have attempted to highlight all the data
flows
and the decisions which drive them. (Apologies for the crudeness of
the
drawing; I did it rapidly.)
Please could you take a look and see where our understandings differ, and highlight specifically what the differences are.
Thanks, Philip
On Wed, 2016-02-03 at 14:16 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
Hi Philip, Thanks for your answer, but we are still not on the same page.
We
talking about different things. There are other parts beside feature requirements which
influence
the decomposition. Its seems for me that you are focusing on
features
and if the design/decomposition proposed is able to realize it. My focus is alignment with app-centric design, so responsibilities & dependencies (I only use features to make things more clear).
So
if you are saying the design can provide the feature, then that’s not what I am talking about. I am talking about the design does not fit to the non-function requirements (app-centric solution). Parts
of
the functionality belongs to the wrong responsibility or we even do need to split an entity into parts to deploy the responsibility to different parties. Since we are iterating in cycles a little bit and I start to
gets
doubts about the efficiency of this kind of mail threads, let
us
limit the iterations. If within a few next ones we do not conclude, then lets have a call about it. But for now let me try to
explain
my intention again via email: So yes, one can technically pass everything through the navigation App, delivering all POIs to the App as also requesting a consolidated data from it. That’s possible. And the design is done in that way. And that’s not the way how
it
shall be. So its not the question if the current design can
also
realize the mentioned features. The POI mechanism defined already was motivation by the update
of
the navi-database with data needed for route calculation. Only for that purpose. So for now, please forget the POI mechanism defined already. Now we are talking about the “route list”. Maybe the naming is not beneficial, internally we typically use the term “horizon”. Its dedicated scope is to carry information related to the
(expected)
vehicle position, starting from the current location up to expected future positons. This is where the term route-list comes into
the
game. The goal now is to provide a framework, where all apps
can
consume data from for their internal processing as also provide data to this framework (to enrich it). This all is also valid w/o any route available. In that case
the
data focus more around the current vehicle position. It is even
valid,
if there is no navigation app installed at all. There is nevertheless the current geo position available (e.g. from geoclue, and
maybe
even only on WLAN based positioning so without any GPS solution,
that
doesn’t matter). The navigation App is just another App, optionally producing data to that framework and/or consuming data from it (e.g. the information about the current route, including its intermediate destinations etc). And it could even be that multiple Apps, dealing with most probable pathes exposes information to this horizon (not only the Navi App currently maintaining the active route). The framework is completely independent of the developer of a particular Navigation App, this solutions is completely out of the scope/responsibility of the navigation provider. It belongs to the system, the OS. And yes, intermediate destinations are provided and handled by
a
navigation app, again via another mechanism (the scheme mechanisms, not the POI one). And if a new intermediate destination has
been
defined via this way, and the route has been updated, then the navi app can expose it to the said horizon framework. And another
App
can consume this new information about an intermediate destination for their scope and may also add new data to this framework accordingly. So what I am asking for is, to keep the POI mechanism as a way
of
choice for database updates, and to add an additional framework
–
which we can call “horizon” or something else - where Apps can produce data to as also consume data from it. The Navi App
shall
be able to provide its route list information to it and update it. Rgds Andre -----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Dienstag, 2. Februar 2016 18:27 An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com
;
dev el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: [Devel] Updated geolocation
and
navigation design document Hi Andre, Replies inline. I’ve trimmed a few of the parts of the e-mail which we agree on. On Tue, 2016-01-26 at 13:03 +0000, Barkowski Andre (CM-
CI1/PRM1)
wrote:
However, my understanding of https://wiki.apertis.org/Points_of_interest design is, that only
the
control flow runs via a central SDK service, but if allowed
it
establishes a private point-to-point channel (pipe) between
producer
App and consumer App (w/o any SDK service inbetween anymore). With that, the content itself (the POIs) are untouched form the so
called
"central POI service", the POIs are neither stored/cached,
nor
distributed by them. With that, the "SDK-Service" (central
POI
service) does _not_ return points of interest like
restaurants,
filling stations and tourist attractions. As also there is no capability to define filters in that request, since in an
app-
centric
approach the policies are belonging to the Source/Producer
App.
The SDK service itself only establishes private point to point connections.
That is correct. I guess when I’ve been saying ‘POI service’ or ‘POI system’ from the point of view of an application which is consuming POI data (such as the navigation UI, or another application which needs to display POIs), I would consider the ‘POI service/system’ to be the set of all applications which are providing POIs over peer-to-peer connections.
• Route list: a list of objects which describe the route for
a
navigation, i.e. the roads to take; this might include alternative routes; it _does_ include Point objects like intermediate destinations on the route so there are point type objects already included in that structure
as
also attributes/metadata for each object for further details.
Yes, although the metadata is limited to a description for the location and what type of point it is (start, waypoint, waypoint which
is
for routing only and isn’t a destination, final destination).
Please note, that the navigation "route-list" is something
different
than the navigation "guidance". The guidance focus on
detailed
description of turns ahead, the route-list has a different focus
it
describes the complete trip. So that’s 2 APIs and different structures/objects. I would recommend to adopt the document accordingly.
Noted — I will include this in the next update to the document.
And what I am talking about now is, that apps shall be able
to
augment the route list returned by the SDK-API . The route
list
exposed via the route-list SDK-API for sure gets provided
(and
updated) by the navigation app (somehow similar like it can
do
it
for
the geo-position to geo-clue), but Apps can augment data to
it.
The APIs realizing this capability have second priority for
me,
but nevertheless I like to cover it right from the
beginning from
conceptual point of view. With "create some functionality" I do mean the samples
provided
to explain use-cases where Apps consume and augment POIs to the route list:
- a Weather App may consumes Intermediate Destination
Information from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places
- 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 information of gasoline stations
in
the route list to add recommended cafeterias into the route list
to
align
the breaks for the driver
- a restaurant app may 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
a
POI location available in route list. The major thing is, in an app centric approach, the policies are coupled with the source of the data. Its _not_ the navigation app which orchestrates the other apps - like in a systemic
client-
server
model, what to deliver. This limits the capabilities to
fantasy
provided by the navigation app developer as also his capabilities
and
development work. In an app-centric approach its completely vice versa, each app focus on its essential service, a navigation calculates the route. That’s it. And a restaurant app deals
the
POI,
and handles all policies and User Interaction to
choose/handle
them,
even though they may finally gets used to set a new
destination
or they land in the route list.
OK. I think this fits with my proposed design and the Points of Interest design as they currently stand, although I should clarify things. The route list API continues to provide only the list of roads
to
take (i.e. the geometry of the route) as I described in my previous
e-
mail. Applications which provide POIs query this API to find out the current route, as described in the fourth paragraph of https://wiki.apertis.org/Points_of_interest#Recommendations. The navigation UI uses interface discovery to find applications which provide POI data. It then queries them (via peer-to-peer connections) for general and specific POIs, as described in the POI design. Its shall not be the responsibility of the Navigation to
requests
it/or not. Its done by the Providing Apps autonomously. It shall not depend on the code (responsibility) of the navigation App at all if this The logic for working out what POIs to send to the navigation
UI
lies within each application. The navigation UI does no filtering based on content (though for security reasons it might want to apply
some
rate limiting to prevent DoS attacks). It simply displays all the
POIs
it receives. It might be possible for an application to add metadata to a
POI
it sends to the navigation UI to say ‘please add this POI as a waypoint’, in which case the navigation UI could prompt the user about it (or add the destination anyway, or ignore it — this policy is up to the navigation UI developer). If the POI is added as a waypoint in the route, the SDK route list API would signal an update to the route, which would be received by the navigation UI and all
applications
providing POIs to it. This would allow for the coupon use case
—
if a restaurant gets added as a waypoint, the coupon application
could
start emitting a POI for using coupons there. If another application wants to display the same map view as
the
navigation UI, showing the route and POIs on it, it has to make the same API calls as the navigation UI: a call to the SDK route
list
API to get the route; and interface discovery followed by peer-to- peer retrieval of POIs from other applications. So, in short, the ‘augmented route list’ is provided by a combination of the route list API and the POI system (i.e. retrieving POIs from other applications using peer-to-peer connections). I hope that makes sense? Philip
-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Montag, 25. Januar 2016 15:56 An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.c
om
;
dev
el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document Hi Andre, On Fri, 2016-01-22 at 17:16 +0000, Barkowski Andre (CM- CI1/PRM1) wrote:
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.
To check, what do you mean by the terms ‘POI service’ and ‘route list’? I interpret them as: • POI service: an SDK service which returns points of
interest
like
restaurants, filling stations and tourist attractions • Route list: a list of points which describe the plotted route
for
a navigation, i.e. the roads to take; this might include alternative routes; it does not include nearby POIs Andre: hope this is answered above
Let me add:
we do _not_ need a central POI service, or viceversa
I
am
not aware about a related requirement.
All suggestions I have made about POI handling in the context of
the
Geolocation and Navigation document have been references to
the
existing https://wiki.apertis.org/Points_of_interest design.
I
am
not
suggesting changes to that design, nor am I suggesting
copying
parts
of it into this design (or any of the navigation APIs). Andre: I see.
We do have the already mentioned 3 Use cases and the mechanisms discussed covers the use-cases already perfectly
- for in app UI browsing: libchamlain. We have it, fine.
Yes.
- 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.a
pe
rt is
.o
rg
/Data_sharing ) again, we have it designed already.
Yes.
- 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)
I think this is covered by the SDK navigation route guidance API (§7.6 of version 0.3.1 of the document), if we are using the same meaning for ‘route list’ (see above). Andre: see above, I think we do need 2 API scopes, one for “route- list” one for “guidance”
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.
What do you mean by ‘create some functionality’? In the design as it stands currently, applications cannot augment
the
route list returned by the SDK navigation route guidance API. They can augment the list of POIs returned by the POI API (https://wik
i.
ap er
ti
s. org/Points_of_interest). Andre: see above, I do mean things like that
- a Weather App may consumes Intermediate Destination
Information from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places
- 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 information of gasoline stations
in
the route list to add recommended cafeterias into the route list
to
align
the breaks for the driver
- a restaurant app may 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
a
POI location available in route list.
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.
For clarity, which API do you mean by ‘it’? Andre: I do mean the capability for Apps to augment POIs into the Route-List
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.
I’ve put a few replies below too.
-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.u
k]
Gesendet: Mittwoch, 20. Januar 2016 16:57 An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch
.c
om > ;
dev
el@lists.apertis.org Betreff: Re: AW: AW: AW: [Devel] Updated geolocation and
navigation
design document
> 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.
OK, we would have to add a separate SDK API for handling guidance notifications, similar to the existing
org.freedesktop.Notifications
API for handling other notifications from applications. I
will
include a recommendation for that in the next update to the document. Andre: agreed
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.
Sorry, when I said “if other applications want to display something similar to the guidance UI” I meant something more like “if other applications want to display the current route, or the
current
route
plus nearby POIs”. Andre: I would expect this is build-in behind the scene into libchamplain. So by using libchamplain, Apps get this information already embedded. Similar like they get the current vehicle
position
(from geoclue) already well embedded into libchamplain. The
usecases
for Apps to use route list information is the stuff mentioned
above.
Let me repeat to prevent misunderstanding:
- a Weather App may consumes Intermediate Destination
Information from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places
- 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 information of gasoline stations
in
the route list to add recommended cafeterias into the route list
to
align
the breaks for the driver
- a restaurant app may 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
a
POI location available in route list.
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.
I don’t think I can fully understand these points without agreeing
on
the terminology at the top of the e-mail. Andre: ok, hope my comments given where helpful in that regard. In the current version of the design, these use cases are handled
by:
• The gasoline station application exposes gasoline stations as points of interest via the POI API (https://wiki.apertis.org/Points_
of
_i nt
er
es t). • The restaurant application exposes restaurants as points
of
interest via the POI API (https://wiki.apertis.org/Points_of_interest)
.
• The navigation application contains the logic to:
- Detect where in the route the vehicle is likely to need
refuelling, query the POI API (https://wiki.apertis.org/Points_of_interes
t)
for gasoline stations, and add them to the route.
- Detect when in the route the driver is likely to need
food,
query
the POI API (https://wiki.apertis.org/Points_of_interest) for restaurants, and add them to the route. I can’t think of a sensible way of handling coupons at the moment. They don’t really fit into any of the existing APIs. The design is this way round, rather than allowing the restaurant
and
gasoline applications to ‘insert’ recommendations into the route
list
because it leaves the navigation application in charge of
which
restaurants (for example) are shown. It means the code for determining when is ‘a good time to stop for food’ is in one place (the navigation application) rather than many (each restaurant application), each
of
which could end up using different definitions of when is ‘a good time to stop for food’ in order to gain competitive advantage. Andre: like said above, the design philosophy is an app-
centric
solution is, to bundle the policy / logic within the provider app.
So
its not one central intelligence, orchestrating all others,
its
vice
versa all the others are providing things accordant to their implemented logic. Apps can compete in providing the same service with another policy or using another service with a similar policy. The user decides by choosing the App which fits best his
needs.
And he can do in the smallest granularity, per App . So he is
able
to adopt the overall solution by making dedicated decisions per source (App). (Above, I am using ‘navigation application’ to mean the
entire
navigation application bundle, including any UIs, agents, or
services
which it provides.) Philip