[Devel] Updated geolocation and navigation design document
Barkowski Andre (CM-CI1/PRM1)
Andre.Barkowski at de.bosch.com
Thu Feb 18 12:25:16 GMT 2016
Hi Philip,
ok, lets do it in this way.
I fear I will not be able to spend enough time to provide more information about the "complexity of algorithms", but I will put it on my list and if I get a chance I will follow up on this. But please do not expect something in near/mid term.
Beside that, the approach mentioned by you for the "iteratively/recursively enrichment of a common data set" is exactly what I mean with theoretically. This leads to a worst case of data traffic and processing which I think is neither feasible nor appropriate for an embedded device: if you have tens to hundreds of LBS Apps/Agents, each one with hundreds to thousands of POIs, all that data transferred between all combinations of sender/receiver combinations and on top this also recursively, than that’s what I referred to being only a theoretical solution.
And in regard to deterministic: its not only the algorithm itself, we transport lots of single data objects and caused by the distributed approach with dedicated channels, the inflow sequence of objects differs per App, and this may lead to a different result already. And already a single fault count. And object equality is not only reduced to having the exact same geo-coordinate. Objects coming from various sources and do not share a joint common basis/reference, so they are identically even though they have a different geo-location. So its much more to validate to conclude on equality and the conclusion may also depends on objects already available in your dataset. So you may conclude in you algorithm that a new entity is equal or not depending on what you have already received. For automotive usage consistency is more important than absolute correctness, because we have to take care not to distract the driver.
Rgds
Andre
-----Ursprüngliche Nachricht-----
Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk]
Gesendet: Donnerstag, 18. Februar 2016 12:12
An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>; devel at lists.apertis.org
Betreff: Re: AW: AW: AW: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document
Hi Andre,
On Wed, 2016-02-17 at 16:05 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
> 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)
Entirely correct.
> - the initial functional scope of "horizon" API will be limited,
> further extension will come over time in future
OK.
> - my preference is founded on my experience of navigation based
> algorithms and data structure only, no detailed analysis has been
> done.
I suggest we go with the library approach, then, and consider
performing some more detailed analysis of the performance later on. If
performance does turn out to be a problem, converting the library into
a daemon should not be too hard (the complex code will have already
been written, and it should be a matter of designing a suitable D-Bus
API and adding that).
> 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
Makes sense to me.
> That said, for me its somehow similar like the media solution, with
> some grillo / library based SDK-API providing access to a central
> dataset.
Correct.
> 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.
Your point about determinism is a good point, and something we will
have to work to avoid. I’ll add it to the document as something to be
aware of when implementing the code.
I think the I/O and memory costs of aggregating at each application
rather than in a daemon will be the same, if we assume that most POIs
will not be merged, since the applications providing them are not
likely to produce duplicates. In both cases, each application has to
receive roughly N points of interest over D-Bus, and has to store them
in memory so they can be used and displayed within the application.
The thing which will differ more between the centralised and
decentralised approaches is CPU usage — but I was assuming that the
cost of aggregating points of interest is reasonably low (see below for
more thoughts about this).
> From my point of view, you underestimate the effort, complexity and
> runtime dependencies for map-matching algorithms.
Possibly — can you point me towards some example algorithms or code
which does what you are thinking about?
At the moment, I’m thinking that aggregation will be a matter of
finding points of interest which share a title and coordinates and
hence are probably duplicates and should be merged. Is it more complex
than this?
> 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.
Indeed, the library will be performing aggregation regardless of
whether applications are running, if it is used in the system chrome.
However, this doesn’t counter the argument against a centralised
approach, which is that – assuming most points of interest do not get
aggregated, and assuming a low number of POI producers compared to
consumers – a centralised approach requires twice the IPC bandwidth, as
all points of interest need to be sent into the daemon and then sent
out again.
Anyway, as you said, we can always turn the horizon library into a
wrapper around a D-Bus interface in future after doing performance
analysis.
> - 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.
It is possible and feasible: application A (let’s assume it’s a
restaurant application) emits a POI for a restaurant. Application B (a
fuel station application) is querying for POIs, and receives the POI
from application A. It determines that there’s a fuel station next to
the restaurant, and emits that as a POI. Application C (a coupon
application) is querying for POIs as well, and receives both POIs for
the restaurant and fuel station. It determines that there are coupons
available for fuel if you eat at the restaurant, and emits a POI for
the coupons.
> 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.
Indeed. I would be interested to know more details about what
algorithms you think will be needed for aggregating points of interest,
as mentioned above. Otherwise, I think we can conclude on this design —
I will make minor updates to it to mention the need to avoid
inconsistencies in horizon data when processing it in multiple
applications; and the need for the horizon API to be usable outside of
applications (for example, in the system chrome).
Philip
> -----Ursprüngliche Nachricht-----
> Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk]
> Gesendet: Montag, 15. Februar 2016 17:37
> An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>; dev
> el at 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 at collabora.co.uk]
> > Gesendet: Dienstag, 9. Februar 2016 15:50
> > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>;
> > dev
> > el at 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 at collabora.co.uk]
> > > Gesendet: Freitag, 5. Februar 2016 15:34
> > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>;
> > dev
> > > el at 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 at collabora.co.uk]
> > > > Gesendet: Mittwoch, 3. Februar 2016 16:18
> > > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com
> > > > >;
> > > > dev
> > > > el at 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-
> > mail
> > > > 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 at collabora.co.uk]
> > > > > Gesendet: Dienstag, 2. Februar 2016 18:27
> > > > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.c
> > > > > om
> > > ;
> > > > > dev
> > > > > el at 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 at collabora.co.u
> > > > > > k]
> > > > > > Gesendet: Montag, 25. Januar 2016 15:56
> > > > > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch
> > > > > > .c
> > om
> > > > > > > ;
> > > > > dev
> > > > > > el at 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 vice
> > versa
> > > > > > > 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
> > > > > > > 1) for in app UI browsing: libchamlain. We have it, fine.
> > > > > > Yes.
> > > > > > > 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
> > > > > > > .a
> > pe
> > > > > > > rt
> > > > > > > is
> > > > > .o
> > > > > > rg
> > > > > > > /Data_sharing )
> > > > > > > again, we have it designed already.
> > > > > > Yes.
> > > > > > > 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)
> > > > > > 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://w
> > > > > > ik
> > 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 at collabora.co
> > > > > > > .u
> > k]
> > > > > > > Gesendet: Mittwoch, 20. Januar 2016 16:57
> > > > > > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bos
> > > > > > > ch
> > .c
> > > > > > > om
> > > > > > > > ;
> > > > > > dev
> > > > > > > el at 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/Point
> > > > > > s_
> > 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_interes
> > > > > > t)
> > .
> > > > > > • 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_inter
> > > > > > es
> > 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
-------------- 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/20160218/ce4c783e/attachment-0001.bin>
More information about the Devel
mailing list