<!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: [Devel] Updated geolocation and navigation design document</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Hi Philip,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">please find my feedback enclosed</FONT></SPAN><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">in green</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></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></P>
<P DIR=LTR><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, 12. Januar 2016 18:43<BR>
An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; devel@lists.apertis.org<BR>
Betreff: Re: 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">I think I understand most of your points here — just a few remaining</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">questions about points of interest. I will start updating the other</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">sections of the design tomorrow.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">On Tue, 2015-12-01 at 14:31 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:</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: Donnerstag, 26. November 2015 10:20</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: [Devel] Updated geolocation and navigation design</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> 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">> > - add UseCase (or a reference in some way): to "imprint a tour"</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > consisting of a set of coordinates (via an extended version of the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > scheme mechanism)</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">> A use case where an LBS application launches the navigation</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> application</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> with a destination and multiple waypoints (using the URI scheme</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> mechanism for launching the navigation application)?</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">> I believe this would be a more complex case of the use case above, or</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> am I misunderstanding?</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">> Andre: yes, thing about a tour city guide App, where you can find</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> prepared tours.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The difference is a little in granularity and with that quantity as</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> also “meaning” of a waypoint.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Aha, I see.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> A waypoint discussed so far reflects an (intermediate) destination,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> you keep freedom to the navi engine to calculate the route inbetween</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> and there is typically a dedicated “intermediate destination reached”</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> announcement of the route guidance component.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> But in this case you would like to “influence” the path, even if it</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> is not an intermediate destination. You could go as far as really</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> referencing every link (road element) on the track - and leave no</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> freedom at all anymore to the routing engine – but that’s over</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> specified. So as of now – like you said – we would simple go a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> “similar” (waypoint) mechanism with some more fine granular</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> supporting points</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> inbetween, but also _without_ “intermediate destination reached”</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> announcement. So we do have to distinguish between both structs,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> maybe we</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> do have to slightly extend the scheme mechanisms with some</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> coordinates specifying a “via-area” in addition to “intermediate</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> destinations”.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Its up to the App to restrict or provide freedom to the Routing</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> engine and with that to take care that the “supporting points“ are</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> close enough to each other to make sure that the path is right where</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> it matters, independent of the routing engine behind.</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">> Some background info for future extensions:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The reason to call this “via _area_” is, because the same mechanism</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> could (in future) also be used (extended) for other usecases to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> influence the path. For example, if you like to travel (e.g. from</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Hamburg) to Rome, you can go via Paris or via Munich. This does not</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> specify an intermediate destination, you neither would like to reach</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> a specific road in that area, nor would you like to get an</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> “intermediate destination reached” announcement. Its only a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> “supporting point” in a more fuzzy description, which finally gets</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> represented by some area (center point and radius). By using a wider</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> or smaller radius one can influence how close the path has to hit the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> supporting point. This typically correlate to the type of location</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> referenced to (specific point, a village,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> town, etc), so one can also keep this concrete mapping (to a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> dedicated radius) in the responsibility of the routing engine and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> only refer to a well-defined representative dimension.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> However, in general this (definition of via areas etc) should all be</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Navi App-internally (similar like call handling in an phone app),</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> also depending on the Navi supporting this kind of features. An app</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> only provides a destination, and the navi app handles if this shall</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> replace the current destination, if it’s a new intermediate one,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> which one, as also if there should be via areas in between and what</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> kind of routing parameters /fast, short, etc) are used. But for some</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> dedicated use-cases, we may provide Apps some more capabilities to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> influences this in future.</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">> Lets keep this functionality out of scope so far. I only explain it,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> to give you a bigger picture to keep it in mind during API</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> definition. The goal is to have some kind of future proneness, i.e.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> that the next extension does not break the introduced API directly.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> You can think about if we have handle all in one scalable struct</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (i.e. an intermediated destination is only as specialization of a via</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> area and all are waypoints), or if we use different things for it.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OK, I will incorporate the use case and try to ensure that the design</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">does not make some of this future functionality more awkward.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - add UseCase: to share/subscribe (updated) route-information</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">> As I've noted below, I cannot think of a use case where an LBS</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> application could usefully use that information, which is not already</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> implementable using the geolocation or geocoding APIs. Could you give</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> an example of the use case you have in mind?</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">> Andre: if there is route-information available, then we do have an</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> active route guidance.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The route guidance’s presents some information from the route to the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> User, e.g. the ETA</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (estimated time of arrival), destination and direction of next turn,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> etc. It also shows important</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POIs at the route, e.g. fuel stations, service areas, etc</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">> If a 3rd Party App adds POI data to the is route-info, this will be</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> included into this presentation (guidance).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> One can show where the next McDonalds is – if you have a McDonald’s</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> app installed - , or some</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Touristic interesting things. The App can align the information with</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the preferences of the User,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Driver Condition, Driving situation, the Vehicle Status, etc</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">> see for example the Use-Case below (Restaurants)</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">> Another perspective is, that the route information describes your</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> track ahead. With that one can call</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> It “horizon”. Apps can provide further details about the track ahead,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> e.g. hazard spots, weather conditions etc,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> which finally can be used to inform the Diver (via the guidance info)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> as also from deeply embedded functions</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> in the car to adopt their functionality-</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">> To be more abstract, it’s not (only) the way that POI information</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> from all over the cloud gets loaded and imported into</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the navigation app and considered at point in time of route</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> calculation, in contrast this use-case covers the scope that after a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route has been calculated, additional attributes / extended</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> information gets added to the path. So apps – reflecting a given</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> cloud service / data – gathers their data accordant to the situation</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> and adds this to the route-info. This does not influence the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> track itself (routing), but it informs the user, enables new actions</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> as also will be used again from other (functions) Apps for their</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> build in functionality.</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">> Since it also influences other functionalities, we have to reflect</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the security (e.g. integrity) of data-providers. For example we could</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> think about transporting the source of an information (e.g. which</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> App). Another aspect would be the quality of data, e.g. accuracy,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> age, etc </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> of data.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">I see your meaning for the use case. If this is indeed all about what’s</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">displayed in the navigation app, I believe this is entirely handled</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">already by the points of interest design:</FONT></SPAN></P>
<P DIR=LTR><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"></SPAN><A HREF="https://wiki.apertis.org/Data_sharing"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Data_sharing</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></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">Andre:</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">no,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">w</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">e still have a fundamental mismatch</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">, the purposes are very different.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">I</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">feel its hard to discuss all that via email, but lets try:</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">With the referred APIs (point_of_interest) we hand over data</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><I></I></B></SPAN><B><I><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">responsibility</FONT></SPAN></I></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"> form one (source</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">-app</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">) to another (sink</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">-app</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><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">The “navigation app” imports that data, from that point</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">in</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">time any further data management (</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">duplicate handling,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">persistence storage,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">validity, usage in various embedded services like destination input, route calculation, etc)</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">in in their internal (black box) responsibility. The mechanism is simple a</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">point-to-point</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">data pipe, deliver and forget.</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"></SPAN></B></P>
<P DIR=LTR><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">We do not flood the navigation app by providing to it all information available, only information which shall be</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">handed over</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">into their</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">responsibility, so typically which shall influence their routing. We do _</FONT></SPAN></B><SPAN LANG="de"><B><I></I></B></SPAN><B><I><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">not</FONT></SPAN></I></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">_ import all mac-donalds data into the navi app. This stays in the mac-donalds app, it gets</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">browsed within this app etc. </FONT></SPAN></B></P>
<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Please keep also in mind, that the navigation app itself is somehow special in regard to their output.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">Beside</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">provides some UI to control its func</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">t</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">ions</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">like all the other apps (e.g. media player), the “route guidance” information is very special.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">In addition to a black box build-in solution for the route guidance</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> - like all the smartphone</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">Smartphone solutions</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> realizing today –</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">on prompt</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">the guidance is only</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">acoustic</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> or</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">a</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">n</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> app-change</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">transition</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">to the navigation app appear</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"></FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">we will go a step forward for this driver related information.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">The guidance</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">will be presented to the user inde</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">pendent of the current App in use</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> in foreground</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">. So you can “leave” the navi-app but the guidance</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">shall</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">continue.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">In fact we influence the internal design by requesting an agent to be provided</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">by the app-developer</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">to deliver these data.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">And that’s not only an acoustical prompt, its also</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">data</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">which</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">gets finally a</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">visual</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> representation</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> (turn icons,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">lane information, etc)</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">In this approach</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">via an SDK-API</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">the rendering gets done by some</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">system service. Its more like a “notification”/“dialog-box”/“status framework” stuff</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> (please have a look to the running status framework and the relation to assist framework to</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">o</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">So the navigation App provides its data as output to some SDK-API.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">In fact part of this is the route list, which finally land in that guidance dialog. Lets call it assistance window – driver related information.</FONT></SPAN></B></P>
<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">To this route list, other apps can directly add further data. This is _</FONT></SPAN></B><SPAN LANG="de"><B><I></I></B></SPAN><B><I><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">not</FONT></SPAN></I></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">_ 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</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">and managing it. This data, gets provided by the source app to the rout–list and with that finally rendered to t</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">he user by some system service (assist window). On the other hand, other apps can consume this enriched route list again</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">for their build-in functions and policies. Its all outside the navigation, the navi only provides the initial foundation.</FONT></SPAN></B></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">Specifically, depending on the answers to the questions in that design</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">about the relative bandwidth of the POI streams, this can be</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">implemented by:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial"> • the navigation app queries POIs from a publish/subscribe POI service</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">and displays them on the calculated route as appropriate; or</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial"> • the navigation app sends the calculated route as a query to a POI</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">query interface (§(Consumer-initiated pull via a stream)); or</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial"> • the POI apps send their POIs to the navigation app which then</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">chooses which ones to display on the calculated route (§(Provider-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">initiated push via a stream)).</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">Andre</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">: like said, we are not restricted to an App-App relation (even though we support this limited approach too), I am talking about a system service in-between.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">On the one hand this is handling all driver related notifications like guidance, but hazard sport warnings, speed limits etc, and the navigation App is only one out of many</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">providing this data, on the other hand it’s the data responsibility, which does mean</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">Points_of_interest</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> API gets used to handover the responsibility and this will be</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> done only for a very small subset (relevant for route calculation)</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">The other suggested data sharing models are also possible here,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">depending on the bandwidth needed.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">If it’s also about changing the behaviour of other applications to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">display data pertaining to the calculated route, then we will need</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">another API for exposing that data, and it would be entirely unrelated</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">to POI sharing.</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">Andre</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"> yes, that’s part of the scope.</FONT></SPAN></B><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">> > - add UseCase: to add something into a route list (e.g. restaurants</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > along the route from restaurant app) and this based on own interest</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > of the user, specified in this app (e.g. via favorites) and under</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > control of User by enabling this participation via settings.</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">> Do you mean automatically? What is the user's participation in this</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> use</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> case: are they specifically interacting with a restaurant app and ask</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> it to book them into a restaurant and add it as a navigation</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> waypoint;</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> or do they just want to see nearby restaurants highlighted on the map</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> as they travel through an area?</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">> Andre: like said above, information from the route list will find its</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> way to the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route guidance (we sometime call this driver assistance information).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> So its not about reservation, its about information. A Restaurant App</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">> provide recommendations for a rest stop, fitting to the driving time</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (e.g. a location</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> area reached after 2 hours of drive), the day time (afternoon,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> evening, etc => coffee break, dinner, etc),</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the user preferences (Italian, vegetarian, etc) etc.</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">> In relation the use-case above “add UseCase: to share/subscribe</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (updated) route-information”</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The App subscribes for changes in route list, and provides new POIs</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> inc ae the path has</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> been changed.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">I guess I am not quite clear about the user experience here. With this</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">restaurant use case, are you expecting the restaurant app itself to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">provide the recommendations //as part of its interface//; or are you</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">expecting it to export them as POIs which will be displayed //by the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">navigation app as part of its interface//?</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">Andre</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">: like explained above, please don’t see</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">the Navi app</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">as the final sink. It has a relation to a system service to expose its notification to the driver.</FONT></SPAN></B></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 FACE="Arial" SIZE=2 COLOR="#000000"> <<...>> </FONT></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT FACE="Arial" SIZE=2 COLOR="#000000"> <<...>> </FONT></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT FACE="Arial" SIZE=2 COLOR="#000000"> <<...>> </FONT></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">The “user interface” is part of a system chrome, we call it “assist window”. Its like a notification center, b</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">u</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">t</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">for driver</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">centric</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">information. The navi-app provides data to it, but other apps too. For each product variant,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">we implement a UI customization for the</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">look & feel of this “driver notification</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">center”. Once the user tap on an</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">object</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">in that view, the related app gets launched.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">There can even be a second instance of that information exposed to the instrument cluster, but that happens behind the scene with some Interdomain communication. </FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">There can also be</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">POI data</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">w/o any</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">active</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">navigation (route guidance)</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"> I</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">n case there is no destination set</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">and with that no route list</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"> apps can provide POI</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"> surrounding the current geo position (e.g. hazard sport warnings,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">touristic info, etc)</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">. The</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> user can define via system settings if an app is allowed to expose data to</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">this center</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> (like in a</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> us</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">u</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">al</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">notification center)</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"></SPAN></B></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">I suspect you mean the latter option, because the former would not make</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">as much sense if the user had (f</FONT></SPAN><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">or example) multiple restaurant</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">applications installed — then they would have to look at each</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">application in turn to see all the recommendations, and the look and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">feel of the recommendations would be under the control of those</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">applications, rather than under the control of the OEM (who presumably</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">wrote the navigation application).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Could you clarify this please?</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">Andre</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">: hope it became more clear. But please don’t hesitate to ask. </FONT></SPAN></B></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"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I have a use case in the updated document which covers a restaurant</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> application adding a waypoint into the current navigation route, if</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">> user explicitly requests it (for example, by making a booking at the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> restaurant). Does that cover what you mean?</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">> Andre: It should be possible for the user to select an information</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> added to the route-list,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (so from that point of view we againneed the source of information,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> i.e. which App has added what)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> After selection by the User, the App gets launched and shows the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> detailed view of that POI.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In the App internal scope, the User can proceed a reservation /</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> booking (similar like phone handling</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Is app internal).</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">> Booked POIs, lands in the app-internal list of reservations, and can</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> be maintained / edited app internally</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> At any point in time later.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OK, I’ll incorporate that into the document.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> However, this brings me to another topic of cross app usage. Its also</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the same for Phone Handling.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We do have a last mode of an App, which is the one the App has been</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> left last time. It could be a Detailed</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> View of a specific content, with some extensive tasks picked up</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> before (email, call history, contact info, </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Restaurant location, etc). Then the User left the App to home screen</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> or some other App due to some reason.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Now there is a cross reference from another App into (like mentioned</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> before, also into communication Apps to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> share something – e.g email, or call handling etc). We should try</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> hard to execute that cross reference</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (send a mail, book a restaurant, initiate a call), without</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> jeopardizing the state of the full-blown app. So this may</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Lead us to the requirement to App- Developers, to provide a dedicated</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> executable – an Agent – for this specific</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Task. This helps us also in minimzing resource needs and increasing</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> reaction time.</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 add this to the right place – the right proposal - as take</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> care that our design fits to it.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">To be sure I understand you, you’re talking about ensuring that a task</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">which is started by an application which is then sent to the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">background, is completed rather than (for example) being paused? Even</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">while another application is in the foreground?</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">Andre</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">My focus is less the completion in background, my focus is</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">independence (or vice versa side-effects) caused by remote calls.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">It’s a kind of “multi-threading”, even w/o</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">multi-user capabilities.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">But to skip the software terminology, think about having a</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">user driven path (assum</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">e</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> you</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">start writing an email in email client)</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> and an inter-app communication (user</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">interrupts</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">email</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">writing, leaves the app,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">[email state in background is still in editing mode of the last mail],</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">launches browser,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">jumps to a url and renders the page, and then he gets in</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">mind to</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">“share” that page with some friend, initiates sharing mechanism, selects via email,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">an editing view</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">of email</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">slides in with the given url embedded). This task shall</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><I></I></B></SPAN><B><I><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">not</FONT></SPAN></I></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">irrevocable destroy the background mode of the email app, which is still in editing mode of new mail. The user can even switch to email, and continue writing it, because</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">the new one is executed on behalf of browser. If the user switches back to browser, he gets the sharing screen on top</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">, etc.</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">Its typical iOS behavior, so you can reflect it quite easy.</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"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">That has always been my understanding of how the system should work,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">and how agents and applications should interact. </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">> > - add UseCase: for map-widget (with temporary integrated POI data)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > its integrated data sources (position, destination, route, etc)</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">> What is the use case for this? i.e. In what application context do</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> you</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> imagine this widget being used? I have been trying to think of an LBS</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> application use case for exposing destination and waypoint</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">> and cannot think of one.</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">> Andre: An App like “Restaurants” shows Restaurants accordant to the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> User Preferences (only open ones, high user rating,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> time depending only Italian or Chinese etc) in an embedded map</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (libchamplain).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> On selection of an POI in this map, the app shows extended POI</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> information (pictures, comments, etc) to the User and vice versa in</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> choosing a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POI-Description in the App, the map gets scrolled to the related</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> location. For a POI corresponding to the user interest,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the user can initiate a route guidance (scheme based nav service with</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> new destination corresponding to the coordinate info of the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Restaurant).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Do you envisage this embedded map showing the vehicle’s current planned</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">route? (Ah, you answered this already below!)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In regard to “temporary integrated POI data”:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> None of the added data (POIs, but also all other kind of added data</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> like line or polygon once) has been imported to the Navi.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> it all resides in the Restaurant App. The “data responsibility”</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> including their validity Resides in the POI App.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The Navi App only gets a new destination.</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">> The POI data is also not “imported” to libchamplain, its only shown</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> in a separate layer during the lifetime of the App (temporary).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Other Apps do not get them included in “their” map widget.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Agreed.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In regard to “integrated data sources”</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Even though data added to libchamplain by an App keeps the App</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> boundary (its lifecycle and its data responsibility), the map widget</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Itself carries already lots of information gathered behind the scene</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (and with that shared over all apps). This is for sure the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> street data (e.g. tiles fetched from some backend) but beside that</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> its also for example</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - The current vehicle position (a moving, updated, vehicle</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> cursor)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - Information (maybe a subset) from the route list, i.e. the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> destination (e.g. a flag), the intermediate destinations, the track</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> itself, etc</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">That answers my question from above, thank you. This should all be</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">possible by providing libchamplain map layers as part of the SDK APIs,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">which query the relevant geolocation or navigation service.</FONT></SPAN></P>
<P DIR=LTR><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">Andre</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"> yes</FONT></SPAN></B><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - add UseCase: for map-widget own responsibility in regard to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > look&feel of embedding the widget, of embedded additional data, its</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > interaction on selection events, and the overall functionality</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">> Can you clarify this please? Do you mean that the map widget should</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> always have the same appearance, regardless of which application it</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">> embedded in?</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">> Andre: no vice versa.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Lets reflect again the scenario mentioned above:</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> An App like “Restaurants” shows Restaurants in an embedded map</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> accordant to its app internal style.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> On selection of an POIs in this map, the app shows extended</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> information to the User and vice versa in choosing a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POI-Description in the App, the map gets scrolled to the related</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> location. For a POI corresponding to the user interest,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the user can initiate a route guidance (scheme based nav service with</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> new destination corresponding to the coordinate info of the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Restaurant).</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">> In an app centric solution we would like to enable freedom for Apps</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> to present it accordant to its needs. So</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the App can define the size of the map widget, its position in the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> screen, it can add animated transitions to the whole widget</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (e.g. a backflip animation of the map, showing some preferences on</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the back side), and can also define the look & feel of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Data added to the map (e.g. appearance animation of added POIs, i.e.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> own clutter actors).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OK, that’s all possible. What would not be easily possible is to allow</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">the application to define how the map itself is rendered (for example,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">what colours are used for different grades of road), as libchamplain</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">typically uses pre-rendered image tiles for its map, whose rendering we</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">cannot affect.</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">Andre</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"> yes</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">, the tiles are ok.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">I referred to freedom for data _</FONT></SPAN></B><SPAN LANG="de"><B><I></I></B></SPAN><B><I><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">added by the App</FONT></SPAN></I></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">_</FONT></SPAN></B></P>
<P DIR=LTR><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">That’s not the tiles, but additional i</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">co</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">ns, points, polygons,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">etc. Even for these we can prepare some fitting well to the overall look&feel, e.g. “</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">blue</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">pin falling from sky” for POIs</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">, but an app my create on own clutter actor for its POIs and use them for the</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">representation</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 its additional data.</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> For sure we prepare and provide templates to an App, for prepared</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> screens, its transitions, as also for POIs added</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (e.g. a pin, with some falling from sky animation), but the App is</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> free to use it. So we never restrict it to it. The App has</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Freedom do go for an own way, w/o any need / impact to other apps.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Its all about general purpose solitons and enabling.</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">> Vice versa, if we have imported data into the navigation app, the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> data responsibility changes. Its like said already in regard to the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> validity (how long to store, when to delete data etc), but also in</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> regard to the look & feel. The data imported into another App gets</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> rendered</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> like the other App likes to render it. If someone likes to change it,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> someone has to discuss this with the other App-Owner.</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">> Hope you get what I mean.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">That’s all clear, thank you.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - add UseCase: to explain a SDK service provided for LBS Apps to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> ask</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > for input of a location which gets transformed to a geo-positon</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> used</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > for backend-server. "Type ahead search and completion for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> addresses"</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > an optional extension / future feature</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">> This (which is a description of reverse geocoding; please correct me</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> if</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I've misinterpreted) is covered by the 'viewing an address on the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> map'</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> use case, which I have reworded to apply to LBS applications rather</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> than the navigation application.</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">> Andre: its slightly different. Lots of LBS Apps do need for their</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> backend service a geo-coordinate.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> But that’s not the information a User like to type in. A User likes</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> to provide a name (a city, a complete postal address,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> a name an interesting location, etc). To take care that not each and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> every App now has the challenge to derive a geo-coordinate</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> from a given name (and every app does this in another way and in</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> different “quality”) a central service should cover that.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In best case, this is also embedded in the keyboard, as a special</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> form.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Yes, this is precisely what the reverse geocoding service is designed</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">to do: convert a human-written place name or address into a coordinate</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">(or list of coordinates if the search is ambiguous).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">This is also covered by the type-ahead search requirement in the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">design, which recommends that we provide a widget where type-ahead</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">suggestions are integrated already, so application developers do not</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">have to reimplement the search functionality.</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">Andre</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">: great</FONT></SPAN></B><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - add UseCase: explains how a Navi App can produce data for other</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > (LBS) Apps (becomes a backend replacement / a data server for 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">> </FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I believe this is covered already by the 'automotive backend' use</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> case,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> which considers the navigation application and automotive backend to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> be</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> fairly tightly coupled from the point of view of providing backend</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> services for the SDK APIs.</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">> Andre: yes, but here it is meant more in relation to “integration of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Navi Apps” (the separate chapter),</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> because in this separate chapter an 3rd party interested in</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> integrating its navi solution should not only</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> know what needs to be done to get it running at all (from a consuming</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> perspective), but also what kind</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> of data/interfaces should be exposed (from a producing point of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> view).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">I see. I will try and make that clearer in the appendix which covers</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">recommendations for third-party navigation applications.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - add UseCase (or a reference in some way): to handover/import POIs</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > (e.g. Traffic information) which we do have already separately</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > covered in our wiki (add a reference). Via that usecase one can</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> also</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > explain, how a user is able to select data sources to be used by a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Navi App by loading the one of interest from Store (out of various</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > alternative sources for traffic information)</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">> I have made sure there is a cross-reference to the POI design 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">> 'POI data' non-use-case section. I believe selecting POI sources for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the navigation application should be internal to the navigation</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> application.</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">> Andre: yes, but please keep in mind that the method of “selection” is</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> _not_ based</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> on “business logic” within the navi software, but by the User.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> So the User will make his decision in the context of the Navi App</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (its setting & preferences, similar like access to a camera roll gets</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> granted or not).</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The Navi App exposes its interest, the User grants it or not and can</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> it change at every</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Point in time. Via this mechanism, the user can “configure”, which</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> sources to use.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">I see. This would be an instance of manifest permissions which are</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">checked at runtime, when the navigation application tries to query the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">POI API (and this may result in the POI service prompting the user to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">allow or deny the request, then saving the result). I will update the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">document to cover this.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Specific</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - 3.2.1 the sentence "functionality may be exposed directly by the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > backend and used by applications using specific APIs on the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> backend".</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > To be honest, I would love to go for some SDK-APIs also for this</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > extension. We can "tag" them as "product specific", but maybe</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > something similar will be provided from other backends too. To</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> having</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > a "normalization" layer in-between is also beneficial from</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> backwards</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > compatibility point of view. If we have direct dependencies to App,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > we run short in compatibility tests.</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">> The point of this use case was that such backend-specific APIs expose</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> functionality which is //not// covered in the SDK API — if it were</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> covered in the SDK API, they would not be backend-specific APIs! I</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> will</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> amend the document to clarify that the SDK APIs can be extended in</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> future if it seems appropriate to standardise some functionality from</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> multiple backends which was previously only available as backend-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> specific APIs.</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">> Andre: for me it looks like this is a very specific use-case. An App,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> who</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> uses APIs not part of the SDK becomes a build-in App (formerly named</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> as core-apps)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> and needs to be updated with the OS. It has a tight relationship, and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> since we only guarantee</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> backwards compatibility for the SDK, the update path (bundled with</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the OS) changes.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (see applications proposal).</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">> We intend to use this way to bridge 'automotive backend'</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> functionalities via representative</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Agents. These Agents becomes then “build-in” ones, and they use some</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> backend-specific APIs</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> for implementation. But its not to expose this backend-specific APIs</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> to other Apps, its more like</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> a Web-App uses a proprietary API to connect to its Backend and the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> same will happen for the Agent</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> using a proprietary interface to its automotive Backend. However, the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> connection to automotive</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Backends will be discussed further in the scope of “Interdomain</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Connection” Proposal. We will</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> See on what we conclude finally.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Indeed, shall we come back to this point after you’ve finished</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">reviewing our proposal for the Inter-Domain Communications design.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre</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">yes, lets do that.</FONT></SPAN></B><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">> > - 3.6. from my point of view it’s a valid use-case, but to be</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> honest</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > I do not see the specific topic which influences the requirements</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">> > API proposal for the scope of this document. For me it is similar</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > like a Media Player app continues to render music if another App</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > takes foreground focus.</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">> The motivation for this use case was to ensure that routing is</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> implemented as an agent and application, rather than purely as an</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> application (which would stop being able to output audio if suspended</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> or moved to the background).</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">> However, that's a navigation-application-internal feature, so I have</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> dropped the use case.</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">> Andre: thx, that a valid one. We should put this into the special</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> chapter</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Which explains to 3rd parties “how to integrate a navi app”.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Will do.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - 3.9 change the scenario from "Navi" to "LBS" app. But to be</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> honest,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > this is not a first priority goal. This is very special for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> "address</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > input", but since the SDK-API is for general purpose, one do not</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > really know If the user types in a "address" or a "POI name". So</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > "Eiffel Tower" is maybe not a valid address (in the meaning of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> city,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > street etc.), but it describes a location. Text-ahead search is</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> maybe</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > very challenging for that. This extended scope is very challenging</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > for offline solution, because the database will increase to a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > significant size. This lead to online cloud based solution, which</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> may</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > have issues with availability or performance. However, lets keep</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">> > use case and see how far we come.</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">> Agreed. I will rephrase the use case to be LBS-only, and re-evaluate</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the implementation suggestion to see how feasible it is.</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">> Andre: yes, lets look about the capabilities of backends.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In addition - since an installed Navigation _can_ become a data</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> provide for one, multiple or all backends -</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> this would one more type of data which can be replaced/provided by</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> an installed navigation backend.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> So we would have map tiles for libchamplain, position for geoclue,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route-list for “tbd SDK-API”, etc</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> and now “transformation of a location name to a geo-position with</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> text-ahead support”</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Indeed, the requirement for supporting multiple backends would apply</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">equally to this API as others.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - 3.14 can maybe hanged to a LBS App usecase, subscribed for a new</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > route-info available and updating the POIs (e.g. hazard spots)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> along</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the (new) route in this 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">> That's a use case for the POI system; I think the best way to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> implement</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> this would be for the navigation application to pull in a new set of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POIs every time it changes the routing (or waypoints or destination).</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">> Andre: like explained above, we will have different sinks of POIs,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> aligned with the different purpose and also with related data</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> responsibility.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - in “libchamplain” for User interaction / selection (aligned</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> with App lifecycle/)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - in “route list” as extended information / attributes (aligned</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> with lifecycle of a route)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - in “Navigation” (via on pull-mode and interface discovery htt</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> ps://wiki.apertis.org/Points_of_interest) as data import (and with</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> that also a hand over of data responsibility, persistent storage,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> validity, user presentation and also embedding into its build in</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> functionality like route calculation)</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">> So there is not _one_ POI system. Hope the 3 different purposes are</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> now more clear.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The use case mentioned in 3.14. deals with POIs provided to 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">I think this is clear. I was using the term ‘POI system’ to mean the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">POI API or service which collates POIs from various POI providers, and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">makes them available to the POI sinks as part of a publish/subscribe-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">style system. Maybe I could better have said ‘POI publish/subscribe</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">system’.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">In all three cases here, I think the POIs are coming from the same pool</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">of sources. The differences arise in how long the sinks keep the POI</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">data, how they process it, and which of the POIs they consider</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">interesting. Am I following your thinking correctly?</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">Andre</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">: to be honest, I am thinking in another direction.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">Its driven by responsibility and data management.</FONT></SPAN></B></P>
<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"></SPAN></B></P>
<P DIR=LTR><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">In regard to the first topic:</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">There is stuff which gets embedded into libchamplain which</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">stays</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> completely in the App responsibility.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">Its for User Interaction, nothing else. It uses libchamplain APIs (clutter) to embed POIs. The user can interact with it and libchamplain informs</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">the App about content selected which has been included by it. So nothing from a central POI service in that regard.</FONT></SPAN></B></P>
<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"></SPAN></B></P>
<P DIR=LTR><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">In regard to the last topic: There is stuff which gets imported into some other App. Data responsibility gets forwarded. This is the “some App streams data into the navigation” via a pipe solution.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">Nothing central in between for the data flow, only for the control flow some SDK-API has been used.</FONT></SPAN></B></P>
<P DIR=LTR><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Finally the is the route list, where Apps can decide to</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">embed</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">data for the driver. I have explained above that stuff more in detail. Again a different thing to the 2 above.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">The validity of this data is only during runtime. The system service does not store</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">the</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">data persistently.</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"></SPAN><SPAN LANG="en-us"></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">> > - 3.17 may can be changed to LBS App, consuming it. However, we can</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">> > also keep this in a sense, that a</FONT></SPAN><SPAN LANG="de"> <FONT SIZE=2 FACE="Arial">Navi app can replace the backend</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > and produce road info for the SDK-API.</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">> I have dropped this one, because I cannot think of a use case where</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> an</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> LBS application would need to know road information.</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">> Andre: see above in regard to use-cases, where an app likes to know</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> road information of the track ahead. E.g. for Hazard spot warning,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> rest station, etc,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OK, I will re-add this one and rephrase it accordingly.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > 3.18 from my point of view it’s a valid use-case, but to be honest</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > do not see the specific topic which influences the requirements and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > API proposal for the scope of this document. For me it is similar</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > like a last User-Mode.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > 3.19 sounds for me like a Navi-App internal feature</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">> Dropped. I have tried to think of use cases for where an LBS</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> application might need to be notified of the navigation destination</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (and when it changes), but I can't think of any use cases which</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> aren't</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> already handled by using geolocation or geofencing.</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">> Andre: again, see above. If the route changes, the restaurant app</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> would like to update the rest stations recommended to the user. That</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> not geolocation as also not geofencing.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OK.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > 3.22 also a valid use-case, 3rd party navi apps has to use some</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > system info APIs</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">> But third-party navigation applications are likely to come with their</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> own locale database, and all they need to be able to use that is the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> vehicle's location, which they get from the geolocation API. I cannot</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> think of other use cases for exposing locale information to LBS</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> applications which are not served by the geolocation API, so I have</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> dropped this use case.</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">> Andre: at least the position of crossing a border could be of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> interest. An App could use this information to set a geofence and to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> inform the User about something (e.g. traffic regulations) once he is</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> close by. Or Apps could use this information to align their</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> recommendations etc. However, this a very special detail, and we can</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> extend the scope / data carried in route list also over time.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OK, we can come back to this one later.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Another topic is, that Navi Apps may use more than the vehicle’s</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> location for processing. They may need information about the type of</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> vehicle (dimensions, etc), if a trailer is connected etc.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">That should be covered by the vehicle data/sensors and actuators API,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">which navigation applications are able to use.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > 4.3. to be honest, looks like I do not understand the Use-case. We</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > would like to have a libchamplain map widget loading map tiles from</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > backend providing OSM street data.</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">> I was told that the automotive domain would definitely not be storing</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> 2D map tiles for libchamplain, so they would not be sent over the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> inter-domain communication link; this non-use-case documents that</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> fact.</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">> I think we are in agreement: libchamplain’s map tiles will be loaded</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> from a backend (in the CE domain) which provides OSM data.</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">> Andre: no, that’s a misunderstanding. Map tiles will be loaded from a</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> backend</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (in the CE domain) which provides OSM data, that’s right. We will use</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> this setup</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> also for the SDK environment.</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">> But lets keep the use-case also for the automotive domain setup and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> with that</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the inter-domain communication link. Lets cover it concept & design</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> wise and lets see</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> when we implement it.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OK, I will reinstate the use case, but indicate that it is potentially</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">for implementation in the future.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > 5.17. for LBS-Apps, from my point of view this is more a lib-</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > champlain feature. But maybe I am wrong.</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">> libchamplain can give the latitude and longitude of a location on the</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> map, but this requirement is about the forward geocoding API to</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> convert</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> that (latitude, longitude) pair into a postal address.</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">> Andre: I see. Again a backend service which – in case a navi app is</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> installed - can be provided by the navi app to.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Precisely. The forward geocoding API will also support multiple</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">backends.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > 5.22. please change the use case mentioned to an LBS one (embedding</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">> > map view into the App screen) and adding service specific</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> additional</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > information (like animated weather map overlays within a weather</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> map,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > route proposal from tour guides, or hotel from a hotel app)</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > However, for me this is some kind of feature discussion for the map</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > widget. Today we use libchamplain, is supports some features,</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> others</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > will follow. Today its 2D. We can think about if the API (from</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > libchamplain) is well already, should be enhanced or if we should</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> use</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > a separate one for 3D. This can also be a roadmap discussion, when</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> we</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > enhance what.</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">> The use case which motivated the requirement for a 3D map was</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> implementing a navigation application, but since that use case has</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> been</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> removed, I don't think there is now a motivation for a 3D map API, so</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> will drop this requirement. There might be individual applications</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> which would benefit from a 3D map, but I think a 2D map (i.e.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> libchamplain) caters for 90% of all mapping use cases in LBS</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> applications, so it would be unnecessary effort to provide a 3D map</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">> in the SDK.</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">> Andre: yes, its not intended for implementing a navi app.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> However, it’s stays a roadmap topic even that it’s intended for LBS</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Apps only.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I agree that a 2D maps serves well for the majority of LBS Apps, but</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> sometimes OEMs</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> like to push the limits. And since Smartphone Ecosystems provide</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> already some</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> “perspective 2,5D view”, Navi Apps itself provides full 3D view, it</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> may appears that to be</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> up-to-date we have to embed 3D capability also into the map view for</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> LBS Apps.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> To provide a modern and feature rich user experience.</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">> So keep it on the roadmap, its nothing urgent yet.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OK, I will include it in the document again as a potential future</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">feature.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Are there any other alternative designs you want to be considered?</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">> Andre: so far it seems sufficient for me to reflect Google services</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> as backend replacements.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> On the one hand they have a good footprint in this area, and they</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> also serve well as a representative</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> scenario for proving the flexibility.</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">> However, do not to forget, that an installed Navi app can replace</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> single up to all backends, and</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> that with that it could also be provided by “automotive backends” via</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the interdomain</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> communication.</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">The need for multiple backends is firmly embedded in my thoughts about</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">the design!</FONT></SPAN></P>
<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Philip</FONT></SPAN><SPAN LANG="de"></SPAN></P>
</BODY>
</HTML>