[Devel] Updated geolocation and navigation design document

[Barkowski Andre (CM-CI1/PRM1)]

Hi Philip,

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.
- App UI (like "Fuel Station application UI" or "Navigation UI")  belongs the "application bundle"
- 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. 
- 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. 

- 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.
- With that flexibility, the User has the option to decides for the Navi of his choice.
- if the backend is located in automotive domain, then this is coupled/bundled with one (maybe build in) "Navi App". 

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

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

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

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) ? 
(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 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. 

Rgds
Andre



-----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>; devel 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.com>; 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.uk]
> > Gesendet: Montag, 25. Januar 2016 15:56
> > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>;
> 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.apertis
> .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://wiki.aper
> 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.uk]
> > > Gesendet: Mittwoch, 20. Januar 2016 16:57
> > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>;
> > 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/Points_of_int
> 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_interest) 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/20160204/5e3bed98/attachment-0001.bin>