<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version rmj.rmm.rup.rpr">
<TITLE>AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Hi Philip,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Thanks for your answer, but</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">w</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">e are still not on the same page</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">. W</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">e</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">talking about different things. </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">There</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">are</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">other parts beside feature requirements which influence</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">decomposition. Its seems for me that you are</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">focusing</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> on</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">features and if the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">design/decomposition</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">proposed</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">is</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> able to realize</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">it</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">My focus is</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">alignment with app-centric design, so responsibilities & dependencies</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> (I only</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">use features</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">to make things more clear)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">So if you are saying the design can provide the feature, then that’s not what I am talking about. I</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> am talking</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> about</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">the design does not fit to the non-function requirements (app-centric solution)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">. Parts of the functionality</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">belongs to the wrong responsibility or we</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">even</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">do need to split an entity into parts to deploy the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">responsibility to different parties</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Since we</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">are</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">iterating in cycles</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> a little bit</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">and I start to gets doubts about the efficiency of this kind of mail threads</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">, 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</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">my intention again via email:</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">So yes, one can</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> technically</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">pass everything through the navigation App, delivering all POIs to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">the App</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">as also requesting a consolidated</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">data from it.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">That’s possible. </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">current design</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">can also realize the mentioned features.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">The POI mechanism defined already was</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">motivation</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">by the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">update</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">of the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">navi-database</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">with data needed</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">for</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">route calculation. Only for that purpose.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">So for now</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">, please forget the POI mechanism defined already.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Now we are talking about the “route list”. Maybe the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">naming</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">is</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">not beneficial</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">, internally we typically</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">use</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">the term</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">“horizon”.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">Its dedicated scope is to carry</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">information related to the (expected) vehicle position, starting from the current location up to expected future positons. This is where</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">term</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">route</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">-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).</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">This all is also valid w/o any route available. In that case the dat</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">a</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> focus more around the current vehicle position.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">It is even</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">valid</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">, if there is no navigation</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">app</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">installed at all. There is nevertheless the current geo position available (e.g. from geoclue, and maybe even</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">only on</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">WLAN</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">based positioning so without any GPS solution, that doesn’</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">t</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">matter).</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">The navigation App is just another App, optionally producing data to that framework and/or consuming data from it (e.g. the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">information about the current route</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">, including its intermediate destinations etc</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">).</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">And it could even be that multiple Apps, dealing with most probable pathes</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">exposes</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">information to this horizon (not only the Navi App currently maint</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">a</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">ining the active route</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">The framework</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">is</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">completely</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">independent of the developer of</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">a particular</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">Navigation App, this solutions is</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">completely</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> out of the scope/</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">responsibility</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">of the navigation provider.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">It belongs to the system, the OS.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">And yes, intermediate destinations are provided and handled by</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">a</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial"> navigation</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> app</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">, again via another mechanism</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">(</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">the scheme mechanisms,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">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 sa</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">i</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">d horizon framework. An</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">d</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">an</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">other App can consume this new information about an intermediate destination for their scope and may also add new data to this</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">framework</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">accordingly.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">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</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">c</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">all</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">“</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">horizon</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">”</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> or something else</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> -</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> where Apps can produce data to as also consume data from it.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">The Navi App shall be able to provide its route list</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">information</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">to it and update it.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Rgds</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Andre</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="de-de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="de-de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">-----</FONT></SPAN><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Ursprüngliche Nachricht-----<BR>
Von: Philip Withnall [<A HREF="mailto:philip.withnall@collabora.co.uk">mailto:philip.withnall@collabora.co.uk</A>]<BR>
Gesendet: Dienstag, 2. Februar 2016 18:27<BR>
An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; devel@lists.apertis.org<BR>
Betreff: Re: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document</FONT></SPAN><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Hi Andre,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Replies inline. I’ve trimmed a few of the parts of the e-mail which we</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">agree on.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">On Tue, 2016-01-26 at 13:03 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> However, my understanding of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="https://wiki.apertis.org/Points_of_interest"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial"> design is, that only the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> control flow runs via a central SDK service, but if allowed it</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> establishes a private point-to-point channel (pipe) between producer</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> App and consumer App (w/o any SDK service inbetween anymore). With</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> that, the content itself (the POIs) are untouched form the so called</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> "central POI service", the POIs are neither stored/cached, nor</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> distributed by them. With that, the "SDK-Service" (central POI</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> service) does _not_ return points of interest like restaurants,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> filling stations and tourist attractions. As also there is no</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> capability to define filters in that request, since in an app-centric </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> approach the policies are belonging to the Source/Producer App. The</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> SDK service itself only establishes private point to point</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> connections.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">That is correct. I guess when I’ve been saying ‘POI service’ or ‘POI</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">system’ from the point of view of an application which is consuming POI</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">data (such as the navigation UI, or another application which needs to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">display POIs), I would consider the ‘POI service/system’ to be the set</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">of all applications which are providing POIs over peer-to-peer</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">connections.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">> • Route list: a list of objects which describe the route for a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation, i.e. the roads to take; this might include alternative</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> routes; it _does_ include Point objects like intermediate</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> destinations on the route</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> so there are point type objects already included in that structure as</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> also attributes/metadata for each object for further details.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Yes, although the metadata is limited to a description for the location</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">and what type of point it is (start, waypoint, waypoint which is for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">routing only and isn’t a destination, final destination).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">> Please note, that the navigation "route-list" is something different</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> than the navigation "guidance". The guidance focus on detailed</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> description of turns ahead, the route-list has a different focus - it</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> describes the complete trip. So that’s 2 APIs and different</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> structures/objects. I would recommend to adopt the document</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> accordingly.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Noted — I will include this in the next update to the document.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> And what I am talking about now is, that apps shall be able to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> augment the route list returned by the SDK-API . The route list</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> exposed via the route-list SDK-API for sure gets provided (and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> updated) by the navigation app (somehow similar like it can do it for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the geo-position to geo-clue), but Apps can augment data to it.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The APIs realizing this capability have second priority for me, but</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> nevertheless I like to cover it right from the beginning from</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> conceptual point of view.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> With "create some functionality" I do mean the samples provided to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> explain use-cases where Apps consume and augment POIs to the route</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> list:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a Weather App may consumes Intermediate Destination Information</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> from Route List to show entries on top of the user stored locations</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> in its UI to inform the User about weather at this places</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a gasoline station app adds a refueling stop into the route list</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> for a location to be reached at a time where the car runs low on fuel</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a restaurant app may uses information of gasoline stations in the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route list to add recommended cafeterias into the route list to align</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the breaks for the driver</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a restaurant app may decides to add restaurant POIs as</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> recommendations into the route list for a location to be reached at a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> time where a break would be wise</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a installed “coupon” app may add available discounts available at a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POI location available in route list.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The major thing is, in an app centric approach, the policies are</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> coupled with the source of the data. Its _not_ the navigation app</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> which orchestrates the other apps - like in a systemic client-server</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> model, what to deliver. This limits the capabilities to fantasy</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> provided by the navigation app developer as also his capabilities and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> development work. In an app-centric approach its completely vice</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> versa, each app focus on its essential service, a navigation</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> calculates the route. That’s it. And a restaurant app deals the POI,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> and handles all policies and User Interaction to choose/handle them,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> even though they may finally gets used to set a new destination or</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> they land in the route list.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OK. I think this fits with my proposed design and the Points of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Interest design as they currently stand, although I should clarify</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">things.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">The route list API continues to provide only the list of roads to take</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">(i.e. the geometry of the route) as I described in my previous e-mail.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Applications which provide POIs query this API to find out the current</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">route, as described in the fourth paragraph of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><A HREF="https://wiki.apertis.org/Points_of_interest#Recommendations"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest#Recommendations</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">The navigation UI uses interface discovery to find applications which</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">provide POI data. It then queries them (via peer-to-peer connections)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">for general and specific POIs, as described in the POI design.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">It</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">s</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"></FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">shall not be the responsibility of the</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">Navigation</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">to</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">requests it</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">/or not</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"></FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>
<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Its done by the Providing Apps</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">autonomously.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"></FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>
<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">It shall not depend on the code (</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">responsibility</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">)</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"></FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">of the navigation App at all if this</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">The logic for working out what POIs to send to the navigation UI lies</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">within each application. The navigation UI does no filtering based on</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">content (though for security reasons it might want to apply some rate</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">limiting to prevent DoS attacks). It simply displays all the POIs it</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">receives.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">It might be possible for an application to add metadata to a POI it</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">sends to the navigation UI to say ‘please add this POI as a waypoint’,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">in which case the navigation UI could prompt the user about it (or add</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">the destination anyway, or ignore it — this policy is up to the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">navigation UI developer). If the POI is added as a waypoint in the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">route, the SDK route list API would signal an update to the route,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">which would be received by the navigation UI and all applications</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">providing POIs to it. This would allow for the coupon use case — if a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">restaurant gets added as a waypoint, the coupon application could start</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">emitting a POI for using coupons there.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">If another application wants to display the same map view as the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">navigation UI, showing the route and POIs on it, it has to make the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">same API calls as the navigation UI: a call to the SDK route list API</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">to get the route; and interface discovery followed by peer-to-peer</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">retrieval of POIs from other applications.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">So, in short, the ‘augmented route list’ is provided by a combination</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">of the route list API and the POI system (i.e. retrieving POIs from</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">other applications using peer-to-peer connections).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">I hope that makes sense?</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Philip</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> -----Ursprüngliche Nachricht-----</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Von: Philip Withnall [</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:philip.withnall@collabora.co.uk"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">mailto:philip.withnall@collabora.co.uk</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">]</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Gesendet: Montag, 25. Januar 2016 15:56</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> An: Barkowski Andre (CM-CI1/PRM1) <</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:Andre.Barkowski@de.bosch.com"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Andre.Barkowski@de.bosch.com</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">>; dev</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="mailto:el@lists.apertis.org"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">el@lists.apertis.org</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Betreff: Re: AW: AW: AW: AW: [Devel] Updated geolocation and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation design document</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Hi Andre,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> On Fri, 2016-01-22 at 17:16 +0000, Barkowski Andre (CM-CI1/PRM1)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> wrote:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Hi Philip,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > I feel we are still not fully on the same page. We closed some gaps</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > lately (in regard to the assist-window), but it seems to me that we</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > still have a gap in regard to POI handling itself.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > So summarize, let me go one step back and start with</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - POI service is _not_ equal to route-list.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > I am talking about a route list, you are talking about a central</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> poi</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > service.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> To check, what do you mean by the terms ‘POI service’ and ‘route</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> list’?</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I interpret them as:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> • POI service: an SDK service which returns points of interest like</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> restaurants, filling stations and tourist attractions</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> • Route list: a list of points which describe the plotted route for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation, i.e. the roads to take; this might include alternative</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> routes; it does not include nearby POIs</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre: hope this is answered above</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Let me add:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - we do _not_ need a central POI service, or vice versa I am</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > not aware about a related requirement.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> All suggestions I have made about POI handling in the context of the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Geolocation and Navigation document have been references to the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> existing</FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="https://wiki.apertis.org/Points_of_interest"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial"> design. I am not</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> suggesting changes to that design, nor am I suggesting copying parts</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> it into this design (or any of the navigation APIs).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre: I see.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > We do have the already mentioned 3 Use cases and the mechanisms</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > discussed covers the use-cases already perfectly</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > 1) for in app UI browsing: libchamlain. We have it, fine.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Yes.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > 2) for app import / handover: Pull mode for various types of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> content</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > – also TPEG based POI data -</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> ></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="https://wiki.apertis.org/Points_of_interest"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > (For completion there is also a push mode for various types of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > content – so far no need for TPEG support - </FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="https://wiki.apertis.o"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.o</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> rg</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > /Data_sharing )</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > again, we have it designed already.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Yes.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > 3) now we add the route-list to the SDK-API, where I also ask to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > provide capabilities to add POIs to it (independent from the navi-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > app)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I think this is covered by the SDK navigation route guidance API</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (§7.6</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> of version 0.3.1 of the document), if we are using the same meaning</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> ‘route list’ (see above).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre: see above, I think we do need 2 API scopes, one for “route-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> list” one for “guidance”</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > In any case we do need the route list, it has originally nothing to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > do with the POI discussion. Apps shall be able to consume</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> information</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > about the current route and to create some functionality. That the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > purpose of the route list essentially.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> What do you mean by ‘create some functionality’?</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In the design as it stands currently, applications cannot augment the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route list returned by the SDK navigation route guidance API. They</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> can</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> augment the list of POIs returned by the POI API (</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="https://wiki.aperti"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.aperti</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> s.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> org/Points_of_interest).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre: see above, I do mean things like that</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a Weather App may consumes Intermediate Destination Information</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> from Route List to show entries on top of the user stored locations</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> in its UI to inform the User about weather at this places</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a gasoline station app adds a refueling stop into the route list</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> for a location to be reached at a time where the car runs low on fuel</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a restaurant app may uses information of gasoline stations in the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route list to add recommended cafeterias into the route list to align</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the breaks for the driver</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a restaurant app may decides to add restaurant POIs as</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> recommendations into the route list for a location to be reached at a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> time where a break would be wise</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a installed “coupon” app may add available discounts available at a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POI location available in route list.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Based on that scope, I am asking for the additional functionality</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > add Metadata/Content from Apps directly to it, especially POIs. Its</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > neither a first priority nor will it dramatically change the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> design.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Its simple an add-on. We can even decide to implement it later.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> For clarity, which API do you mean by ‘it’?</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre: I do mean the capability for Apps to augment POIs into the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Route-List</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Similar stuff is valid for the guidance & assist window discussion.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > The APIs for the “guidance” (which is “just another notification</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > style API for a dedicated purpose”) as also the assist window</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (which</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > is just another system chrome application where for example the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> data</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > exposed via the guidance notification style SDK-API lands in) are</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > optional and don’t have side effects to other SDK-APIs. So we can</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > implementation wise realize it in a later step, its not of first</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > priority. However, I like to have a common understanding about the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > overall scope early.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > If we provide capabilities to add metadata into an available route-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > list to Apps, other Apps (than the navi app) can add additional</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > content/ additional metadata to available content, for example POIs</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > into a currently shared route list. Since we have already</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > libchamplain and also the Point_of_interest and sharing mechanisms</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > design, My focus is on just one more method for that route-list. I</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> am</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > _not_ talking about any big thing, especially not about a central</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POI</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > service.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > I would like to propose we serialize the discussion. How about</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> first</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > finalizing the solution for the route list, including POIs into it</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > from Apps via an SDK API.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Then reflect, for what a central POI service could be beneficial ?</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > I have embedded some comments below in green.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I’ve put a few replies below too.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > -----Ursprüngliche Nachricht-----</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Von: Philip Withnall [</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:philip.withnall@collabora.co.uk"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">mailto:philip.withnall@collabora.co.uk</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">]</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Gesendet: Mittwoch, 20. Januar 2016 16:57</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > An: Barkowski Andre (CM-CI1/PRM1) <</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:Andre.Barkowski@de.bosch.com"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Andre.Barkowski@de.bosch.com</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">>;</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> dev</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> ></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="mailto:el@lists.apertis.org"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">el@lists.apertis.org</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Betreff: Re: AW: AW: AW: [Devel] Updated geolocation and navigation</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > design document</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> ></FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Please keep also in mind, that the navigation app itself is</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> somehow</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > special in regard to their output. Beside provides some UI to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > control</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > its functions like all the other apps (e.g. media player), the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > “route</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > guidance” information is very special. In addition to a black box</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > build-in solution for the route guidance - like all the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> smartphone</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Smartphone solutions realizing today – (on prompt the guidance is</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > only acoustic or an app-change transition to the navigation app</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > appears) we will go a step forward for this driver related</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > information. The guidance will be presented to the user</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> independent</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > of the current App in use in foreground. So you can “leave” the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > navi-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > app but the guidance shall continue. In fact we influence the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > internal design by requesting an agent to be provided by the app-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > developer to deliver these data. And that’s not only an</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> acoustical</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > prompt, its also data which gets finally a visual representation</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > (turn icons, lane information, etc). In this approach via an SDK-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > API</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the rendering gets done by some system service. Its more like a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > “notification”/“dialog-box”/“status framework” stuff (please have</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > look to the running status framework and the relation to assist</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > framework too). So the navigation App provides its data as output</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > some SDK-API. In fact part of this is the route list, which</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> finally</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > land in that guidance dialog. Lets call it assistance window –</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > driver</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > related information.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > I see. The way I would recommend doing this in the design is to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > implement the guidance UI separately from the navigation UI. It</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> could</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > potentially be part of the same application bundle, or part of a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > different one, or even implemented as part of the system chrome.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Andre: to be honest, this all is optional. A navi app developer can</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > decide to implement the guidance in its local app-bundle scope.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Then</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the UI appears within its own App Screen Area.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > However, since it is beneficial (independent from the POI or Assist</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Window Discussion) that the guidance portion is separated from the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > rest of the full-fledge App (because it enables us to handle a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > separated executable with its own lifecycle, which means we can</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> keep</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > only that part running in background instead of the Full App) we</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > should ask for an Agent for it. The App developer can decide to do</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> so</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > or not. So the requirement for isolating the Guidance into an Agent</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > is already valid w/o all the discussion about POIs and/or Assist</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Window.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > On top of that we like to also support an assist window solution as</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > part of our system. Therefore we will provide a notification style</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > similar API for driver related information. Guidance data will be</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > covered by it, and if a Navi App developer decided to use this SDK-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > API, the guidance information will land there (but also information</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > from route list will land in such an assist window). Similar like</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > mentioned above, we like to ask the developer to provide an agent</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the guidance data. However, the assist window (the UI for the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > guidance) is finally a system chrome element and not deployed with</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the App bundle. It belongs to the OS and gets distributed with it.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> OK, we would have to add a separate SDK API for handling guidance</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> notifications, similar to the existing org.freedesktop.Notifications</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> API for handling other notifications from applications. I will</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> include</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> a recommendation for that in the next update to the document.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre: agreed</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > The guidance UI would take data from the SDK points of interest</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> API,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > and from the SDK navigation route guidance API (§7.6). This would</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > allow</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > it to render the route (from the guidance API), and points of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > interest</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > along the way (from the PoI API).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > The navigation UI (where the driver chooses their destination and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > plans</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the route) may retrieve points of interest from the SDK, or may</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > choose</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > not to if the developer thinks they will be distracting.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > i.e. The SDK API you are suggesting for the data from the guidance</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> UI</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > is effectively the points of interest API plus the navigation route</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > guidance API.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Andre: like said, its not the “points_of_interest” API, its from</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > route-list API.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > To this route list, other apps can directly add further data.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> This</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > is</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > _not_ forwarded to the navi-app, it does not modify the route</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> list</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > nor does it gets stored by the navi-app. The navi app don’t has</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> any</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > interest in getting and managing it. This data, gets provided by</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > source app to the rout–list and with that finally rendered to the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > user by some system service (assist window). On the other hand,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > other</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > apps can consume this enriched route list again for their build-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> in</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > functions and policies. Its all outside the navigation, the navi</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > only</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > provides the initial foundation.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > That’s possible due to the split between the navigation UI and the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > guidance UI. The navigation UI can choose to not query for points</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > interest, or can heavily filter the PoI requests it makes.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Conversely,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the guidance UI can query for lots of PoIs.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > If other applications want to display something similar to the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > guidance</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > UI, they must make the same navigation route guidance API and PoI</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> API</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > queries as made by the guidance UI. This should be simple to do,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > allows each application to further customise the points of interest</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > they display.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Andre:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > to be honest, the use-cases behind that stuff is _not_ that another</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > app will do something similar like the guidance UI.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Sorry, when I said “if other applications want to display something</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> similar to the guidance UI” I meant something more like “if other</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> applications want to display the current route, or the current route</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> plus nearby POIs”.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre: I would expect this is build-in behind the scene into</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> libchamplain. So by using libchamplain, Apps get this information</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> already embedded. Similar like they get the current vehicle position</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (from geoclue) already well embedded into libchamplain. The usecases</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> for Apps to use route list information is the stuff mentioned above.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Let me repeat to prevent misunderstanding:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a Weather App may consumes Intermediate Destination Information</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> from Route List to show entries on top of the user stored locations</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> in its UI to inform the User about weather at this places</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a gasoline station app adds a refueling stop into the route list</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> for a location to be reached at a time where the car runs low on fuel</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a restaurant app may uses information of gasoline stations in the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route list to add recommended cafeterias into the route list to align</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the breaks for the driver</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a restaurant app may decides to add restaurant POIs as</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> recommendations into the route list for a location to be reached at a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> time where a break would be wise</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - a installed “coupon” app may add available discounts available at a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POI location available in route list.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Other Apps uses information form that API for their essential</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > service, e.g. if an App of a weather service does know intermediate</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > destinations from the route list, it may decides to show entries on</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > top of the stored locations for current destination and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> intermediate</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > destinations (in todays list you have the current positon for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> example</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > as a default, this app could extend that approach depending on</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> stuff</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > from the route list).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Or if a gasoline station app adds a refueling stop into the route</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > list for a location to be reached at a time where the car runs low</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> on</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > fuel, a restaurant app may uses this information to add recommended</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > cafeterias into the route list to align the breaks for the driver.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Or if a restaurant app decides to add restaurant POIs as</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > recommendations into the route list for a location to be reached at</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > time where a break would be wise, a installed “coupon” app may add</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > available discounts available at this location.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > etc.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I don’t think I can fully understand these points without agreeing on</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the terminology at the top of the e-mail.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre: ok, hope my comments given where helpful in that regard.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In the current version of the design, these use cases are handled by:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> • The gasoline station application exposes gasoline stations as</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> points</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> of interest via the POI API (</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="https://wiki.apertis.org/Points_of_inter"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_inter</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> es</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> t).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> • The restaurant application exposes restaurants as points of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> interest</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> via the POI API (</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="https://wiki.apertis.org/Points_of_interest"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> • The navigation application contains the logic to:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - Detect where in the route the vehicle is likely to need</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> refuelling,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> query the POI API (</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="https://wiki.apertis.org/Points_of_interest"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">) for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> gasoline stations, and add them to the route.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - Detect when in the route the driver is likely to need food, query</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the POI API (</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="https://wiki.apertis.org/Points_of_interest"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">) for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> restaurants, and add them to the route.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I can’t think of a sensible way of handling coupons at the moment.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> They</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> don’t really fit into any of the existing APIs.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The design is this way round, rather than allowing the restaurant and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> gasoline applications to ‘insert’ recommendations into the route list</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> because it leaves the navigation application in charge of which</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> restaurants (for example) are shown. It means the code for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> determining</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> when is ‘a good time to stop for food’ is in one place (the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> application) rather than many (each restaurant application), each of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> which could end up using different definitions of when is ‘a good</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> time</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> to stop for food’ in order to gain competitive advantage.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre: like said above, the design philosophy is an app-centric</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> solution is, to bundle the policy / logic within the provider app. So</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> its not one central intelligence, orchestrating all others, its vice</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> versa all the others are providing things accordant to their</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> implemented logic. Apps can compete in providing the same service</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> with another policy or using another service with a similar policy.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The user decides by choosing the App which fits best his needs. And</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> he can do in the smallest granularity, per App . So he is able to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> adopt the overall solution by making dedicated decisions per source</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (App).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (Above, I am using ‘navigation application’ to mean the entire</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation application bundle, including any UIs, agents, or services</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> which it provides.)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Philip</FONT></SPAN><SPAN LANG="de"></SPAN></P>
</BODY>
</HTML>