Hi Philip,

please find enclosed some answers in green After having done this iteration, I will now review the document an send afterwards some feedback.

Rgds Andre

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Dienstag, 17. November 2015 11:46 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; devel@lists.apertis.org Betreff: Re: AW: [Devel] Updated geolocation and navigation design document

Hi Andre,

On Mon, 2015-11-16 at 17:20 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

thx for the updated document. After having read the document and before I start providing deeper feedback, I was wondering about the UseCases covered in that document. We have used the pattern (from Usecases to Requirements, reflection of existing solutions and coming to a proposed approach) already multiple times, but this time I was really wondering, when do we pick up a use-case to be mentioned ?

That’s a good question. Picking up use cases seems to be the hardest part of producing these design documents. Personally, the way I have been doing it is to make up what I think are reasonable use cases for such a system (based on my experience of using similar systems), and to add in use cases I have received from other parties. When the document undergoes review (either internally or externally), I add more use cases extracted from the feedback, and iterate until everyone seems to be happy.

I am working on the assumption that if anybody spots a use case which is missing – or one which they think we should //not// design for – they will comment on that in their reviews.

Andre: ok

One of my primary intentions is to define the SDK-API. So from that point of view I reflect, what kind of use-case exists for a "non- navigation app" to deal with location based information (e.g. Weather, Hotels, etc). That’s an App-Developer point of view.

I was operating on the assumption that navigation apps would use the SDK (with the caveat that OEM-provided navigation apps may additionally use out-of-band data from OEM-specific APIs in the automotive domain). Is that not the case?

Andre: creating navi-apps from scratch (fully relying on SDK-API exposed functionalities) are not in focus. (I have send a separate mail for this topic)

Certainly, using my phone as an example, I have a variety of navigation apps available to download, all of which use the Android geo-APIs. Andre: There is eventually a certain level (functional scope) of navigation app achievable using exposed SDK-APIs with Backends based on cloud solutions deployed as default, but like said its simple not our focus. If someone is willing to create its own Navi-App cased on it, he is free to go for it. And he is also free to substitute functionality over time with build in ones, but we do not take care that its functionality is well done.

Another set of use-cases comes from flexibility in system setups, that’s influencing things behind the scene and is more a System Integrator point of view.

Agreed.

In contrast, I do _not_ take into account what an developer of a navigation App would like to do. That’s all internal stuff, without dependency to the SDK. I do have the feeling, there are uses cases included only relevant for Navigation internal implementation. Lets call them Navi-features. But I am not sure. Things like "Deviating off a navigation route", "Resuming a navigation route" or "cancelling a navigation route", aren't they full App-Internal ? Its seems to me like we would discuss that a phone call needs to have the capability to be canceled. That for sure right, but I miss why its important for our context.

These particular use cases were specifically aimed at navigation apps, yes. In this case I may have been too verbose, as those use cases did not translate into requirements for the routing API — they could be implemented entirely internally in a navigation app, as you say.

Andre: yes, but before we remove them lets reflect vice versa from LBS-App point of view, if this is scenario e.g. from consumer point of view which is worse to mention.

Philip

Or the description is misleading, e.g. an App would like to subscribe for a new route (for example caused by deviating off a navigation route, but also caused by other reasons like a new (intermediate) destination has been set). In that case the description / and the use case would more focus on consuming the new-route information and to generate some great service from it instead of "that the calculated route must be radically different", and "recalculation should happen within a short time period".

Hope you get what I mean.

Rgds Andre

-----Ursprüngliche Nachricht----- Von: Devel [mailto:devel-bounces@lists.apertis.org] Im Auftrag von Philip Withnall Gesendet: Donnerstag, 12. November 2015 17:40 An: devel@lists.apertis.org mailto:devel@lists.apertis.org Betreff: [Devel] Updated geolocation and navigation design document

Hi all,

Please find attached version 0.2.1 of the geolocation and navigation design document. This version incorporates feedback about swappable backends and the ability to back any of the APIs by an implementation in the automotive domain.

I have uploaded this version to the wiki as a draft. Further feedback is welcome and will be incorporated as normal.

https://wiki.apertis.org/File:Apertis-geolocation-navigation-design-0 .2 .1.pdf

Thanks, Philip

Hi Andre,

Sorry for the delay in replying. Here are some responses, plus a few more questions I have come up with while updating the document in response to your feedback.

I am part-way through updating the document, and will continue to work on it while awaiting your response, although I will not be able to finalise the updated design until then.

As I can foresee replies to this e-mail getting quite long, please feel free to delete paragraphs from it which have been addressed and which you have no further comments on!

On Thu, 2015-11-19 at 12:42 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

Hi Philip,

enclosed my feedback to the proposal. I focus on the section "use- cases", because later on it would result in repeating similar things (changes in Usecase lead to changes in requirements etc). With that, my feedback for chapter 5 onwards becomes somehow partial only.

General

• we do not focus on releasing a build-in (OS) navi functionality,

but exclusively going via connected backends, located in cloud, in apps, or in automotive domain (via a wrapping app). If we have established a design for that, it will be appropriate for a build-in Apertis OS solution, too. We only have to select one and to ship it as "build-in" App (as defined by Applications document)

I understand — and thank you for the separate e-mail which clarifies this. I have amended the introduction of the document to restrict the scope to what you suggest, and am going through and reworking the use cases and requirements accordingly.

LBS:

• add UseCase (or a reference in some way): to set a (intermediate)

destination (via scheme mechanism) which we do have already separately covered in our wiki (add a reference)

I have adapted the 'navigating via waypoints' use case to cover this.

• add UseCase (or a reference in some way): to "imprint a tour"

consisting of a set of coordinates (via an extended version of the scheme mechanism)

A use case where an LBS application launches the navigation application with a destination and multiple waypoints (using the URI scheme mechanism for launching the navigation application)?

I believe this would be a more complex case of the use case above, or am I misunderstanding?

• add UseCase: to share/subscribe (updated) route-information

As I've noted below, I cannot think of a use case where an LBS application could usefully use that information, which is not already implementable using the geolocation or geocoding APIs. Could you give an example of the use case you have in mind?

• add Usecase: for the requirement 5.29, e.g. that there is a country

App, providing traffic rules valid for each country state, and provides a notification to the driver at point in time of crossing a country's frontier.

Added.

• add UseCase: to add something into a route list (e.g. restaurants

along the route from restaurant app) and this based on own interest of the user, specified in this app (e.g. via favorites) and under control of User by enabling this participation via settings.

Do you mean automatically? What is the user's participation in this use case: are they specifically interacting with a restaurant app and ask it to book them into a restaurant and add it as a navigation waypoint; or do they just want to see nearby restaurants highlighted on the map as they travel through an area?

I have a use case in the updated document which covers a restaurant application adding a waypoint into the current navigation route, if the user explicitly requests it (for example, by making a booking at the restaurant). Does that cover what you mean?

• add UseCase: for map-widget (with temporary integrated POI data)

its integrated data sources (position, destination, route, etc)

What is the use case for this? i.e. In what application context do you imagine this widget being used? I have been trying to think of an LBS application use case for exposing destination and waypoint information, and cannot think of one.

• add UseCase: for map-widget own responsibility in regard to

look&feel of embedding the widget, of embedded additional data, its interaction on selection events, and the overall functionality

Can you clarify this please? Do you mean that the map widget should always have the same appearance, regardless of which application it is embedded in?

• add  UseCase: to explain a SDK service provided for LBS Apps to ask

for input of a location which gets transformed to a geo-positon used for backend-server. "Type ahead search and completion for addresses" an optional extension / future feature

This (which is a description of reverse geocoding; please correct me if I've misinterpreted) is covered by the 'viewing an address on the map' use case, which I have reworded to apply to LBS applications rather than the navigation application.

NAVI:

• add UseCase: which describes the installation / exchange of a Navi

App, and with that the Technology/Backend used can be exchanged

Added.

• add Usecase (or a reference in some way) : which shows the relation

to sensor&Actuator API of a Navi App (e.g. use of vehicle speed or gyro / accelerometer data). Add a reference to this document

Added as 'navigation- and sensor-driven refinement of geolocation'.

• add UseCase: which shows that a majority of Navi related

configurations and parameter are (moved) into the App-internal scope (e.g. ambiguity resolution, routing parameter/preferences, handling/selection of alternative routes, consideration of traffic info, etc), instead of exposing them to external (SDK) API (similar like call-handling is a phone internal sequence, w/o coverage at SDK- API)

I have added a non-use-case for this.

• add UseCase: explains how a Navi App can produce data for other

(LBS) Apps  (becomes a backend replacement / a data server for SDK- API)

I believe this is covered already by the 'automotive backend' use case, which considers the navigation application and automotive backend to be fairly tightly coupled from the point of view of providing backend services for the SDK APIs.

• add UseCase (or a reference in some way): to handover/import POIs

(e.g. Traffic information) which we do have already separately covered in our wiki (add a reference). Via that usecase one can also explain, how a user is able to select data sources to be used by a Navi App by loading the one of interest from Store (out of various alternative sources for traffic information)

I have made sure there is a cross-reference to the POI design from the 'POI data' non-use-case section. I believe selecting POI sources for the navigation application should be internal to the navigation application. For other APIs (such as POI feeding into geocoding), I have updated the use cases to mention that the user should be able to disable it on an application-by-application basis.

Specific

• 3.2.1 the sentence "functionality may be exposed directly by the

backend and used by applications using specific APIs on the backend". To be honest, I would love to go for some SDK-APIs also for this extension. We can "tag" them as "product specific", but maybe something similar will be provided from other backends too. To having a "normalization" layer in-between is also beneficial from backwards compatibility point of view. If we have direct dependencies to App, we run short in compatibility tests.

The point of this use case was that such backend-specific APIs expose functionality which is //not// covered in the SDK API — if it were covered in the SDK API, they would not be backend-specific APIs! I will amend the document to clarify that the SDK APIs can be extended in future if it seems appropriate to standardise some functionality from multiple backends which was previously only available as backend- specific APIs.

• 3.5 sounds for me its a Navi-App internal feature and uses the app-

internal User preferences for route calculation.

Dropped.

• 3.6. from my point of view it’s a valid use-case, but to be honest

I do not see the specific topic which influences the requirements and API proposal for the scope of this document. For me it is similar like a Media Player app continues to render music if another App takes foreground focus.

The motivation for this use case was to ensure that routing is implemented as an agent and application, rather than purely as an application (which would stop being able to output audio if suspended or moved to the background).

However, that's a navigation-application-internal feature, so I have dropped the use case.

• 3.7. sounds for me like a Navi-App internal feature
• 3.8. sounds for me like a Navi-App internal feature

These use cases motivate geocoding APIs, and would be useful in an LBS context. I will rephrase them to be in an LBS context, rather than a navigation context.

• 3.9 change the scenario from "Navi" to "LBS" app. But to be honest,

this is not a first priority goal. This is very special for "address input", but since the SDK-API is for general purpose, one do not really know If the user types in a "address" or a "POI name". So "Eiffel Tower" is maybe not a valid address (in the meaning of city, street etc.), but it describes a location. Text-ahead search is maybe very challenging for that. This extended scope is very challenging for offline solution, because the database will increase to a significant size. This lead to online cloud based solution, which may have issues with availability or performance. However, lets keep the use case and see how far we come.

Agreed. I will rephrase the use case to be LBS-only, and re-evaluate the implementation suggestion to see how feasible it is.

-  3.10 sounds for me like a Navi-App internal feature. However maybe a good example for stuff covered App internally including handling of preferences, user interaction for selections etc.

• 3.11 & 3.12: can maybe changed to a usecase that an LBS App (e.g.

Hotel) sets a new (Intermediate) destination. The LBS App sets the destination, an app change appears to the running Navi app, and within the context of the Navi app the dialog appears how to deal with this new destination (set as new, add as waypoint etc.)

• 3.13 can maybe changed to a LBS App usecase, consuming the

"estimated time left" information to recommend a restaurant for break

I have repurposed all of these to be LBS-only use cases.

• 3.14 can maybe hanged to a LBS App usecase, subscribed for a new

route-info available and updating the POIs (e.g. hazard spots) along the (new) route in this list

That's a use case for the POI system; I think the best way to implement this would be for the navigation application to pull in a new set of POIs every time it changes the routing (or waypoints or destination).

• 3.15 can maybe modified to a usecase, where a traffic info App

_imports_  traffic data to the Navi App. Which one to use is configurable from the User via system settings.

I think this is also something to be handled by the POI system, using the TPEG data exported by traffic data applications. The navigation application should pull that data in.

• 3.16 sounds for me like a Navi-App internal feature. Extended infos

like (speed limits, hazard spots etc to be discussed (if this is notification is independently provided via some notification API, or if this gets merged into a turn-by-turn direction info. So far I would expect the first

Dropped.

• 3.17 may can be changed to LBS App, consuming it. However, we can

also keep this in a sense, that a Navi app can replace the backend and produce road info for the SDK-API.

I have dropped this one, because I cannot think of a use case where an LBS application would need to know road information.

3.18 from my point of view it’s a valid use-case, but to be honest I do not see the specific topic which influences the requirements and API proposal for the scope of this document. For me it is similar like a last User-Mode. 3.19 sounds for me like a Navi-App internal feature

Dropped. I have tried to think of use cases for where an LBS application might need to be notified of the navigation destination (and when it changes), but I can't think of any use cases which aren't already handled by using geolocation or geofencing.

3.22 also a valid use-case, 3rd party navi apps has to use some system info APIs

But third-party navigation applications are likely to come with their own locale database, and all they need to be able to use that is the vehicle's location, which they get from the geolocation API. I cannot think of other use cases for exposing locale information to LBS applications which are not served by the geolocation API, so I have dropped this use case.

3.23 the part "The system must continue to provide an estimated vehicle location to apps, with suitably increasing error bounds" should be limited to what is feasible w/o a full blown navigation map (including its local street data). All other parts, including dead reckoning should be left for 3.25. (an installed navigation App, consuming sensor / actuator data (e.g. vehicle speed and others), performs a map matching based on its own street data to process a dead reckoning and "provide" the more accurate location information for publishing to SDK-API (e.g. geoclue).

Changed.

3.24. sounds for me like a Navi-App internal feature. From an App centric point of view, the usual use case would be that the user opens the "address-book" App, enter the name of their friend, and he will use the friend's address for navigation and by setting it as new destination an app-change to the navigation App appears.

That is a valid use case, but is now essentially identical to one of the other use cases I have in the document (setting the navigation destination from a calendar event), so I will drop this one.

3.25. maybe consuming sensor / actuator data (e.g. actual vehicle speed, 3D-gyroscope data etc.) should be included in the description 3.26. please add a sentence, that a consumer/producer relation can be enabled / disabled by the User via System settings

Done.

4.1.: due to this use-case is mentioned in the section "NON-USE- CASE", one can misunderstand that these kind of usecases are not covered by our solution. But in fact it is, its only not part of this description. It would help to prevent misunderstanding, if these 2 very different kind of "not in scope" could differentiated more clearly.

Good point. I have added an introduction to §4 to clarify that these are non-use-cases //for this particular design//, and may be legitimate use cases for other designs.

4.3. to be honest, looks like I do not understand the Use-case. We would like to have a libchamplain map widget loading map tiles from backend providing OSM street data.

I was told that the automotive domain would definitely not be storing 2D map tiles for libchamplain, so they would not be sent over the inter-domain communication link; this non-use-case documents that fact.

I think we are in agreement: libchamplain’s map tiles will be loaded from a backend (in the CE domain) which provides OSM data.

In regard to the chapter 5 Requirements, I am already very fine. This situation ("gap" in UseCases but "fitment" of requirements) forces me to think about it and to start the chat on mailing list. However, please find enclosed the remaining feedback to chapter 5 - requirements

5.5. from my point of the, the part (via points) for "routing API" is not needed. For me it is App internal. Initiating a route sets a new destination (via the already described scheme mechanism). Then an app-Change appears to the navigation App, receiving the new request and then the handling of the new destination  (in case a tour is already running, asking for if it shall be added as a waypoint or canceling the current tour) takes place, and also the routing parameters (like include traffic info, routing parameters like fast/short etc, selection of one out of alternative routes, etc). Beside that use-case, we should also provide a mechanism to "imprint" a tour into a navigation. This will be done "restricting" the freedom of the navigation app based on providing waypoints in addition to the destination location. Lets see this as an extension of our scheme mechanisms, not only carrying one coordinate but a set of it. The navigation App has to handles this as a one request, and adding this into its current tour like describes before for a single coordinate.  However, the resulting exposed "route-list-info" needs to cover waypoints. So maybe it makes sense to distinguish between a "routing API" to set a destination (initiate a route calculation) and the "route-list info" to share and update details on the path.

I see. I have reworded that requirement and the following one to be navigation-application-centric.

5.11. support of various vehicle types sounds for me like a Navi-App internal feature. We can even have different Apps serving best for a particular vehicle type.  In addition, change of vehicle characteristics (being a car or a truck) is not a primary use-case for us, because so far we are fixed build in. So even if the characteristics change over products groups, its more or less fixed for one installation. Maybe we do have some dynamics via the sensor / actuator API, like trailer connected etc.(but also vehicle dimensions like height, width, maximum speed, etc) 5.12 sounds for me like a Navi-App internal feature

I have dropped both of these.

5.13 exposed SDK-APIs providing TTS capabilities should be offered for Navi Apps to be used for their generated turn-by-turn instruction (and then with the style of voice of the system), but an App developer can decide to use its own engine internally.

I have dropped this, because as you say, it is internal to the navigation application, which is able to use the SDK TTS API the same as any other application on the system.

5.14. yes, this would be a requirement to App-Developers providing a Navi-App. To split our the Guidance part (into an Agent) to enable a independent lifecycle of this executable.

Similarly, I have dropped this.

5.15. for me, the mentioned requirements belongs to libchamplain. And in regard to the question (vector or raster), lets start what is available e.g. raster maps and lets see what we need to enhance over time (e.g. use of vector maps). This is somehow a detailed feature roadmap discussion about the specific scope of the map-widget, so let me left it out for this feedback

That answers the open question, thank you.

5.16. please adopt the usecase mentioned (for LBS-Apps, instead of address Entry Navi destination input). We can also think about to embed this deeper into the keyboard. Similar like we support "forms", there could be a prepared one for covering the whole usecase for an App-developer.

Done.

5.17. for LBS-Apps, from my point of view this is more a lib- champlain feature. But maybe I am wrong.

libchamplain can give the latitude and longitude of a location on the map, but this requirement is about the forward geocoding API to convert that (latitude, longitude) pair into a postal address.

5.18. please keep in mind how to embed this into the keyboard. We have already features like "suggestions", "history" etc in scope of the keyboard.

I have added a sentence to mention that.

5.19. sounds for me like a Navi-App internal feature. This is also in some overlap with  5.5. - where waypoints are also mentioned. 5.20. sounds for me like a Navi-App internal feature. This is also in some overlap with 5.11., because vehicle types could be handled to some degree also as a parameter for routing algorithm. 5.21. sounds for me like a Navi-App internal feature

Removed.

5.22. please change the use case mentioned to an LBS one (embedding a map view into the App screen) and adding service specific additional information (like animated weather map overlays within a weather map, route proposal from tour guides, or hotel from a hotel app) However, for me this is some kind of feature discussion for the map widget. Today we use libchamplain, is supports some features, others will follow. Today its 2D. We can think about if the API (from libchamplain) is well already, should be enhanced or if we should use a separate one for 3D. This can also be a roadmap discussion, when we enhance what.

The use case which motivated the requirement for a 3D map was implementing a navigation application, but since that use case has been removed, I don't think there is now a motivation for a 3D map API, so I will drop this requirement. There might be individual applications which would benefit from a 3D map, but I think a 2D map (i.e. libchamplain) caters for 90% of all mapping use cases in LBS applications, so it would be unnecessary effort to provide a 3D map API in the SDK.

5.31. sounds for me like a Navi-App internal feature. But the Nav App can /dead-reckoning/ provide data (position with higher accuracy) - in the sense of exchanging the backend - to via the SDK-API to other Apps 5.32. same like 5.31

I have updated the wording in these to correspond to the requirements.

5.35. if I am right, then the mechanisms behind the transport of POI streams is the pipe approach already discussed in separately. Please bring this into relation to it. We had already some discussion in that regard at the point of time discussing the pipe mechanism. In an app-centric approach Business logic / policies belongs to the App who deals with the source. It is one bundle, covering HMI, logic, protocols etc. With that we leave it to the "provider" app (and its internal configuration done by the user via its HMI and preferences) to provide a reasonable amount of data. However, this freedom shall not lead to vulnerabilities, so malfunctional apps or attackers taking over a installed app, causing a deny of service attack needs to be handled well. With that we have to detect and terminate this kind of connections, but from my point of view this is easily possible by the consumer app by simple stopping consuming / closing the pipe.

Yes, a lot of these considerations belong in the POI design, but I will try and cross-reference to that design more clearly from the Geolocation and Navigation design.

Maybe we can collect all this Nav-App related requirements (like 5.5, 5.19, 5.11, 5.20, 5.12, 5.13, 5.14, 5.20, 5.21, etc) into one common (sub) chapter. Its maybe worth to keep & collect them to take care that a 3rd party, interesting in proving its solution to Apertis, get a better understanding what integration can be done / is expected. Please reflect if this would provide a benefit, and if so what should be addressed in this chapter.

Good suggestion. I have written a brief new chapter on this.

Following some comments in regard to section 6 - existing solutions

• please add a Reflection of what Genivi is doing

Added as section 6.8.

• 6.5.4. from my point of view, NavIt could be an App-internal

dependency for someone interested in create a nav App based on it. So it is worth to refer to it under the section Gnome, but from my point of view more in relation to an App then the Apertis System / OS.

Reworded slightly to reflect this.

• 6.7. same like for Navit, NavServer can be used to create a Nav-

App, but in contrast of an OSS solution it is a commercial one. Since the App Developer will align his solution accordant to the SDK-APIs available, from my point of view we can reflect as a second step if available solutions can fit to the defined SDK-APIs of the system instead of vice versa.

Reworded slightly to reflect this.

Following some comments in regard to section 7 - approach

• 7.3. no, that’s not the way to go. For the use cases - which are

pretty the same like the ones for 2D - and which focus on independence for LBS Apps to embed their content in a prepared map- view as also this map-view into the overall scene with full autonomy in regard to look&feel (clutter animations) -  as also in regard to reflect seamless transitions between 2D and 3D, we have to reflect which kind of framework does provide this freedom. We can reflect if libchamplain could/should be extended, we can discuss if opensceengraph provides a feasible framework for it or something on top, how do we get a clutter actor our of it and how can we influence the embedded POI animations etc. However, since this is not an urgent topic, if there is no immediate approach visible, we can put it onto the roadmap for later work.

Indeed, this part of the design can be removed as the use cases and requirements which motivated it have been removed. I will condense the design back down to a 2D map view (i.e. libchamplain), with navigation applications implementing their own 3D view internally.

• 7.6 please adopt it to a setup, where it gets realized as App,

maybe even as "build-in" App if we like to deploy a prepared solution.

Yes, I will rework this section substantially.

• 7.9. good to have a OSS solution. However, I would like to

understand how this would fit in case we are interested to use a google service (as a variant)

OK, I will add in a Google geocoding option as a variant. My initial thoughts are that this would become a backend for the same geocode-glib API, using the Google Maps Geocoding API. However, I will investigate it further before writing up my recommendations in the design.

I will also add an alternative design for the address completion component, using the Google Places API.

Are there any other alternative designs you want to be considered?

Philip

-----Ursprüngliche Nachricht----- Von: Devel [mailto:devel-bounces@lists.apertis.org] Im Auftrag von Philip Withnall Gesendet: Donnerstag, 12. November 2015 17:40 An: devel@lists.apertis.org Betreff: [Devel] Updated geolocation and navigation design document

Hi all,

Please find attached version 0.2.1 of the geolocation and navigation design document. This version incorporates feedback about swappable backends and the ability to back any of the APIs by an implementation in the automotive domain.

I have uploaded this version to the wiki as a draft. Further feedback is welcome and will be incorporated as normal.

https://wiki.apertis.org/File:Apertis-geolocation-navigation-design-0 .2 .1.pdf

Thanks, Philip

Hi Andre,

I think I understand most of your points here — just a few remaining questions about points of interest. I will start updating the other sections of the design tomorrow.

On Tue, 2015-12-01 at 14:31 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk]  Gesendet: Donnerstag, 26. November 2015 10:20 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; dev el@lists.apertis.org Betreff: Re: AW: [Devel] Updated geolocation and navigation design document

...

• add UseCase (or a reference in some way): to "imprint a tour"

consisting of a set of coordinates (via an extended version of the scheme mechanism)

A use case where an LBS application launches the navigation application with a destination and multiple waypoints (using the URI scheme mechanism for launching the navigation application)?   I believe this would be a more complex case of the use case above, or am I misunderstanding?   Andre: yes, thing about a tour city guide App, where you can find prepared tours. The difference is a little in granularity and with that quantity as also “meaning” of a waypoint.

Aha, I see.

A waypoint discussed so far reflects an (intermediate) destination, you keep freedom to the navi engine to calculate the route inbetween and there is typically a dedicated “intermediate destination reached” announcement of the route guidance component. But in this case you would like to “influence” the path, even if it is not an intermediate destination. You could go as far as really referencing every link (road element) on the track - and leave no freedom at all anymore to the routing engine – but that’s over specified. So as of now – like you said – we would simple go a “similar” (waypoint) mechanism with some more fine granular supporting points inbetween, but also _without_ “intermediate destination reached” announcement. So we do have to distinguish between both structs, maybe we do have to slightly extend the scheme mechanisms with some coordinates specifying a “via-area” in addition to “intermediate destinations”. Its up to the App to restrict or provide freedom to the Routing engine and with that to take care that the “supporting points“ are close enough to each other to make sure that the path is right where it matters, independent of the routing engine behind.   Some background info for future extensions: The reason to call this “via _area_” is, because the same mechanism could (in future) also be used (extended) for other usecases to influence the path. For example, if you like to travel (e.g. from Hamburg) to Rome, you can go via Paris or via Munich.  This does not specify an intermediate destination, you neither would like to reach a specific road in that area, nor would you like to get an “intermediate destination reached” announcement. Its only a “supporting point” in a more fuzzy description, which finally gets represented by some area (center point and radius). By using a wider or smaller radius one can influence how close the path has to hit the supporting point. This typically correlate to the type of location referenced to (specific point, a village, town, etc), so one can also keep this concrete mapping (to a dedicated radius) in the responsibility of the routing engine and only refer to a well-defined representative dimension. However, in general this (definition of via areas etc) should all be Navi App-internally (similar like call handling in an phone app), also depending on the Navi supporting this kind of features. An app only provides a destination, and the navi app handles if this shall replace the current destination, if it’s a new intermediate one, which one, as also if there should be via areas in between and what kind of routing parameters /fast, short, etc) are used. But for some dedicated use-cases, we may provide Apps some more capabilities to influences this in future.   Lets keep this functionality out of scope so far. I only explain it, to give you a bigger picture to keep it in mind during API definition. The goal is to have some kind of future proneness, i.e. that the next extension does not break the introduced API directly. You can think about if we have handle all in one scalable struct (i.e. an intermediated destination is only as specialization of a via area and all are waypoints), or if we use different things for it.

OK, I will incorporate the use case and try to ensure that the design does not make some of this future functionality more awkward.

...

• add UseCase: to share/subscribe (updated) route-information

As I've noted below, I cannot think of a use case where an LBS application could usefully use that information, which is not already implementable using the geolocation or geocoding APIs. Could you give an example of the use case you have in mind?   Andre: if there is route-information available, then we do have an active route guidance. The route guidance’s presents some information from the route to the User, e.g. the ETA (estimated time of arrival), destination and direction of next turn, etc. It also shows important POIs at the route, e.g. fuel stations, service areas, etc   If a 3rd Party App adds POI data to the is route-info, this will be included into this presentation (guidance). One can show where the next McDonalds is – if you have a McDonald’s app installed - , or some Touristic interesting things. The App can align the information with the preferences of the User, Driver Condition, Driving situation, the Vehicle Status, etc   see for example the Use-Case below (Restaurants)   Another perspective is, that the route information describes your track ahead. With that one can call It “horizon”. Apps can provide further details about the track ahead, e.g. hazard spots, weather conditions etc, which finally can be used to inform the Diver (via the guidance info) as also from deeply embedded functions in the car to adopt their functionality-   To be more abstract, it’s not (only) the way that POI information from all over the cloud gets loaded and imported into the navigation app and considered at point in time of route calculation, in contrast this use-case covers the scope that after a route has been calculated, additional attributes / extended information gets added to the path. So apps – reflecting a given cloud service / data – gathers their data accordant to the situation and adds this to the route-info. This does not influence the track itself (routing), but it informs the user, enables new actions as also will be used again from other (functions) Apps for their build in functionality.   Since it also influences other functionalities, we have to reflect the security (e.g. integrity) of data-providers. For example we could think about transporting the source of an information (e.g. which App).  Another aspect would be the quality of data, e.g. accuracy, age, etc   of data.

I see your meaning for the use case. If this is indeed all about what’s displayed in the navigation app, I believe this is entirely handled already by the points of interest design:

https://wiki.apertis.org/Points_of_interest https://wiki.apertis.org/Data_sharing

Specifically, depending on the answers to the questions in that design about the relative bandwidth of the POI streams, this can be implemented by:  • the navigation app queries POIs from a publish/subscribe POI service and displays them on the calculated route as appropriate; or  • the navigation app sends the calculated route as a query to a POI query interface (§(Consumer-initiated pull via a stream)); or  • the POI apps send their POIs to the navigation app which then chooses which ones to display on the calculated route (§(Provider- initiated push via a stream)).

The other suggested data sharing models are also possible here, depending on the bandwidth needed.

If it’s also about changing the behaviour of other applications to display data pertaining to the calculated route, then we will need another API for exposing that data, and it would be entirely unrelated to POI sharing.

...

• add UseCase: to add something into a route list (e.g. restaurants

along the route from restaurant app) and this based on own interest of the user, specified in this app (e.g. via favorites) and under control of User by enabling this participation via settings.

Do you mean automatically? What is the user's participation in this use case: are they specifically interacting with a restaurant app and ask it to book them into a restaurant and add it as a navigation waypoint; or do they just want to see nearby restaurants highlighted on the map as they travel through an area?   Andre: like said above, information from the route list will find its way to the route guidance (we sometime call this driver assistance information). So its not about reservation, its about information. A Restaurant App could provide recommendations for a rest stop, fitting to the driving time (e.g. a location area reached after 2 hours of drive), the day time (afternoon, evening, etc => coffee break, dinner, etc), the user preferences (Italian, vegetarian, etc) etc.   In relation the use-case above “add UseCase: to share/subscribe (updated) route-information” The App subscribes for changes in route list, and provides new POIs inc ae the path has been changed.

I guess I am not quite clear about the user experience here. With this restaurant use case, are you expecting the restaurant app itself to provide the recommendations //as part of its interface//; or are you expecting it to export them as POIs which will be displayed //by the navigation app as part of its interface//?

I suspect you mean the latter option, because the former would not make as much sense if the user had (for example) multiple restaurant applications installed — then they would have to look at each application in turn to see all the recommendations, and the look and feel of the recommendations would be under the control of those applications, rather than under the control of the OEM (who presumably wrote the navigation application).

Could you clarify this please?

I have a use case in the updated document which covers a restaurant application adding a waypoint into the current navigation route, if the user explicitly requests it (for example, by making a booking at the restaurant). Does that cover what you mean?   Andre: It should be possible for the user to select an information added to the route-list, (so from that point of view we againneed the source of information, i.e. which App has added what) After selection by the User,  the App gets launched and shows the detailed view of that POI. In the App internal scope, the User can proceed a reservation / booking (similar like phone handling Is app internal).   Booked POIs, lands in the app-internal list of reservations, and can be maintained / edited app internally At any point in time later.

OK, I’ll incorporate that into the document.

However, this brings me to another topic of cross app usage. Its also the same for Phone Handling. We do have a last mode of an App, which is the one the App has been left last time. It could be a Detailed View of a specific content, with some extensive tasks picked up before (email, call history, contact info,   Restaurant location, etc). Then the User left the App to home screen or some other App due to some reason. Now there is a cross reference from another App into (like mentioned before, also into communication Apps to share something – e.g email, or call handling etc). We should try hard to execute that cross reference (send a mail, book a restaurant, initiate a call), without jeopardizing the state of the full-blown app. So this may Lead us to the requirement to App- Developers, to provide a dedicated executable – an Agent – for this specific Task. This helps us also in minimzing resource needs and increasing reaction time.   Please add this to the right place – the right proposal - as take care that our design fits to it.

To be sure I understand you, you’re talking about ensuring that a task which is started by an application which is then sent to the background, is completed rather than (for example) being paused? Even while another application is in the foreground?

That has always been my understanding of how the system should work, and how agents and applications should interact.

...

• add UseCase: for map-widget (with temporary integrated POI data)

its integrated data sources (position, destination, route, etc)

What is the use case for this? i.e. In what application context do you imagine this widget being used? I have been trying to think of an LBS application use case for exposing destination and waypoint information, and cannot think of one.   Andre: An App like “Restaurants” shows Restaurants accordant to the User Preferences (only open ones, high user rating, time depending only Italian or Chinese etc) in an embedded map  (libchamplain). On selection of an POI in this map, the app shows extended POI information (pictures, comments, etc) to the User and vice versa in choosing a POI-Description in the App, the  map gets scrolled to the related location. For a  POI corresponding to the user interest, the user can initiate a route guidance (scheme based nav service with new destination corresponding to the coordinate info of the Restaurant).

Do you envisage this embedded map showing the vehicle’s current planned route? (Ah, you answered this already below!)

In regard to “temporary integrated POI data”: None of the added data (POIs, but also all other kind of added data like line or polygon once) has been imported to the Navi. it all resides in the Restaurant App. The “data responsibility” including their validity Resides in the POI App. The Navi App only gets a new destination.   The POI data is also not “imported” to libchamplain, its only shown in a separate layer during the lifetime of the App (temporary). Other Apps do not get them included in “their” map widget.

Agreed.

In regard to “integrated data sources” Even though data added to libchamplain by an App keeps the App boundary (its lifecycle and its data responsibility), the map widget Itself carries already lots of information gathered behind the scene (and with that shared over all apps). This is for sure the street data (e.g. tiles fetched from some backend) but beside that its also for example -       The current vehicle position (a moving, updated, vehicle cursor) -       Information (maybe a subset) from the route list, i.e. the destination (e.g. a flag), the intermediate destinations, the track itself, etc -       etc

That answers my question from above, thank you. This should all be possible by providing libchamplain map layers as part of the SDK APIs, which query the relevant geolocation or navigation service.

...

• add UseCase: for map-widget own responsibility in regard to

look&feel of embedding the widget, of embedded additional data, its interaction on selection events, and the overall functionality

Can you clarify this please? Do you mean that the map widget should always have the same appearance, regardless of which application it is embedded in?   Andre: no vice versa. Lets reflect again the scenario mentioned above: An App like “Restaurants” shows Restaurants in an embedded map accordant to its app internal style. On selection of an POIs in this map, the app shows extended information to the User and vice versa in choosing a POI-Description in the App, the  map gets scrolled to the related location. For a  POI corresponding to the user interest, the user can initiate a route guidance (scheme based nav service with new destination corresponding to the coordinate info of the Restaurant).   In an app centric solution we would like to enable freedom for Apps to present it accordant to its needs. So the App can define the size of the map widget, its position in the screen, it can add animated transitions to the whole widget (e.g. a backflip animation of the map, showing some preferences on the back side), and can also define the look & feel of Data added to the map (e.g. appearance animation of added POIs, i.e. own clutter actors).

OK, that’s all possible. What would not be easily possible is to allow the application to define how the map itself is rendered (for example, what colours are used for different grades of road), as libchamplain typically uses pre-rendered image tiles for its map, whose rendering we cannot affect.

For sure we prepare and provide templates to an App, for prepared screens, its transitions, as also for POIs added (e.g. a pin, with some falling from sky animation), but the App is free to use it.  So we never restrict it to it. The App has Freedom do go for an own way, w/o any need / impact to other apps. Its all about general purpose solitons and enabling.   Vice versa, if we have imported data into the navigation app, the data responsibility changes. Its like said already in regard to the validity (how long to store, when to delete data etc), but also in regard to the look & feel. The data imported into another App gets rendered like the other App likes to render it. If someone likes to change it, someone has to discuss this with the other App-Owner.   Hope you get what I mean.

That’s all clear, thank you.

...

• add  UseCase: to explain a SDK service provided for LBS Apps to

ask

...

for input of a location which gets transformed to a geo-positon

used

...

for backend-server. "Type ahead search and completion for

addresses"

...

an optional extension / future feature

This (which is a description of reverse geocoding; please correct me if I've misinterpreted) is covered by the 'viewing an address on the map' use case, which I have reworded to apply to LBS applications rather than the navigation application.   Andre: its slightly different. Lots of LBS Apps do need for their backend service a geo-coordinate. But that’s not the information a User like to type in. A User likes to provide a name (a city, a complete postal address, a name an interesting location, etc). To take care that not each and every App now has the challenge to derive a geo-coordinate from a given name (and every app does this in another way and in different “quality”) a central service should cover that. In best case, this is also embedded in the keyboard, as a special form.

Yes, this is precisely what the reverse geocoding service is designed to do: convert a human-written place name or address into a coordinate (or list of coordinates if the search is ambiguous).

This is also covered by the type-ahead search requirement in the design, which recommends that we provide a widget where type-ahead suggestions are integrated already, so application developers do not have to reimplement the search functionality.

• add UseCase: explains how a Navi App can produce data for other

...

(LBS) Apps  (becomes a backend replacement / a data server for SDK- API)

I believe this is covered already by the 'automotive backend' use case, which considers the navigation application and automotive backend to be fairly tightly coupled from the point of view of providing backend services for the SDK APIs.   Andre: yes, but here it is meant more in relation to “integration of Navi Apps” (the separate chapter), because in this separate chapter an 3rd party interested in integrating its navi solution should not only know what needs to be done to get it running at all (from a consuming perspective), but also what kind of data/interfaces should be exposed (from a producing point of view).

I see. I will try and make that clearer in the appendix which covers recommendations for third-party navigation applications.

...

• add UseCase (or a reference in some way): to handover/import POIs

(e.g. Traffic information) which we do have already separately covered in our wiki (add a reference). Via that usecase one can

also

...

explain, how a user is able to select data sources to be used by a Navi App by loading the one of interest from Store (out of various alternative sources for traffic information)

I have made sure there is a cross-reference to the POI design from the 'POI data' non-use-case section. I believe selecting POI sources for the navigation application should be internal to the navigation application.   Andre: yes, but please keep in mind that the method of “selection” is _not_ based on “business logic” within the navi software, but by the User. So the User will make his decision in the context of the Navi App (its setting & preferences, similar like access to a camera roll gets granted or not). The Navi App exposes its interest, the User grants it or not and can it change at every Point in time. Via this mechanism, the user can “configure”, which sources to use.

I see. This would be an instance of manifest permissions which are checked at runtime, when the navigation application tries to query the POI API (and this may result in the POI service prompting the user to allow or deny the request, then saving the result). I will update the document to cover this.

...

Specific

• 3.2.1 the sentence "functionality may be exposed directly by the

backend and used by applications using specific APIs on the

backend".

...

To be honest, I would love to go for some SDK-APIs also for this extension. We can "tag" them as "product specific", but maybe something similar will be provided from other backends too. To

having

...

a "normalization" layer in-between is also beneficial from

backwards

...

compatibility point of view. If we have direct dependencies to App, we run short in compatibility tests.

The point of this use case was that such backend-specific APIs expose functionality which is //not// covered in the SDK API — if it were covered in the SDK API, they would not be backend-specific APIs! I will amend the document to clarify that the SDK APIs can be extended in future if it seems appropriate to standardise some functionality from multiple backends which was previously only available as backend- specific APIs.   Andre: for me it looks like this is a very specific use-case. An App, who uses APIs not part of the SDK becomes a build-in App (formerly named as core-apps) and needs to be updated with the OS. It has a tight relationship, and since we only guarantee backwards compatibility for the SDK, the update path (bundled with the OS) changes. (see applications proposal).   We intend to use this way to bridge 'automotive backend' functionalities via representative Agents. These Agents becomes then “build-in” ones,  and they use some backend-specific APIs for implementation. But its not to expose this backend-specific APIs to other Apps, its more like a Web-App uses a proprietary API to connect to its Backend and the same will happen for the Agent using a proprietary interface to its automotive Backend. However, the connection to automotive Backends will be discussed further in the scope of “Interdomain Connection” Proposal. We will See on what we conclude finally.

Indeed, shall we come back to this point after you’ve finished reviewing our proposal for the Inter-Domain Communications design.

...

• 3.6. from my point of view it’s a valid use-case, but to be

honest

...

I do not see the specific topic which influences the requirements

and

...

API proposal for the scope of this document. For me it is similar like a Media Player app continues to render music if another App takes foreground focus.

The motivation for this use case was to ensure that routing is implemented as an agent and application, rather than purely as an application (which would stop being able to output audio if suspended or moved to the background).   However, that's a navigation-application-internal feature, so I have dropped the use case.   Andre: thx, that a valid one. We should put this into the special chapter Which explains to 3rd parties “how to integrate a navi app”.

Will do.

...

• 3.9 change the scenario from "Navi" to "LBS" app. But to be

honest,

...

this is not a first priority goal. This is very special for

"address

...

input", but since the SDK-API is for general purpose, one do not really know If the user types in a "address" or a "POI name". So "Eiffel Tower" is maybe not a valid address (in the meaning of

city,

...

street etc.), but it describes a location. Text-ahead search is

maybe

...

very challenging for that. This extended scope is very challenging for offline solution, because the database will increase to a significant size. This lead to online cloud based solution, which

may

...

have issues with availability or performance. However, lets keep

the

...

use case and see how far we come.

Agreed. I will rephrase the use case to be LBS-only, and re-evaluate the implementation suggestion to see how feasible it is.   Andre: yes, lets look about the capabilities of backends. In addition - since an installed Navigation _can_ become a data provide for one, multiple or all backends - this would one more type of data  which can be replaced/provided by an installed navigation backend. So we would have map tiles for libchamplain, position for geoclue, route-list for “tbd SDK-API”, etc and now “transformation of a location name to a geo-position with text-ahead support”

Indeed, the requirement for supporting multiple backends would apply equally to this API as others.

...

• 3.14 can maybe hanged to a LBS App usecase, subscribed for a new

route-info available and updating the POIs (e.g. hazard spots)

along

...

the (new) route in this list

That's a use case for the POI system; I think the best way to implement this would be for the navigation application to pull in a new set of POIs every time it changes the routing (or waypoints or destination).   Andre: like explained above, we will have different sinks of POIs, aligned with the different purpose and also with related data responsibility. -       in “libchamplain” for User interaction / selection (aligned with App lifecycle/) -       in “route list” as extended information / attributes (aligned with lifecycle of a route) -       in “Navigation” (via on pull-mode and interface discovery htt ps://wiki.apertis.org/Points_of_interest) as data import (and with that also a hand over of data responsibility, persistent storage, validity, user presentation and also embedding into its build in functionality like route calculation)   So there is not _one_ POI system. Hope the 3 different purposes are now more clear. The use case mentioned in 3.14. deals with POIs provided to the route-list.

I think this is clear. I was using the term ‘POI system’ to mean the POI API or service which collates POIs from various POI providers, and makes them available to the POI sinks as part of a publish/subscribe- style system. Maybe I could better have said ‘POI publish/subscribe system’.

In all three cases here, I think the POIs are coming from the same pool of sources. The differences arise in how long the sinks keep the POI data, how they process it, and which of the POIs they consider interesting. Am I following your thinking correctly?

...

• 3.17 may can be changed to LBS App, consuming it. However, we can

also keep this in a sense, that a Navi app can replace the backend and produce road info for the SDK-API.

I have dropped this one, because I cannot think of a use case where an LBS application would need to know road information.   Andre: see above in regard to use-cases, where an app likes to know road information of the track ahead. E.g. for Hazard spot warning, rest station, etc,

OK, I will re-add this one and rephrase it accordingly.

...

3.18 from my point of view it’s a valid use-case, but to be honest

I

...

do not see the specific topic which influences the requirements and API proposal for the scope of this document. For me it is similar like a last User-Mode. 3.19 sounds for me like a Navi-App internal feature

Dropped. I have tried to think of use cases for where an LBS application might need to be notified of the navigation destination (and when it changes), but I can't think of any use cases which aren't already handled by using geolocation or geofencing.   Andre: again, see above. If the route changes, the restaurant app would like to update the rest stations recommended to the user. That not geolocation as also not geofencing.

OK.

...

3.22 also a valid use-case, 3rd party navi apps has to use some system info APIs

But third-party navigation applications are likely to come with their own locale database, and all they need to be able to use that is the vehicle's location, which they get from the geolocation API. I cannot think of other use cases for exposing locale information to LBS applications which are not served by the geolocation API, so I have dropped this use case.   Andre: at least the position of crossing a border could be of interest. An App could use this information to set a geofence and to inform the User about something (e.g. traffic regulations) once he is close by. Or Apps could use this information to align their recommendations etc.  However, this a very special detail, and we can extend the scope / data carried in route list also over time.

OK, we can come back to this one later.

Another topic is, that Navi Apps may use more than the vehicle’s location for processing. They may need information about the type of vehicle (dimensions, etc), if a trailer is connected etc.

That should be covered by the vehicle data/sensors and actuators API, which navigation applications are able to use.

...

4.3. to be honest, looks like I do not understand the Use-case. We would like to have a libchamplain map widget loading map tiles from backend providing OSM street data.

I was told that the automotive domain would definitely not be storing 2D map tiles for libchamplain, so they would not be sent over the inter-domain communication link; this non-use-case documents that fact.   I think we are in agreement: libchamplain’s map tiles will be loaded from a backend (in the CE domain) which provides OSM data.   Andre: no, that’s a misunderstanding. Map tiles will be loaded from a backend (in the CE domain) which provides OSM data, that’s right. We will use this setup also for the SDK environment.   But lets keep the use-case also for the automotive domain setup and with that the inter-domain communication link. Lets cover it concept & design wise and lets see when we implement it.

OK, I will reinstate the use case, but indicate that it is potentially for implementation in the future.

...

5.17. for LBS-Apps, from my point of view this is more a lib- champlain feature. But maybe I am wrong.

libchamplain can give the latitude and longitude of a location on the map, but this requirement is about the forward geocoding API to convert that (latitude, longitude) pair into a postal address.   Andre: I see. Again a backend service which – in case a navi app is installed - can be provided by the navi app to.

Precisely. The forward geocoding API will also support multiple backends.

...

5.22. please change the use case mentioned to an LBS one (embedding

a

...

map view into the App screen) and adding service specific

additional

...

information (like animated weather map overlays within a weather

map,

...

route proposal from tour guides, or hotel from a hotel app) However, for me this is some kind of feature discussion for the map widget. Today we use libchamplain, is supports some features,

others

...

will follow. Today its 2D. We can think about if the API (from libchamplain) is well already, should be enhanced or if we should

use

...

a separate one for 3D. This can also be a roadmap discussion, when

we

...

enhance what.

The use case which motivated the requirement for a 3D map was implementing a navigation application, but since that use case has been removed, I don't think there is now a motivation for a 3D map API, so I will drop this requirement. There might be individual applications which would benefit from a 3D map, but I think a 2D map (i.e. libchamplain) caters for 90% of all mapping use cases in LBS applications, so it would be unnecessary effort to provide a 3D map API in the SDK.   Andre: yes, its not intended for implementing a navi app. However, it’s stays a roadmap topic even that it’s intended for LBS Apps only. I agree that a 2D maps serves well for the majority of LBS Apps, but sometimes OEMs like to push the limits. And since Smartphone Ecosystems provide already some “perspective 2,5D view”, Navi Apps itself provides full 3D view, it may appears that to be up-to-date we have to embed 3D capability also into the map view for LBS Apps. To provide a modern and feature rich user experience.   So keep it on the roadmap, its nothing urgent yet.

OK, I will include it in the document again as a potential future feature.

Are there any other alternative designs you want to be considered?   Andre: so far it seems sufficient for me to reflect Google services as backend replacements. On the one hand they have a good footprint in this area, and they also serve well as a representative scenario for proving the flexibility.   However, do not to forget, that an installed Navi app can replace single up to all backends, and that with that it could also be provided by “automotive backends” via the interdomain communication.

The need for multiple backends is firmly embedded in my thoughts about the design!

Philip

On 19/01/16 14:13, Barkowski Andre (CM-CI1/PRM1) wrote:

no, we still have a fundamental mismatch, the purposes are very different. I feel its hard to discuss all that via email, but lets try:

I think you and Philip are using the term "navigation app" to mean different things, which has led to some confusion.

It sounds as though we have two components:

* The navigation service (possibly in the automotive domain), which receives location and a limited set of POI, plots routes, etc.

* The assistance window (navigation UI), which draws the route provided by the navigation service

I think when Philip and I have talked about "the navigation app", we've mostly been thinking of the assistance window. When you talk about "the navigation app", are you primarily referring to what I've called the "navigation service" here?

Which one do you intend to be potentially end-user-swappable, for instance via an app store - the navigation service, or the assistance window, or both?

I suggest we try to avoid "navigation app" as a term if it's going to be this confusing, and find a more precise description of each part that needs to be a separate entity.

Hi Andre,

I think Simon is correct in that we were not clear on terminology. Due to the fact that the navigation application bundle is provided as a black box, I was using the term ‘navigation application’ to mean all of:  • a navigation UI for choosing a destination and planning a route;  • a guidance UI for providing guidance for that route while driving, potentially also showing points of interest along the way; and  • a navigation service which provides the (non-SDK) APIs used by the two UIs, and can act as a backend for the various SDK geo-APIs.

These two UIs may be part of the same application, or may be separate applications (for example with the guidance UI as part of the system chrome). The navigation service may be a separate process, or may be combined with one or both of the UI processes.

The navigation service might communicate with systems in the automotive domain to provide its functionality.

Essentially, I have been viewing the ‘navigation application’ as a black box which provides UIs and (non-SDK) services related to navigation, and hence have not been differentiating the term.

I believe you were thinking I was using ‘navigation application’ to mean just the navigation UI.

I will reply to your other e-mail with this in mind.

Philip

On Tue, 2016-01-19 at 14:58 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

Hi Simon,

i agree, we have to align our understanding of the scopes.

We do have a an "App-Bundle" for Navigation. Its more than the "service". Beside the "services" like positioning, route calculation etc, it also covers HMI for destination input, and also the map rendering including the rendering the route in its navi map. And to make is also concrete, the App-Bundle can decide not to use libchmplain for it, its their internal stuff rendered once the App is in foreground.

The only thing I am talking about is the "guidance". That’s an additional separated scope compared to the once mentioned above.

For sure this can also be handled in the black box internal scope of the App-bundle, that’s not forbidden. Since this does not need any further APIs we do not need to discuss this setup in more detail. But I like to push the limits and not to restrict it to a build-in solution only. So this special part I like to separate and to put an SDK-API in-between and to request an Agent to be delivered by the App-Developer to expose data to it.

The visual representation of this data gets realized by some system chrome software belonging to the OS.

In the picture enclosed, the map shown on the right part is rendered by the app-bundle, based on their own technology of choice (including data received via a pipe from 3rd party apps). The Assist window shown on the left part is rendered by the OS, based on data received via SDK-APIs from various Apps. In between we see a minimized part of the App-Launcher, which can be used to switch between Apps.

Rgds Andre

-----Ursprüngliche Nachricht----- Von: Devel [mailto:devel-bounces@lists.apertis.org] Im Auftrag von Simon McVittie Gesendet: Dienstag, 19. Januar 2016 15:33 An: devel@lists.apertis.org Betreff: Re: [Devel] Updated geolocation and navigation design document

On 19/01/16 14:13, Barkowski Andre (CM-CI1/PRM1) wrote:

...

no, we still have a fundamental mismatch, the purposes are very different. I feel its hard to discuss all that via email, but lets try:

I think you and Philip are using the term "navigation app" to mean different things, which has led to some confusion.

It sounds as though we have two components:

• The navigation service (possibly in the automotive domain),

which receives location and a limited set of POI, plots routes, etc.

• The assistance window (navigation UI), which draws the route

provided   by the navigation service

I think when Philip and I have talked about "the navigation app", we've mostly been thinking of the assistance window. When you talk about "the navigation app", are you primarily referring to what I've called the "navigation service" here?

Which one do you intend to be potentially end-user-swappable, for instance via an app store - the navigation service, or the assistance window, or both?

I suggest we try to avoid "navigation app" as a term if it's going to be this confusing, and find a more precise description of each part that needs to be a separate entity.

--  Simon McVittie Collabora Ltd. http://www.collabora.com/

---

Devel mailing list Devel@lists.apertis.org https://lists.apertis.org/listinfo/devel _______________________________________________ Devel mailing list Devel@lists.apertis.org https://lists.apertis.org/listinfo/devel

Hi Philip,

I feel we are still not fully on the same page. We closed some gaps lately (in regard to the assist-window), but it seems to me that we still have a gap in regard to POI handling itself.

So summarize, let me go one step back and start with - POI service is _not_ equal to route-list. I am talking about a route list, you are talking about a central poi service.

Let me add: - we do _not_ need a central POI service, or vice versa I am not aware about a related requirement.

We do have the already mentioned 3 Use cases and the mechanisms discussed covers the use-cases already perfectly 1) for in app UI browsing: libchamlain. We have it, fine. 2) for app import / handover: Pull mode for various types of content – also TPEG based POI data - https://wiki.apertis.org/Points_of_interest (For completion there is also a push mode for various types of content – so far no need for TPEG support - https://wiki.apertis.org/Data_sharing ) again, we have it designed already. 3) now we add the route-list to the SDK-API, where I also ask to provide capabilities to add POIs to it (independent from the navi-app) In any case we do need the route list, it has originally nothing to do with the POI discussion. Apps shall be able to consume information about the current route and to create some functionality. That the purpose of the route list essentially.

Based on that scope, I am asking for the additional functionality to add Metadata/Content from Apps directly to it, especially POIs. Its neither a first priority nor will it dramatically change the design. Its simple an add-on. We can even decide to implement it later.

Similar stuff is valid for the guidance & assist window discussion. The APIs for the “guidance” (which is “just another notification style API for a dedicated purpose”) as also the assist window (which is just another system chrome application where for example the data exposed via the guidance notification style SDK-API lands in) are optional and don’t have side effects to other SDK-APIs. So we can implementation wise realize it in a later step, its not of first priority. However, I like to have a common understanding about the overall scope early.

If we provide capabilities to add metadata into an available route-list to Apps, other Apps (than the navi app) can add additional content/ additional metadata to available content, for example POIs into a currently shared route list. Since we have already libchamplain and also the Point_of_interest and sharing mechanisms design, My focus is on just one more method for that route-list. I am _not_ talking about any big thing, especially not about a central POI service.

I would like to propose we serialize the discussion. How about first finalizing the solution for the route list, including POIs into it from Apps via an SDK API. Then reflect, for what a central POI service could be beneficial ?

I have embedded some comments below in green.

Rgds Andre

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Mittwoch, 20. Januar 2016 16:57 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; devel@lists.apertis.org Betreff: Re: AW: AW: AW: [Devel] Updated geolocation and navigation design document

Hi Andre,

With our clarification of the term ‘navigation application’ in mind (see my e-mail from earlier today in this thread), I think we are on the same page about these points. I’ve replied inline below, and will send out a new version (0.3.1) of the design shortly, which will hopefully clarify some of the ideas I refer to a little more.

On Tue, 2016-01-19 at 14:13 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

Andre: no, we still have a fundamental mismatch, the purposes are very different. I feel its hard to discuss all that via email, but lets try: With the referred APIs (point_of_interest) we hand over data _responsibility_ form one (source-app) to another (sink-app). The “navigation app” imports that data, from that point in time any further data management (duplicate handling, persistence storage, validity, usage in various embedded services like destination input, route calculation, etc) in in their internal (black box) responsibility. The mechanism is simple a point-to-point data pipe, deliver and forget. We do not flood the navigation app by providing to it all information available, only information which shall be handed over into their responsibility, so typically which shall influence their routing. We do _not_ import all mac-donalds data into the navi app. This stays in the mac-donalds app, it gets browsed within this app etc.

The points of interest API supports filtering the set or stream of PoIs which an application receives, so if the navigation UI needs to show a specific set of PoIs (fuel stations, for example), it can request from the PoI service to only receive those.

Andre: like said, lets skip the central POI service for now. We do have https://wiki.apertis.org/Points_of_interest. I hope we are inline in regard of its functionality and do not have a mismatch there: There is a control flow with an OS service validating if a data flow is allowed, then a pipe gets established with proper access rights for producer App and consumer app. That’s it. The provider App forwards POI data in TPEG format, the policy which data gets forwarded is in responsibility of the provider App. The consumer App gets no way to influence it. Its all in the scope of the producing app. It has its policy, its user interface etc. The consumer App handles the data validity in its own scope (persistence storage, duplicate detection, validity, etc), it “imports” the provided data. In addition all pipes are dedicated, so we have multiple dedicated (and private) provider / consumer connections, and all consumers gets the same data. This fits to an app centric approach. Even though the first interaction is based on dbus, its not a “client server model way” where parameters / request can be defined and the data gets centrally stored.

Even though it is a pull mode, it is finally controlled by the User (by allowing connections via settings, as also selecting the provider of choice if there are multiple and with that also the policy he likes)

Beside the stuff said for Inter-App Communication, there is an additional sink – again used by other Apps as they consume the Route List but also for the optional Assist Window. This data runs via the route list, so the Provider App can implement a policy which decides a subset to be provided into the Route List.

Please keep also in mind, that the navigation app itself is somehow special in regard to their output. Beside provides some UI to control its functions like all the other apps (e.g. media player), the “route guidance” information is very special. In addition to a black box build-in solution for the route guidance - like all the smartphone Smartphone solutions realizing today – (on prompt the guidance is only acoustic or an app-change transition to the navigation app appears) we will go a step forward for this driver related information. The guidance will be presented to the user independent of the current App in use in foreground. So you can “leave” the navi- app but the guidance shall continue. In fact we influence the internal design by requesting an agent to be provided by the app- developer to deliver these data. And that’s not only an acoustical prompt, its also data which gets finally a visual representation (turn icons, lane information, etc). In this approach via an SDK-API the rendering gets done by some system service. Its more like a “notification”/“dialog-box”/“status framework” stuff (please have a look to the running status framework and the relation to assist framework too). So the navigation App provides its data as output to some SDK-API. In fact part of this is the route list, which finally land in that guidance dialog. Lets call it assistance window – driver related information.

I see. The way I would recommend doing this in the design is to implement the guidance UI separately from the navigation UI. It could potentially be part of the same application bundle, or part of a different one, or even implemented as part of the system chrome.

Andre: to be honest, this all is optional. A navi app developer can decide to implement the guidance in its local app-bundle scope. Then the UI appears within its own App Screen Area. However, since it is beneficial (independent from the POI or Assist Window Discussion) that the guidance portion is separated from the rest of the full-fledge App (because it enables us to handle a separated executable with its own lifecycle, which means we can keep only that part running in background instead of the Full App) we should ask for an Agent for it. The App developer can decide to do so or not. So the requirement for isolating the Guidance into an Agent is already valid w/o all the discussion about POIs and/or Assist Window. On top of that we like to also support an assist window solution as part of our system. Therefore we will provide a notification style similar API for driver related information. Guidance data will be covered by it, and if a Navi App developer decided to use this SDK-API, the guidance information will land there (but also information from route list will land in such an assist window). Similar like mentioned above, we like to ask the developer to provide an agent for the guidance data. However, the assist window (the UI for the guidance) is finally a system chrome element and not deployed with the App bundle. It belongs to the OS and gets distributed with it.

The guidance UI would take data from the SDK points of interest API, and from the SDK navigation route guidance API (§7.6). This would allow it to render the route (from the guidance API), and points of interest along the way (from the PoI API).

The navigation UI (where the driver chooses their destination and plans the route) may retrieve points of interest from the SDK, or may choose not to if the developer thinks they will be distracting.

i.e. The SDK API you are suggesting for the data from the guidance UI is effectively the points of interest API plus the navigation route guidance API.

Andre: like said, its not the “points_of_interest” API, its from the route-list API.

To this route list, other apps can directly add further data. This is _not_ forwarded to the navi-app, it does not modify the route list nor does it gets stored by the navi-app. The navi app don’t has any interest in getting and managing it. This data, gets provided by the source app to the rout–list and with that finally rendered to the user by some system service (assist window). On the other hand, other apps can consume this enriched route list again for their build-in functions and policies. Its all outside the navigation, the navi only provides the initial foundation.

That’s possible due to the split between the navigation UI and the guidance UI. The navigation UI can choose to not query for points of interest, or can heavily filter the PoI requests it makes. Conversely, the guidance UI can query for lots of PoIs.

If other applications want to display something similar to the guidance UI, they must make the same navigation route guidance API and PoI API queries as made by the guidance UI. This should be simple to do, and allows each application to further customise the points of interest they display.

Andre: to be honest, the use-cases behind that stuff is _not_ that another app will do something similar like the guidance UI. Other Apps uses information form that API for their essential service, e.g. if an App of a weather service does know intermediate destinations from the route list, it may decides to show entries on top of the stored locations for current destination and intermediate destinations (in todays list you have the current positon for example as a default, this app could extend that approach depending on stuff from the route list).

Or if a gasoline station app adds a refueling stop into the route list for a location to be reached at a time where the car runs low on fuel, a restaurant app may uses this information to add recommended cafeterias into the route list to align the breaks for the driver.

Or if a restaurant app decides to add restaurant POIs as recommendations into the route list for a location to be reached at a time where a break would be wise, a installed “coupon” app may add available discounts available at this location.

etc.

Specifically, depending on the answers to the questions in that design about the relative bandwidth of the POI streams, this can be implemented by: • the navigation app queries POIs from a publish/subscribe POI service and displays them on the calculated route as appropriate; or • the navigation app sends the calculated route as a query to a POI query interface (§(Consumer-initiated pull via a stream)); or • the POI apps send their POIs to the navigation app which then chooses which ones to display on the calculated route (§(Provider- initiated push via a stream)). Andre: 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. 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 providing this data, on the other hand it’s the data responsibility, which does mean Points_of_interest API gets used to handover the responsibility and this will be done only for a very small subset (relevant for route calculation)

I think this is covered by my points above. If it becomes necessary to add a PoI service to cache points of interest queries between applications, I believe that can be done much later without affecting the PoI design significantly. There is no need to add one from a security point of view, which is the normal requirement for adding a service.

Andre: like said, it’s the route list, not a central poi-service I am talking about. To be honest, I am stressing this because data in that scope is not limited to POI. POIs are belonging to it, but its not only point, also lines, turns, attributes, etc But Yes, adding POIs from an App into this list other than the navigation can be added later.

The other suggested data sharing models are also possible here, depending on the bandwidth needed. If it’s also about changing the behaviour of other applications to display data pertaining to the calculated route, then we will need another API for exposing that data, and it would be entirely unrelated to POI sharing. Andre: yes, that’s part of the scope.

Right. That API is the navigation route guidance API, and is at section 7.6 of the latest design.

...

...

• add UseCase: to add something into a route list (e.g.

restaurants

...

...

along the route from restaurant app) and this based on own

interest

...

...

of the user, specified in this app (e.g. via favorites) and under control of User by enabling this participation via settings.

Do you mean automatically? What is the user's participation in this use case: are they specifically interacting with a restaurant app and

ask

...

it to book them into a restaurant and add it as a navigation waypoint; or do they just want to see nearby restaurants highlighted on the

map

...

as they travel through an area?

Andre: like said above, information from the route list will find

its

...

way to the route guidance (we sometime call this driver assistance

information).

...

So its not about reservation, its about information. A Restaurant

App

...

could provide recommendations for a rest stop, fitting to the driving

time

...

(e.g. a location area reached after 2 hours of drive), the day time (afternoon, evening, etc => coffee break, dinner, etc), the user preferences (Italian, vegetarian, etc) etc.

In relation the use-case above “add UseCase: to share/subscribe (updated) route-information” The App subscribes for changes in route list, and provides new POIs inc ae the path has been changed.

I guess I am not quite clear about the user experience here. With this restaurant use case, are you expecting the restaurant app itself to provide the recommendations //as part of its interface//; or are you expecting it to export them as POIs which will be displayed //by the navigation app as part of its interface//? Andre: like explained above, please don’t see the Navi app as the final sink. It has a relation to a system service to expose its notification to the driver. <<...>> <<...>> <<...>> The “user interface” is part of a system chrome, we call it “assist window”. Its like a notification center, but for driver centric information. The navi-app provides data to it, but other apps too. For each product variant, we implement a UI customization for the look & feel of this “driver notification center”. Once the user tap on an object in that view, the related app gets launched. 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. There can also be “POI data” w/o any active navigation (route guidance). In case there is no destination set (and with that no route list) apps can provide POIs surrounding the current geo position (e.g. hazard sport warnings, touristic info, etc). The user can define via system settings if an app is allowed to expose data to this center (like in a usual notification center)

I think this is covered by my points above.

...

Please add this to the right place – the right proposal - as take care that our design fits to it.

To be sure I understand you, you’re talking about ensuring that a task which is started by an application which is then sent to the background, is completed rather than (for example) being paused? Even while another application is in the foreground? Andre: My focus is less the completion in background, my focus is independence (or vice versa side-effects) caused by remote calls. It’s a kind of “multi-threading”, even w/o multi-user capabilities. But to skip the software terminology, think about having a user driven path (assume you start writing an email in email client) and an inter-app communication (user interrupts email writing, leaves the app, [email state in background is still in editing mode of the last mail], launches browser, jumps to a url and renders the page, and then he gets in mind to “share” that page with some friend, initiates sharing mechanism, selects via email, an editing view of email slides in with the given url embedded). This task shall _not_ 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 the new one is executed on behalf of browser. If the user switches back to browser, he gets the sharing screen on top, etc. Its typical iOS behavior, so you can reflect it quite easy.

I think that is the behaviour we are aiming for, although it depends to a certain extent on application developers implementing their applications to behave correctly when focus changes and another activation request comes in. Andre: agreed. But we have to provide awareness, recommend separate agent for this interaction, and may test it (if they participate at the “sharing mechanism” for exposed data types, during validation we have to test that it is instantiable.

...

In an app centric solution we would like to enable freedom for Apps to present it accordant to its needs. So the App can define the size of the map widget, its position in the screen, it can add animated transitions to the whole widget (e.g. a backflip animation of the map, showing some preferences on the back side), and can also define the look & feel of Data added to the map (e.g. appearance animation of added POIs,

i.e.

...

own clutter actors).

OK, that’s all possible. What would not be easily possible is to allow the application to define how the map itself is rendered (for example, what colours are used for different grades of road), as libchamplain typically uses pre-rendered image tiles for its map, whose rendering we cannot affect. Andre: yes, the tiles are ok. I referred to freedom for data _added by the App_ That’s not the tiles, but additional icons, points, polygons, etc. Even for these we can prepare some fitting well to the overall look&feel, e.g. “blue pin falling from sky” for POIs, but an app my create on own clutter actor for its POIs and use them for the representation of its additional data.

Definitely all possible (and easy) with libchamplain.

In all three cases here, I think the POIs are coming from the same pool of sources. The differences arise in how long the sinks keep the POI data, how they process it, and which of the POIs they consider interesting. Am I following your thinking correctly? Andre: to be honest, I am thinking in another direction. Its driven by responsibility and data management. In regard to the first topic: There is stuff which gets embedded into libchamplain which stays completely in the App responsibility. Its for User Interaction, nothing else. It uses libchamplain APIs (clutter) to embed POIs. The user can interact with it and libchamplain informs the App about content selected which has been included by it. So nothing from a central POI service in that regard. 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. Nothing central in between for the data flow, only for the control flow some SDK-API has been used.

My suggested design for implementing the guidance UI avoids the need for tunnelling points of interest, by keeping the points of interest API separate from the navigation route guidance API. If the two were combined (i.e. PoI data nearby to the route was provided as part of the navigation route guidance API), then we would potentially have problems with data ownership and freshness. Keeping the APIs separate means that each application which queries for points of interest gets up to date ones.

Andre: I see, but the only motivation for this POI data is its relation to the route, (and the knowledge the neighborhood).

Finally the is the route list, where Apps can decide to embed data for the driver. I have explained above that stuff more in detail. Again a different thing to the 2 above. The validity of this data is only during runtime. The system service does not store the data persistently.

I don’t think there are any recommendations for any of the software we’ve discussed (the navigation UI, guidance UI, or other applications) to persistently store points of interest which have come from the PoI API. I would expect any application (or part of the system chrome) which uses PoI data to re-query it at appropriate intervals, and certainly every time the application starts up.

Andre: navigation UI is in App responsibility, there we do not need recommendations for it.

Philip

Hi Philip,

let me focus in this email on the "route_list" vs "central POI service"

if I understood you right, than • the "central POI service" is a reference to the existing https://wiki.apertis.org/Points_of_interest There a no changes suggesting to that design, nor copying parts of it into a new design. That’s fine for me.

However, my understanding of https://wiki.apertis.org/Points_of_interest design is, that only the control flow runs via a central SDK service, but if allowed it establishes a private point-to-point channel (pipe) between producer App and consumer App (w/o any SDK service inbetween anymore). With that, the content itself (the POIs) are untouched form the so called "central POI service", the POIs are neither stored/cached, nor distributed by them. With that, the "SDK-Service" (central POI service) does _not_ return points of interest like restaurants, filling stations and tourist attractions. As also there is no capability to define filters in that request, since in an app-centric approach the policies are belonging to the Source/Producer App. The SDK service itself only establishes private point to point connections.

• Route list: a list of objects which describe the route for a navigation, i.e. the roads to take; this might include alternative routes; it _does_ include Point objects like intermediate destinations on the route

so there are point type objects already included in that structure as also attributes/metadata for each object for further details.

Please note, that the navigation "route-list" is something different than the navigation "guidance". The guidance focus on detailed description of turns ahead, the route-list has a different focus - it describes the complete trip. So that’s 2 APIs and different structures/objects. I would recommend to adopt the document accordingly.

And what I am talking about now is, that apps shall be able to augment the route list returned by the SDK-API . The route list exposed via the route-list SDK-API for sure gets provided (and updated) by the navigation app (somehow similar like it can do it for the geo-position to geo-clue), but Apps can augment data to it.

The APIs realizing this capability have second priority for me, but nevertheless I like to cover it right from the beginning from conceptual point of view.

With "create some functionality" I do mean the samples provided to explain use-cases where Apps consume and augment POIs to the route list: - a Weather App may consumes Intermediate Destination Information from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places - a gasoline station app adds a refueling stop into the route list for a location to be reached at a time where the car runs low on fuel - a restaurant app may uses information of gasoline stations in the route list to add recommended cafeterias into the route list to align the breaks for the driver - a restaurant app may decides to add restaurant POIs as recommendations into the route list for a location to be reached at a time where a break would be wise - a installed “coupon” app may add available discounts available at a POI location available in route list.

The major thing is, in an app centric approach, the policies are coupled with the source of the data. Its _not_ the navigation app which orchestrates the other apps - like in a systemic client-server model, what to deliver. This limits the capabilities to fantasy provided by the navigation app developer as also his capabilities and development work. In an app-centric approach its completely vice versa, each app focus on its essential service, a navigation calculates the route. That’s it. And a restaurant app deals the POI, and handles all policies and User Interaction to choose/handle them, even though they may finally gets used to set a new destination or they land in the route list.

So please take care, that https://wiki.apertis.org/Points_of_interest is following that principle.

I have enclosed some remaining comments in green

Rgds Andre

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Montag, 25. Januar 2016 15:56 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; devel@lists.apertis.org Betreff: Re: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document

Hi Andre,

On Fri, 2016-01-22 at 17:16 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

Hi Philip, I feel we are still not fully on the same page. We closed some gaps lately (in regard to the assist-window), but it seems to me that we still have a gap in regard to POI handling itself. So summarize, let me go one step back and start with

•   POI service is _not_ equal to route-list.
  

I am talking about a route list, you are talking about a central poi service.

To check, what do you mean by the terms ‘POI service’ and ‘route list’?

I interpret them as: • POI service: an SDK service which returns points of interest like restaurants, filling stations and tourist attractions • Route list: a list of points which describe the plotted route for a navigation, i.e. the roads to take; this might include alternative routes; it does not include nearby POIs

Andre: hope this is answered above

Let me add:

•   we do _not_ need a central POI service, or vice versa I am
  

not aware about a related requirement.

All suggestions I have made about POI handling in the context of the Geolocation and Navigation document have been references to the existing https://wiki.apertis.org/Points_of_interest design. I am not suggesting changes to that design, nor am I suggesting copying parts of it into this design (or any of the navigation APIs).

Andre: I see.

We do have the already mentioned 3 Use cases and the mechanisms discussed covers the use-cases already perfectly

1. for in app UI browsing: libchamlain. We have it, fine.

Yes.

2. for app import / handover: Pull mode for various types of content

– also TPEG based POI data - https://wiki.apertis.org/Points_of_interest (For completion there is also a push mode for various types of content – so far no need for TPEG support - https://wiki.apertis.org /Data_sharing ) again, we have it designed already.

Yes.

3. now we add the route-list to the SDK-API, where I also ask to

provide capabilities to add POIs to it (independent from the navi- app)

I think this is covered by the SDK navigation route guidance API (§7.6 of version 0.3.1 of the document), if we are using the same meaning for ‘route list’ (see above).

Andre: see above, I think we do need 2 API scopes, one for “route-list” one for “guidance”

In any case we do need the route list, it has originally nothing to do with the POI discussion. Apps shall be able to consume information about the current route and to create some functionality. That the purpose of the route list essentially.

What do you mean by ‘create some functionality’?

In the design as it stands currently, applications cannot augment the route list returned by the SDK navigation route guidance API. They can augment the list of POIs returned by the POI API (https://wiki.apertis. org/Points_of_interest).

Andre: see above, I do mean things like that - a Weather App may consumes Intermediate Destination Information from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places - a gasoline station app adds a refueling stop into the route list for a location to be reached at a time where the car runs low on fuel - a restaurant app may uses information of gasoline stations in the route list to add recommended cafeterias into the route list to align the breaks for the driver - a restaurant app may decides to add restaurant POIs as recommendations into the route list for a location to be reached at a time where a break would be wise - a installed “coupon” app may add available discounts available at a POI location available in route list.

Based on that scope, I am asking for the additional functionality to add Metadata/Content from Apps directly to it, especially POIs. Its neither a first priority nor will it dramatically change the design. Its simple an add-on. We can even decide to implement it later.

For clarity, which API do you mean by ‘it’?

Andre: I do mean the capability for Apps to augment POIs into the Route-List

Similar stuff is valid for the guidance & assist window discussion. The APIs for the “guidance” (which is “just another notification style API for a dedicated purpose”) as also the assist window (which is just another system chrome application where for example the data exposed via the guidance notification style SDK-API lands in) are optional and don’t have side effects to other SDK-APIs. So we can implementation wise realize it in a later step, its not of first priority. However, I like to have a common understanding about the overall scope early. If we provide capabilities to add metadata into an available route- list to Apps, other Apps (than the navi app) can add additional content/ additional metadata to available content, for example POIs into a currently shared route list. Since we have already libchamplain and also the Point_of_interest and sharing mechanisms design, My focus is on just one more method for that route-list. I am _not_ talking about any big thing, especially not about a central POI service. I would like to propose we serialize the discussion. How about first finalizing the solution for the route list, including POIs into it from Apps via an SDK API. Then reflect, for what a central POI service could be beneficial ? I have embedded some comments below in green.

I’ve put a few replies below too.

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Mittwoch, 20. Januar 2016 16:57 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; dev el@lists.apertis.org Betreff: Re: AW: AW: AW: [Devel] Updated geolocation and navigation design document

...

Please keep also in mind, that the navigation app itself is somehow special in regard to their output. Beside provides some UI to

control

...

its functions like all the other apps (e.g. media player), the

“route

...

guidance” information is very special. In addition to a black box build-in solution for the route guidance - like all the smartphone Smartphone solutions realizing today – (on prompt the guidance is only acoustic or an app-change transition to the navigation app appears) we will go a step forward for this driver related information. The guidance will be presented to the user independent of the current App in use in foreground. So you can “leave” the

navi-

...

app but the guidance shall continue. In fact we influence the internal design by requesting an agent to be provided by the app- developer to deliver these data. And that’s not only an acoustical prompt, its also data which gets finally a visual representation (turn icons, lane information, etc). In this approach via an SDK-

API

...

the rendering gets done by some system service. Its more like a “notification”/“dialog-box”/“status framework” stuff (please have a look to the running status framework and the relation to assist framework too). So the navigation App provides its data as output

to

...

some SDK-API. In fact part of this is the route list, which finally land in that guidance dialog. Lets call it assistance window –

driver

...

related information.

I see. The way I would recommend doing this in the design is to implement the guidance UI separately from the navigation UI. It could potentially be part of the same application bundle, or part of a different one, or even implemented as part of the system chrome. Andre: to be honest, this all is optional. A navi app developer can decide to implement the guidance in its local app-bundle scope. Then the UI appears within its own App Screen Area. However, since it is beneficial (independent from the POI or Assist Window Discussion) that the guidance portion is separated from the rest of the full-fledge App (because it enables us to handle a separated executable with its own lifecycle, which means we can keep only that part running in background instead of the Full App) we should ask for an Agent for it. The App developer can decide to do so or not. So the requirement for isolating the Guidance into an Agent is already valid w/o all the discussion about POIs and/or Assist Window. On top of that we like to also support an assist window solution as part of our system. Therefore we will provide a notification style similar API for driver related information. Guidance data will be covered by it, and if a Navi App developer decided to use this SDK- API, the guidance information will land there (but also information from route list will land in such an assist window). Similar like mentioned above, we like to ask the developer to provide an agent for the guidance data. However, the assist window (the UI for the guidance) is finally a system chrome element and not deployed with the App bundle. It belongs to the OS and gets distributed with it.

OK, we would have to add a separate SDK API for handling guidance notifications, similar to the existing org.freedesktop.Notifications API for handling other notifications from applications. I will include a recommendation for that in the next update to the document. Andre: agreed

The guidance UI would take data from the SDK points of interest API, and from the SDK navigation route guidance API (§7.6). This would allow it to render the route (from the guidance API), and points of interest along the way (from the PoI API). The navigation UI (where the driver chooses their destination and plans the route) may retrieve points of interest from the SDK, or may choose not to if the developer thinks they will be distracting. i.e. The SDK API you are suggesting for the data from the guidance UI is effectively the points of interest API plus the navigation route guidance API. Andre: like said, its not the “points_of_interest” API, its from the route-list API.

...

To this route list, other apps can directly add further data. This

is

...

_not_ forwarded to the navi-app, it does not modify the route list nor does it gets stored by the navi-app. The navi app don’t has any interest in getting and managing it. This data, gets provided by

the

...

source app to the rout–list and with that finally rendered to the user by some system service (assist window). On the other hand,

other

...

apps can consume this enriched route list again for their build-in functions and policies. Its all outside the navigation, the navi

only

...

provides the initial foundation.

That’s possible due to the split between the navigation UI and the guidance UI. The navigation UI can choose to not query for points of interest, or can heavily filter the PoI requests it makes. Conversely, the guidance UI can query for lots of PoIs. If other applications want to display something similar to the guidance UI, they must make the same navigation route guidance API and PoI API queries as made by the guidance UI. This should be simple to do, and allows each application to further customise the points of interest they display. Andre: to be honest, the use-cases behind that stuff is _not_ that another app will do something similar like the guidance UI.

Sorry, when I said “if other applications want to display something similar to the guidance UI” I meant something more like “if other applications want to display the current route, or the current route plus nearby POIs”.

Andre: I would expect this is build-in behind the scene into libchamplain. So by using libchamplain, Apps get this information already embedded. Similar like they get the current vehicle position (from geoclue) already well embedded into libchamplain. The usecases for Apps to use route list information is the stuff mentioned above. Let me repeat to prevent misunderstanding: - a Weather App may consumes Intermediate Destination Information from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places - a gasoline station app adds a refueling stop into the route list for a location to be reached at a time where the car runs low on fuel - a restaurant app may uses information of gasoline stations in the route list to add recommended cafeterias into the route list to align the breaks for the driver - a restaurant app may decides to add restaurant POIs as recommendations into the route list for a location to be reached at a time where a break would be wise - a installed “coupon” app may add available discounts available at a POI location available in route list.

Other Apps uses information form that API for their essential service, e.g. if an App of a weather service does know intermediate destinations from the route list, it may decides to show entries on top of the stored locations for current destination and intermediate destinations (in todays list you have the current positon for example as a default, this app could extend that approach depending on stuff from the route list). Or if a gasoline station app adds a refueling stop into the route list for a location to be reached at a time where the car runs low on fuel, a restaurant app may uses this information to add recommended cafeterias into the route list to align the breaks for the driver. Or if a restaurant app decides to add restaurant POIs as recommendations into the route list for a location to be reached at a time where a break would be wise, a installed “coupon” app may add available discounts available at this location. etc.

I don’t think I can fully understand these points without agreeing on the terminology at the top of the e-mail. Andre: ok, hope my comments given where helpful in that regard.

In the current version of the design, these use cases are handled by: • The gasoline station application exposes gasoline stations as points of interest via the POI API (https://wiki.apertis.org/Points_of_interes t). • The restaurant application exposes restaurants as points of interest via the POI API (https://wiki.apertis.org/Points_of_interest). • The navigation application contains the logic to: - Detect where in the route the vehicle is likely to need refuelling, query the POI API (https://wiki.apertis.org/Points_of_interest) for gasoline stations, and add them to the route. - Detect when in the route the driver is likely to need food, query the POI API (https://wiki.apertis.org/Points_of_interest) for restaurants, and add them to the route.

I can’t think of a sensible way of handling coupons at the moment. They don’t really fit into any of the existing APIs.

The design is this way round, rather than allowing the restaurant and gasoline applications to ‘insert’ recommendations into the route list because it leaves the navigation application in charge of which restaurants (for example) are shown. It means the code for determining when is ‘a good time to stop for food’ is in one place (the navigation application) rather than many (each restaurant application), each of which could end up using different definitions of when is ‘a good time to stop for food’ in order to gain competitive advantage.

Andre: like said above, the design philosophy is an app-centric solution is, to bundle the policy / logic within the provider app. So its not one central intelligence, orchestrating all others, its vice versa all the others are providing things accordant to their implemented logic. Apps can compete in providing the same service with another policy or using another service with a similar policy. The user decides by choosing the App which fits best his needs. And he can do in the smallest granularity, per App . So he is able to adopt the overall solution by making dedicated decisions per source (App).

(Above, I am using ‘navigation application’ to mean the entire navigation application bundle, including any UIs, agents, or services which it provides.)

Philip

Hi Philip,

Thanks for your answer, but we are still not on the same page. We talking about different things. There are other parts beside feature requirements which influence the decomposition. Its seems for me that you are focusing on features and if the design/decomposition proposed is able to realize it. My focus is alignment with app-centric design, so responsibilities & dependencies (I only use features to make things more clear). So if you are saying the design can provide the feature, then that’s not what I am talking about. I am talking about the design does not fit to the non-function requirements (app-centric solution). Parts of the functionality belongs to the wrong responsibility or we even do need to split an entity into parts to deploy the responsibility to different parties.

Since we are iterating in cycles a little bit and I start to gets doubts about the efficiency of this kind of mail threads, let us limit the iterations. If within a few next ones we do not conclude, then lets have a call about it. But for now let me try to explain my intention again via email:

So yes, one can technically pass everything through the navigation App, delivering all POIs to the App as also requesting a consolidated data from it. That’s possible. And the design is done in that way. And that’s not the way how it shall be. So its not the question if the current design can also realize the mentioned features.

The POI mechanism defined already was motivation by the update of the navi-database with data needed for route calculation. Only for that purpose. So for now, please forget the POI mechanism defined already.

Now we are talking about the “route list”. Maybe the naming is not beneficial, internally we typically use the term “horizon”. Its dedicated scope is to carry information related to the (expected) vehicle position, starting from the current location up to expected future positons. This is where the term route-list comes into the game. The goal now is to provide a framework, where all apps can consume data from for their internal processing as also provide data to this framework (to enrich it). This all is also valid w/o any route available. In that case the data focus more around the current vehicle position. It is even valid, if there is no navigation app installed at all. There is nevertheless the current geo position available (e.g. from geoclue, and maybe even only on WLAN based positioning so without any GPS solution, that doesn’t matter). The navigation App is just another App, optionally producing data to that framework and/or consuming data from it (e.g. the information about the current route, including its intermediate destinations etc). And it could even be that multiple Apps, dealing with most probable pathes exposes information to this horizon (not only the Navi App currently maintaining the active route). The framework is completely independent of the developer of a particular Navigation App, this solutions is completely out of the scope/responsibility of the navigation provider. It belongs to the system, the OS.

And yes, intermediate destinations are provided and handled by a navigation app, again via another mechanism (the scheme mechanisms, not the POI one). And if a new intermediate destination has been defined via this way, and the route has been updated, then the navi app can expose it to the said horizon framework. And another App can consume this new information about an intermediate destination for their scope and may also add new data to this framework accordingly.

So what I am asking for is, to keep the POI mechanism as a way of choice for database updates, and to add an additional framework – which we can call “horizon” or something else - where Apps can produce data to as also consume data from it. The Navi App shall be able to provide its route list information to it and update it.

Rgds Andre

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Dienstag, 2. Februar 2016 18:27 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; devel@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document

Hi Andre,

Replies inline. I’ve trimmed a few of the parts of the e-mail which we agree on.

On Tue, 2016-01-26 at 13:03 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

However, my understanding of https://wiki.apertis.org/Points_of_interest design is, that only the control flow runs via a central SDK service, but if allowed it establishes a private point-to-point channel (pipe) between producer App and consumer App (w/o any SDK service inbetween anymore). With that, the content itself (the POIs) are untouched form the so called "central POI service", the POIs are neither stored/cached, nor distributed by them. With that, the "SDK-Service" (central POI service) does _not_ return points of interest like restaurants, filling stations and tourist attractions. As also there is no capability to define filters in that request, since in an app-centric approach the policies are belonging to the Source/Producer App. The SDK service itself only establishes private point to point connections.

That is correct. I guess when I’ve been saying ‘POI service’ or ‘POI system’ from the point of view of an application which is consuming POI data (such as the navigation UI, or another application which needs to display POIs), I would consider the ‘POI service/system’ to be the set of all applications which are providing POIs over peer-to-peer connections.

• Route list: a list of objects which describe the route for a navigation, i.e. the roads to take; this might include alternative routes; it _does_ include Point objects like intermediate destinations on the route so there are point type objects already included in that structure as also attributes/metadata for each object for further details.

Yes, although the metadata is limited to a description for the location and what type of point it is (start, waypoint, waypoint which is for routing only and isn’t a destination, final destination).

Please note, that the navigation "route-list" is something different than the navigation "guidance". The guidance focus on detailed description of turns ahead, the route-list has a different focus - it describes the complete trip. So that’s 2 APIs and different structures/objects. I would recommend to adopt the document accordingly.

Noted — I will include this in the next update to the document.

And what I am talking about now is, that apps shall be able to augment the route list returned by the SDK-API . The route list exposed via the route-list SDK-API for sure gets provided (and updated) by the navigation app (somehow similar like it can do it for the geo-position to geo-clue), but Apps can augment data to it. The APIs realizing this capability have second priority for me, but nevertheless I like to cover it right from the beginning from conceptual point of view. With "create some functionality" I do mean the samples provided to explain use-cases where Apps consume and augment POIs to the route list:

• a Weather App may consumes Intermediate Destination Information

from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places

• a gasoline station app adds a refueling stop into the route list

for a location to be reached at a time where the car runs low on fuel

• a restaurant app may uses information of gasoline stations in the

route list to add recommended cafeterias into the route list to align the breaks for the driver

• a restaurant app may decides to add restaurant POIs as

recommendations into the route list for a location to be reached at a time where a break would be wise

• a installed “coupon” app may add available discounts available at a

POI location available in route list. The major thing is, in an app centric approach, the policies are coupled with the source of the data. Its _not_ the navigation app which orchestrates the other apps - like in a systemic client-server model, what to deliver. This limits the capabilities to fantasy provided by the navigation app developer as also his capabilities and development work. In an app-centric approach its completely vice versa, each app focus on its essential service, a navigation calculates the route. That’s it. And a restaurant app deals the POI, and handles all policies and User Interaction to choose/handle them, even though they may finally gets used to set a new destination or they land in the route list.

OK. I think this fits with my proposed design and the Points of Interest design as they currently stand, although I should clarify things.

The route list API continues to provide only the list of roads to take (i.e. the geometry of the route) as I described in my previous e-mail.

Applications which provide POIs query this API to find out the current route, as described in the fourth paragraph of https://wiki.apertis.org/Points_of_interest#Recommendations.

The navigation UI uses interface discovery to find applications which provide POI data. It then queries them (via peer-to-peer connections) for general and specific POIs, as described in the POI design.

Its shall not be the responsibility of the Navigation to requests it/or not. Its done by the Providing Apps autonomously. It shall not depend on the code (responsibility) of the navigation App at all if this

The logic for working out what POIs to send to the navigation UI lies within each application. The navigation UI does no filtering based on content (though for security reasons it might want to apply some rate limiting to prevent DoS attacks). It simply displays all the POIs it receives.

It might be possible for an application to add metadata to a POI it sends to the navigation UI to say ‘please add this POI as a waypoint’, in which case the navigation UI could prompt the user about it (or add the destination anyway, or ignore it — this policy is up to the navigation UI developer). If the POI is added as a waypoint in the route, the SDK route list API would signal an update to the route, which would be received by the navigation UI and all applications providing POIs to it. This would allow for the coupon use case — if a restaurant gets added as a waypoint, the coupon application could start emitting a POI for using coupons there.

If another application wants to display the same map view as the navigation UI, showing the route and POIs on it, it has to make the same API calls as the navigation UI: a call to the SDK route list API to get the route; and interface discovery followed by peer-to-peer retrieval of POIs from other applications.

So, in short, the ‘augmented route list’ is provided by a combination of the route list API and the POI system (i.e. retrieving POIs from other applications using peer-to-peer connections).

I hope that makes sense?

Philip

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Montag, 25. Januar 2016 15:56 An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com mailto:Andre.Barkowski@de.bosch.com >; dev el@lists.apertis.org mailto:el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document Hi Andre, On Fri, 2016-01-22 at 17:16 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

...

Hi Philip, I feel we are still not fully on the same page. We closed some gaps lately (in regard to the assist-window), but it seems to me that we still have a gap in regard to POI handling itself. So summarize, let me go one step back and start with

•   POI service is _not_ equal to route-list.
  

I am talking about a route list, you are talking about a central

poi

...

service.

To check, what do you mean by the terms ‘POI service’ and ‘route list’? I interpret them as: • POI service: an SDK service which returns points of interest like restaurants, filling stations and tourist attractions • Route list: a list of points which describe the plotted route for a navigation, i.e. the roads to take; this might include alternative routes; it does not include nearby POIs Andre: hope this is answered above

...

Let me add:

•   we do _not_ need a central POI service, or vice versa I am
  

not aware about a related requirement.

All suggestions I have made about POI handling in the context of the Geolocation and Navigation document have been references to the existing https://wiki.apertis.org/Points_of_interest design. I am not suggesting changes to that design, nor am I suggesting copying parts of it into this design (or any of the navigation APIs). Andre: I see.

...

We do have the already mentioned 3 Use cases and the mechanisms discussed covers the use-cases already perfectly

1. for in app UI browsing: libchamlain. We have it, fine.

Yes.

...

2. for app import / handover: Pull mode for various types of

content

...

– also TPEG based POI data - https://wiki.apertis.org/Points_of_interest (For completion there is also a push mode for various types of content – so far no need for TPEG support - https://wiki.apertis.o

rg

...

/Data_sharing ) again, we have it designed already.

Yes.

...

3. now we add the route-list to the SDK-API, where I also ask to

provide capabilities to add POIs to it (independent from the navi- app)

I think this is covered by the SDK navigation route guidance API (§7.6 of version 0.3.1 of the document), if we are using the same meaning for ‘route list’ (see above). Andre: see above, I think we do need 2 API scopes, one for “route- list” one for “guidance”

...

In any case we do need the route list, it has originally nothing to do with the POI discussion. Apps shall be able to consume

information

...

about the current route and to create some functionality. That the purpose of the route list essentially.

What do you mean by ‘create some functionality’? In the design as it stands currently, applications cannot augment the route list returned by the SDK navigation route guidance API. They can augment the list of POIs returned by the POI API (https://wiki.aperti s. org/Points_of_interest). Andre: see above, I do mean things like that

• a Weather App may consumes Intermediate Destination Information

from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places

• a gasoline station app adds a refueling stop into the route list

for a location to be reached at a time where the car runs low on fuel

• a restaurant app may uses information of gasoline stations in the

route list to add recommended cafeterias into the route list to align the breaks for the driver

• a restaurant app may decides to add restaurant POIs as

recommendations into the route list for a location to be reached at a time where a break would be wise

• a installed “coupon” app may add available discounts available at a

POI location available in route list.

...

Based on that scope, I am asking for the additional functionality

to

...

add Metadata/Content from Apps directly to it, especially POIs. Its neither a first priority nor will it dramatically change the

design.

...

Its simple an add-on. We can even decide to implement it later.

For clarity, which API do you mean by ‘it’? Andre: I do mean the capability for Apps to augment POIs into the Route-List

...

Similar stuff is valid for the guidance & assist window discussion. The APIs for the “guidance” (which is “just another notification style API for a dedicated purpose”) as also the assist window

(which

...

is just another system chrome application where for example the

data

...

exposed via the guidance notification style SDK-API lands in) are optional and don’t have side effects to other SDK-APIs. So we can implementation wise realize it in a later step, its not of first priority. However, I like to have a common understanding about the overall scope early. If we provide capabilities to add metadata into an available route- list to Apps, other Apps (than the navi app) can add additional content/ additional metadata to available content, for example POIs into a currently shared route list. Since we have already libchamplain and also the Point_of_interest and sharing mechanisms design, My focus is on just one more method for that route-list. I

am

...

_not_ talking about any big thing, especially not about a central

POI

...

service. I would like to propose we serialize the discussion. How about

first

...

finalizing the solution for the route list, including POIs into it from Apps via an SDK API. Then reflect, for what a central POI service could be beneficial ? I have embedded some comments below in green.

I’ve put a few replies below too.

...

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Mittwoch, 20. Januar 2016 16:57 An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com mailto:Andre.Barkowski@de.bosch.com >;

dev

...

el@lists.apertis.org mailto:el@lists.apertis.org Betreff: Re: AW: AW: AW: [Devel] Updated geolocation and navigation design document

...

Please keep also in mind, that the navigation app itself is

somehow

...

...

special in regard to their output. Beside provides some UI to

control

...

its functions like all the other apps (e.g. media player), the

“route

...

guidance” information is very special. In addition to a black box build-in solution for the route guidance - like all the

smartphone

...

...

Smartphone solutions realizing today – (on prompt the guidance is only acoustic or an app-change transition to the navigation app appears) we will go a step forward for this driver related information. The guidance will be presented to the user

independent

...

...

of the current App in use in foreground. So you can “leave” the

navi-

...

app but the guidance shall continue. In fact we influence the internal design by requesting an agent to be provided by the app- developer to deliver these data. And that’s not only an

acoustical

...

...

prompt, its also data which gets finally a visual representation (turn icons, lane information, etc). In this approach via an SDK-

API

...

the rendering gets done by some system service. Its more like a “notification”/“dialog-box”/“status framework” stuff (please have

a

...

...

look to the running status framework and the relation to assist framework too). So the navigation App provides its data as output

to

...

some SDK-API. In fact part of this is the route list, which

finally

...

...

land in that guidance dialog. Lets call it assistance window –

driver

...

related information.

I see. The way I would recommend doing this in the design is to implement the guidance UI separately from the navigation UI. It

could

...

potentially be part of the same application bundle, or part of a different one, or even implemented as part of the system chrome. Andre: to be honest, this all is optional. A navi app developer can decide to implement the guidance in its local app-bundle scope.

Then

...

the UI appears within its own App Screen Area. However, since it is beneficial (independent from the POI or Assist Window Discussion) that the guidance portion is separated from the rest of the full-fledge App (because it enables us to handle a separated executable with its own lifecycle, which means we can

keep

...

only that part running in background instead of the Full App) we should ask for an Agent for it. The App developer can decide to do

so

...

or not. So the requirement for isolating the Guidance into an Agent is already valid w/o all the discussion about POIs and/or Assist Window. On top of that we like to also support an assist window solution as part of our system. Therefore we will provide a notification style similar API for driver related information. Guidance data will be covered by it, and if a Navi App developer decided to use this SDK- API, the guidance information will land there (but also information from route list will land in such an assist window). Similar like mentioned above, we like to ask the developer to provide an agent

for

...

the guidance data. However, the assist window (the UI for the guidance) is finally a system chrome element and not deployed with the App bundle. It belongs to the OS and gets distributed with it.

OK, we would have to add a separate SDK API for handling guidance notifications, similar to the existing org.freedesktop.Notifications API for handling other notifications from applications. I will include a recommendation for that in the next update to the document. Andre: agreed

...

The guidance UI would take data from the SDK points of interest

API,

...

and from the SDK navigation route guidance API (§7.6). This would allow it to render the route (from the guidance API), and points of interest along the way (from the PoI API). The navigation UI (where the driver chooses their destination and plans the route) may retrieve points of interest from the SDK, or may choose not to if the developer thinks they will be distracting. i.e. The SDK API you are suggesting for the data from the guidance

UI

...

is effectively the points of interest API plus the navigation route guidance API. Andre: like said, its not the “points_of_interest” API, its from

the

...

route-list API.

...

To this route list, other apps can directly add further data.

This

...

is

...

_not_ forwarded to the navi-app, it does not modify the route

list

...

...

nor does it gets stored by the navi-app. The navi app don’t has

any

...

...

interest in getting and managing it. This data, gets provided by

the

...

source app to the rout–list and with that finally rendered to the user by some system service (assist window). On the other hand,

other

...

apps can consume this enriched route list again for their build-

in

...

...

functions and policies. Its all outside the navigation, the navi

only

...

provides the initial foundation.

That’s possible due to the split between the navigation UI and the guidance UI. The navigation UI can choose to not query for points

of

...

interest, or can heavily filter the PoI requests it makes. Conversely, the guidance UI can query for lots of PoIs. If other applications want to display something similar to the guidance UI, they must make the same navigation route guidance API and PoI

API

...

queries as made by the guidance UI. This should be simple to do,

and

...

allows each application to further customise the points of interest they display. Andre: to be honest, the use-cases behind that stuff is _not_ that another app will do something similar like the guidance UI.

Sorry, when I said “if other applications want to display something similar to the guidance UI” I meant something more like “if other applications want to display the current route, or the current route plus nearby POIs”. Andre: I would expect this is build-in behind the scene into libchamplain. So by using libchamplain, Apps get this information already embedded. Similar like they get the current vehicle position (from geoclue) already well embedded into libchamplain. The usecases for Apps to use route list information is the stuff mentioned above. Let me repeat to prevent misunderstanding:

• a Weather App may consumes Intermediate Destination Information

from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places

• a gasoline station app adds a refueling stop into the route list

for a location to be reached at a time where the car runs low on fuel

• a restaurant app may uses information of gasoline stations in the

route list to add recommended cafeterias into the route list to align the breaks for the driver

• a restaurant app may decides to add restaurant POIs as

recommendations into the route list for a location to be reached at a time where a break would be wise

• a installed “coupon” app may add available discounts available at a

POI location available in route list.

...

Other Apps uses information form that API for their essential service, e.g. if an App of a weather service does know intermediate destinations from the route list, it may decides to show entries on top of the stored locations for current destination and

intermediate

...

destinations (in todays list you have the current positon for

example

...

as a default, this app could extend that approach depending on

stuff

...

from the route list). Or if a gasoline station app adds a refueling stop into the route list for a location to be reached at a time where the car runs low

on

...

fuel, a restaurant app may uses this information to add recommended cafeterias into the route list to align the breaks for the driver. Or if a restaurant app decides to add restaurant POIs as recommendations into the route list for a location to be reached at

a

...

time where a break would be wise, a installed “coupon” app may add available discounts available at this location. etc.

I don’t think I can fully understand these points without agreeing on the terminology at the top of the e-mail. Andre: ok, hope my comments given where helpful in that regard. In the current version of the design, these use cases are handled by: • The gasoline station application exposes gasoline stations as points of interest via the POI API (https://wiki.apertis.org/Points_of_inter es t). • The restaurant application exposes restaurants as points of interest via the POI API (https://wiki.apertis.org/Points_of_interest). • The navigation application contains the logic to:

• Detect where in the route the vehicle is likely to need

refuelling, query the POI API (https://wiki.apertis.org/Points_of_interest) for gasoline stations, and add them to the route.

• Detect when in the route the driver is likely to need food, query

the POI API (https://wiki.apertis.org/Points_of_interest) for restaurants, and add them to the route. I can’t think of a sensible way of handling coupons at the moment. They don’t really fit into any of the existing APIs. The design is this way round, rather than allowing the restaurant and gasoline applications to ‘insert’ recommendations into the route list because it leaves the navigation application in charge of which restaurants (for example) are shown. It means the code for determining when is ‘a good time to stop for food’ is in one place (the navigation application) rather than many (each restaurant application), each of which could end up using different definitions of when is ‘a good time to stop for food’ in order to gain competitive advantage. Andre: like said above, the design philosophy is an app-centric solution is, to bundle the policy / logic within the provider app. So its not one central intelligence, orchestrating all others, its vice versa all the others are providing things accordant to their implemented logic. Apps can compete in providing the same service with another policy or using another service with a similar policy. The user decides by choosing the App which fits best his needs. And he can do in the smallest granularity, per App . So he is able to adopt the overall solution by making dedicated decisions per source (App). (Above, I am using ‘navigation application’ to mean the entire navigation application bundle, including any UIs, agents, or services which it provides.) Philip

Hi Philip,

since I still do not know where the blocking factor is let me give some range of feedback, maybe one hits the point - Apps do not change the system scope, they do not install stuff (e.g. backends) into the system. They may ship a backend, but all that belongs and gets installed to its black box environment. However, they may exposes data to some already available system service via some SDK-API. - App UI (like "Fuel Station application UI" or "Navigation UI") belongs the "application bundle" - So the Navi is completely handled as a App-Bundle covering the "Backend" (including route planning) as also the "UI" in its own black box. - since the "navigation UI" belongs the nav app-bundle, it is directly connected to its backend The Navi UI can use whatever black-box internal ways to interact with its backend to create its UI. Same like for each other App-Bundle. The Navi is just another App. However, in addition its proprietary backend may exposes some data to a SDK-API service (route-list "horizon"), and the backend may also consumes aggregated data form (this) SDK-API service.

- its not like discussed for libchamplain or tts or other topics, where the "backends" reside in the OS scope (functionality embedded in the OS). In these areas the backend of choice gest decided by the system integrator at point in time of product definition (it cannot be changed by the User). In contrast to that, for navi we enable flexibility during runtime. Installing an app changes the "backend used". So the Navi App Bundle ships the backend and its UI, but does not change installations in the OS. The App bundle exposes data to the SDK.Route List (Horizon) APIs to other Apps. So we shift the responsibility by keeping the app-centric approach - from the integrator to the user and from OS-scope to App-scope. - With that flexibility, the User has the option to decides for the Navi of his choice. - if the backend is located in automotive domain, then this is coupled/bundled with one (maybe build in) "Navi App".

- The rout-list "horizon" API, is not primary used to create a User-Interface for a "Navigation" Application, neither from other Apps nor from the App bundle who provides the "backend". The primary purpose for the route-list API "horizon" is _not_ to serve for the navigation build-in functionality. Its for location based services/Apps.

- POIs transferred via the pipe mechanism lands in the App specific local "database" (not directly at the UI), the App takes over the data responsibility/management, its like an import. The App decides about if and how to persistently store it, when to delete etc. These data runs like all the other local app data though its app-specific business logic / functionality. Its even possible that these data gets only consumed by some algorithms and never lands natively at the UI.

- think about a setup w/o any navigation installed. Then there is no navi backend installed. Nevertheless, the is a route-list "horizon" API where Apps can consume data from and expose data to (accordant to their app internal functional scope). - It could even be the case that some Apps who are not being a "navigation App" provide some most probable path information to the horizon. Its not a route -since no destination is set and even no navigation installed), but guessing about the way ahead. It could be limited in length (e.g. only until next intersection, or a little ahead of this with even multiple pathes from each intersection, etc). And this can also be added in case a route is given, adding more information about alternative links at intersection could be benefitail for some other Apps to know. So finally its not only POI.

so some questions: - which "component" represents the glue (the framework) between the LBS-Apps (like Navi, Restaurants, Sightseeing, etc), to receive dedicated data from individual producers (LBS Apps), creates and maintains a combined data set, and deliver the data exposed as route-list "horizon" API to consumers (its not the "backend" located in the App Bundle if a a Navi App, this backend is itself a producer only) ? (Btw, a Navi Backend from a proprietary Supplier may do not has at all any of the capabilities needed to aggregate POI data from various sources into a combined set. ) - in which format/way gets this data forwarded to this component ? It does not need to be the pipe based POI mechanism only because we have it. Geoclue also deals with coordinates and nevertheless uses another kind of API to exchange information with its backends. On top its not only POIs, ist also links(streets) etc to be provided to the "horizon" framework.

Rgds Andre

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Mittwoch, 3. Februar 2016 16:18 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; devel@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document

Hi Andre,

As far as I can tell, the design I suggested in my previous e-mail does match your requirements for which components have responsibility for different decisions or pieces of information: • Applications choose which POIs to advertise, and the navigation UI displays them unconditionally (subject to rate limiting) • The route list API is provided by the SDK, in the system, and supports multiple backends — the backend might be provided by the navigation application bundle, but might instead be in the automotive domain, or something else • The navigation UI is just another application, and has no special powers or functionality • Applications choose which waypoints to send to the route list API to be added into the route — this might result in the user being prompted ‘do you want to add this waypoint into your route’, or they might be added unconditionally

I have attached a diagram of the system as I described it in my previous e-mail, and have attempted to highlight all the data flows and the decisions which drive them. (Apologies for the crudeness of the drawing; I did it rapidly.)

Please could you take a look and see where our understandings differ, and highlight specifically what the differences are.

Thanks, Philip

On Wed, 2016-02-03 at 14:16 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

Hi Philip, Thanks for your answer, but we are still not on the same page. We talking about different things. There are other parts beside feature requirements which influence the decomposition. Its seems for me that you are focusing on features and if the design/decomposition proposed is able to realize it. My focus is alignment with app-centric design, so responsibilities & dependencies (I only use features to make things more clear). So if you are saying the design can provide the feature, then that’s not what I am talking about. I am talking about the design does not fit to the non-function requirements (app-centric solution). Parts of the functionality belongs to the wrong responsibility or we even do need to split an entity into parts to deploy the responsibility to different parties. Since we are iterating in cycles a little bit and I start to gets doubts about the efficiency of this kind of mail threads, let us limit the iterations. If within a few next ones we do not conclude, then lets have a call about it. But for now let me try to explain my intention again via email: So yes, one can technically pass everything through the navigation App, delivering all POIs to the App as also requesting a consolidated data from it. That’s possible. And the design is done in that way. And that’s not the way how it shall be. So its not the question if the current design can also realize the mentioned features. The POI mechanism defined already was motivation by the update of the navi-database with data needed for route calculation. Only for that purpose. So for now, please forget the POI mechanism defined already. Now we are talking about the “route list”. Maybe the naming is not beneficial, internally we typically use the term “horizon”. Its dedicated scope is to carry information related to the (expected) vehicle position, starting from the current location up to expected future positons. This is where the term route-list comes into the game. The goal now is to provide a framework, where all apps can consume data from for their internal processing as also provide data to this framework (to enrich it). This all is also valid w/o any route available. In that case the data focus more around the current vehicle position. It is even valid, if there is no navigation app installed at all. There is nevertheless the current geo position available (e.g. from geoclue, and maybe even only on WLAN based positioning so without any GPS solution, that doesn’t matter). The navigation App is just another App, optionally producing data to that framework and/or consuming data from it (e.g. the information about the current route, including its intermediate destinations etc). And it could even be that multiple Apps, dealing with most probable pathes exposes information to this horizon (not only the Navi App currently maintaining the active route). The framework is completely independent of the developer of a particular Navigation App, this solutions is completely out of the scope/responsibility of the navigation provider. It belongs to the system, the OS. And yes, intermediate destinations are provided and handled by a navigation app, again via another mechanism (the scheme mechanisms, not the POI one). And if a new intermediate destination has been defined via this way, and the route has been updated, then the navi app can expose it to the said horizon framework. And another App can consume this new information about an intermediate destination for their scope and may also add new data to this framework accordingly. So what I am asking for is, to keep the POI mechanism as a way of choice for database updates, and to add an additional framework – which we can call “horizon” or something else - where Apps can produce data to as also consume data from it. The Navi App shall be able to provide its route list information to it and update it. Rgds Andre -----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Dienstag, 2. Februar 2016 18:27 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; dev el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document Hi Andre, Replies inline. I’ve trimmed a few of the parts of the e-mail which we agree on. On Tue, 2016-01-26 at 13:03 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

...

However, my understanding of https://wiki.apertis.org/Points_of_interest design is, that only

the

...

control flow runs via a central SDK service, but if allowed it establishes a private point-to-point channel (pipe) between

producer

...

App and consumer App (w/o any SDK service inbetween anymore). With that, the content itself (the POIs) are untouched form the so

called

...

"central POI service", the POIs are neither stored/cached, nor distributed by them. With that, the "SDK-Service" (central POI service) does _not_ return points of interest like restaurants, filling stations and tourist attractions. As also there is no capability to define filters in that request, since in an app-

centric

...

approach the policies are belonging to the Source/Producer App. The SDK service itself only establishes private point to point connections.

That is correct. I guess when I’ve been saying ‘POI service’ or ‘POI system’ from the point of view of an application which is consuming POI data (such as the navigation UI, or another application which needs to display POIs), I would consider the ‘POI service/system’ to be the set of all applications which are providing POIs over peer-to-peer connections.

...

• Route list: a list of objects which describe the route for a navigation, i.e. the roads to take; this might include alternative routes; it _does_ include Point objects like intermediate destinations on the route so there are point type objects already included in that structure

as

...

also attributes/metadata for each object for further details.

Yes, although the metadata is limited to a description for the location and what type of point it is (start, waypoint, waypoint which is for routing only and isn’t a destination, final destination).

...

Please note, that the navigation "route-list" is something

different

...

than the navigation "guidance". The guidance focus on detailed description of turns ahead, the route-list has a different focus -

it

...

describes the complete trip. So that’s 2 APIs and different structures/objects. I would recommend to adopt the document accordingly.

Noted — I will include this in the next update to the document.

...

And what I am talking about now is, that apps shall be able to augment the route list returned by the SDK-API . The route list exposed via the route-list SDK-API for sure gets provided (and updated) by the navigation app (somehow similar like it can do it

for

...

the geo-position to geo-clue), but Apps can augment data to it. The APIs realizing this capability have second priority for me, but nevertheless I like to cover it right from the beginning from conceptual point of view. With "create some functionality" I do mean the samples provided to explain use-cases where Apps consume and augment POIs to the route list:

• a Weather App may consumes Intermediate Destination Information

from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places

• a gasoline station app adds a refueling stop into the route list

for a location to be reached at a time where the car runs low on

fuel

...

• a restaurant app may uses information of gasoline stations in the

route list to add recommended cafeterias into the route list to

align

...

the breaks for the driver

• a restaurant app may decides to add restaurant POIs as

recommendations into the route list for a location to be reached at

a

...

time where a break would be wise

• a installed “coupon” app may add available discounts available at

a

...

POI location available in route list. The major thing is, in an app centric approach, the policies are coupled with the source of the data. Its _not_ the navigation app which orchestrates the other apps - like in a systemic client-

server

...

model, what to deliver. This limits the capabilities to fantasy provided by the navigation app developer as also his capabilities

and

...

development work. In an app-centric approach its completely vice versa, each app focus on its essential service, a navigation calculates the route. That’s it. And a restaurant app deals the

POI,

...

and handles all policies and User Interaction to choose/handle

them,

...

even though they may finally gets used to set a new destination or they land in the route list.

OK. I think this fits with my proposed design and the Points of Interest design as they currently stand, although I should clarify things. The route list API continues to provide only the list of roads to take (i.e. the geometry of the route) as I described in my previous e- mail. Applications which provide POIs query this API to find out the current route, as described in the fourth paragraph of https://wiki.apertis.org/Points_of_interest#Recommendations. The navigation UI uses interface discovery to find applications which provide POI data. It then queries them (via peer-to-peer connections) for general and specific POIs, as described in the POI design. Its shall not be the responsibility of the Navigation to requests it/or not. Its done by the Providing Apps autonomously. It shall not depend on the code (responsibility) of the navigation App at all if this The logic for working out what POIs to send to the navigation UI lies within each application. The navigation UI does no filtering based on content (though for security reasons it might want to apply some rate limiting to prevent DoS attacks). It simply displays all the POIs it receives. It might be possible for an application to add metadata to a POI it sends to the navigation UI to say ‘please add this POI as a waypoint’, in which case the navigation UI could prompt the user about it (or add the destination anyway, or ignore it — this policy is up to the navigation UI developer). If the POI is added as a waypoint in the route, the SDK route list API would signal an update to the route, which would be received by the navigation UI and all applications providing POIs to it. This would allow for the coupon use case — if a restaurant gets added as a waypoint, the coupon application could start emitting a POI for using coupons there. If another application wants to display the same map view as the navigation UI, showing the route and POIs on it, it has to make the same API calls as the navigation UI: a call to the SDK route list API to get the route; and interface discovery followed by peer-to-peer retrieval of POIs from other applications. So, in short, the ‘augmented route list’ is provided by a combination of the route list API and the POI system (i.e. retrieving POIs from other applications using peer-to-peer connections). I hope that makes sense? Philip

...

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Montag, 25. Januar 2016 15:56 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com;

dev

...

el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document Hi Andre, On Fri, 2016-01-22 at 17:16 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

...

Hi Philip, I feel we are still not fully on the same page. We closed some

gaps

...

...

lately (in regard to the assist-window), but it seems to me that

we

...

...

still have a gap in regard to POI handling itself. So summarize, let me go one step back and start with

•   POI service is _not_ equal to route-list.
  

I am talking about a route list, you are talking about a central

poi

...

service.

To check, what do you mean by the terms ‘POI service’ and ‘route list’? I interpret them as: • POI service: an SDK service which returns points of interest

like

...

restaurants, filling stations and tourist attractions • Route list: a list of points which describe the plotted route

for

...

a navigation, i.e. the roads to take; this might include alternative routes; it does not include nearby POIs Andre: hope this is answered above

...

Let me add:

•   we do _not_ need a central POI service, or vice versa I
  

am

...

...

not aware about a related requirement.

All suggestions I have made about POI handling in the context of

the

...

Geolocation and Navigation document have been references to the existing https://wiki.apertis.org/Points_of_interest design. I am

not

...

suggesting changes to that design, nor am I suggesting copying

parts

...

of it into this design (or any of the navigation APIs). Andre: I see.

...

We do have the already mentioned 3 Use cases and the mechanisms discussed covers the use-cases already perfectly

1. for in app UI browsing: libchamlain. We have it, fine.

Yes.

...

2. for app import / handover: Pull mode for various types of

content

...

– also TPEG based POI data - https://wiki.apertis.org/Points_of_interest (For completion there is also a push mode for various types of content – so far no need for TPEG support - https://wiki.apertis

.o

...

rg

...

/Data_sharing ) again, we have it designed already.

Yes.

...

3. now we add the route-list to the SDK-API, where I also ask to

provide capabilities to add POIs to it (independent from the

navi-

...

...

app)

I think this is covered by the SDK navigation route guidance API (§7.6 of version 0.3.1 of the document), if we are using the same meaning for ‘route list’ (see above). Andre: see above, I think we do need 2 API scopes, one for “route- list” one for “guidance”

...

In any case we do need the route list, it has originally nothing

to

...

...

do with the POI discussion. Apps shall be able to consume

information

...

about the current route and to create some functionality. That

the

...

...

purpose of the route list essentially.

What do you mean by ‘create some functionality’? In the design as it stands currently, applications cannot augment

the

...

route list returned by the SDK navigation route guidance API. They can augment the list of POIs returned by the POI API (https://wiki.aper

ti

...

s. org/Points_of_interest). Andre: see above, I do mean things like that

• a Weather App may consumes Intermediate Destination Information

from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places

• a gasoline station app adds a refueling stop into the route list

for a location to be reached at a time where the car runs low on

fuel

...

• a restaurant app may uses information of gasoline stations in the

route list to add recommended cafeterias into the route list to

align

...

the breaks for the driver

• a restaurant app may decides to add restaurant POIs as

recommendations into the route list for a location to be reached at

a

...

time where a break would be wise

• a installed “coupon” app may add available discounts available at

a

...

POI location available in route list.

...

Based on that scope, I am asking for the additional functionality

to

...

add Metadata/Content from Apps directly to it, especially POIs.

Its

...

...

neither a first priority nor will it dramatically change the

design.

...

Its simple an add-on. We can even decide to implement it later.

For clarity, which API do you mean by ‘it’? Andre: I do mean the capability for Apps to augment POIs into the Route-List

...

Similar stuff is valid for the guidance & assist window

discussion.

...

...

The APIs for the “guidance” (which is “just another notification style API for a dedicated purpose”) as also the assist window

(which

...

is just another system chrome application where for example the

data

...

exposed via the guidance notification style SDK-API lands in) are optional and don’t have side effects to other SDK-APIs. So we can implementation wise realize it in a later step, its not of first priority. However, I like to have a common understanding about

the

...

...

overall scope early. If we provide capabilities to add metadata into an available

route-

...

...

list to Apps, other Apps (than the navi app) can add additional content/ additional metadata to available content, for example

POIs

...

...

into a currently shared route list. Since we have already libchamplain and also the Point_of_interest and sharing

mechanisms

...

...

design, My focus is on just one more method for that route-list.

I

...

am

...

_not_ talking about any big thing, especially not about a central

POI

...

service. I would like to propose we serialize the discussion. How about

first

...

finalizing the solution for the route list, including POIs into

it

...

...

from Apps via an SDK API. Then reflect, for what a central POI service could be beneficial

?

...

...

I have embedded some comments below in green.

I’ve put a few replies below too.

...

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Mittwoch, 20. Januar 2016 16:57 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com;

dev

...

el@lists.apertis.org Betreff: Re: AW: AW: AW: [Devel] Updated geolocation and

navigation

...

...

design document

...

Please keep also in mind, that the navigation app itself is

somehow

...

...

special in regard to their output. Beside provides some UI to

control

...

its functions like all the other apps (e.g. media player), the

“route

...

guidance” information is very special. In addition to a black

box

...

...

...

build-in solution for the route guidance - like all the

smartphone

...

...

Smartphone solutions realizing today – (on prompt the guidance

is

...

...

...

only acoustic or an app-change transition to the navigation app appears) we will go a step forward for this driver related information. The guidance will be presented to the user

independent

...

...

of the current App in use in foreground. So you can “leave” the

navi-

...

app but the guidance shall continue. In fact we influence the internal design by requesting an agent to be provided by the

app-

...

...

...

developer to deliver these data. And that’s not only an

acoustical

...

...

prompt, its also data which gets finally a visual

representation

...

...

...

(turn icons, lane information, etc). In this approach via an

SDK-

...

...

API

...

the rendering gets done by some system service. Its more like a “notification”/“dialog-box”/“status framework” stuff (please

have

...

a

...

...

look to the running status framework and the relation to assist framework too). So the navigation App provides its data as

output

...

...

to

...

some SDK-API. In fact part of this is the route list, which

finally

...

...

land in that guidance dialog. Lets call it assistance window –

driver

...

related information.

I see. The way I would recommend doing this in the design is to implement the guidance UI separately from the navigation UI. It

could

...

potentially be part of the same application bundle, or part of a different one, or even implemented as part of the system chrome. Andre: to be honest, this all is optional. A navi app developer

can

...

...

decide to implement the guidance in its local app-bundle scope.

Then

...

the UI appears within its own App Screen Area. However, since it is beneficial (independent from the POI or

Assist

...

...

Window Discussion) that the guidance portion is separated from

the

...

...

rest of the full-fledge App (because it enables us to handle a separated executable with its own lifecycle, which means we can

keep

...

only that part running in background instead of the Full App) we should ask for an Agent for it. The App developer can decide to

do

...

so

...

or not. So the requirement for isolating the Guidance into an

Agent

...

...

is already valid w/o all the discussion about POIs and/or Assist Window. On top of that we like to also support an assist window solution

as

...

...

part of our system. Therefore we will provide a notification

style

...

...

similar API for driver related information. Guidance data will be covered by it, and if a Navi App developer decided to use this

SDK-

...

...

API, the guidance information will land there (but also

information

...

...

from route list will land in such an assist window). Similar like mentioned above, we like to ask the developer to provide an agent

for

...

the guidance data. However, the assist window (the UI for the guidance) is finally a system chrome element and not deployed

with

...

...

the App bundle. It belongs to the OS and gets distributed with

it.

...

OK, we would have to add a separate SDK API for handling guidance notifications, similar to the existing

org.freedesktop.Notifications

...

API for handling other notifications from applications. I will include a recommendation for that in the next update to the document. Andre: agreed

...

The guidance UI would take data from the SDK points of interest

API,

...

and from the SDK navigation route guidance API (§7.6). This would allow it to render the route (from the guidance API), and points of interest along the way (from the PoI API). The navigation UI (where the driver chooses their destination and plans the route) may retrieve points of interest from the SDK, or may choose not to if the developer thinks they will be distracting. i.e. The SDK API you are suggesting for the data from the

guidance

...

UI

...

is effectively the points of interest API plus the navigation

route

...

...

guidance API. Andre: like said, its not the “points_of_interest” API, its from

the

...

route-list API.

...

To this route list, other apps can directly add further data.

This

...

is

...

_not_ forwarded to the navi-app, it does not modify the route

list

...

...

nor does it gets stored by the navi-app. The navi app don’t has

any

...

...

interest in getting and managing it. This data, gets provided

by

...

...

the

...

source app to the rout–list and with that finally rendered to

the

...

...

...

user by some system service (assist window). On the other hand,

other

...

apps can consume this enriched route list again for their

build-

...

in

...

...

functions and policies. Its all outside the navigation, the

navi

...

...

only

...

provides the initial foundation.

That’s possible due to the split between the navigation UI and

the

...

...

guidance UI. The navigation UI can choose to not query for points

of

...

interest, or can heavily filter the PoI requests it makes. Conversely, the guidance UI can query for lots of PoIs. If other applications want to display something similar to the guidance UI, they must make the same navigation route guidance API and PoI

API

...

queries as made by the guidance UI. This should be simple to do,

and

...

allows each application to further customise the points of

interest

...

...

they display. Andre: to be honest, the use-cases behind that stuff is _not_ that

another

...

...

app will do something similar like the guidance UI.

Sorry, when I said “if other applications want to display something similar to the guidance UI” I meant something more like “if other applications want to display the current route, or the current

route

...

plus nearby POIs”. Andre: I would expect this is build-in behind the scene into libchamplain. So by using libchamplain, Apps get this information already embedded. Similar like they get the current vehicle

position

...

(from geoclue) already well embedded into libchamplain. The

usecases

...

for Apps to use route list information is the stuff mentioned

above.

...

Let me repeat to prevent misunderstanding:

• a Weather App may consumes Intermediate Destination Information

from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places

• a gasoline station app adds a refueling stop into the route list

for a location to be reached at a time where the car runs low on

fuel

...

• a restaurant app may uses information of gasoline stations in the

route list to add recommended cafeterias into the route list to

align

...

the breaks for the driver

• a restaurant app may decides to add restaurant POIs as

recommendations into the route list for a location to be reached at

a

...

time where a break would be wise

• a installed “coupon” app may add available discounts available at

a

...

POI location available in route list.

...

Other Apps uses information form that API for their essential service, e.g. if an App of a weather service does know

intermediate

...

...

destinations from the route list, it may decides to show entries

on

...

...

top of the stored locations for current destination and

intermediate

...

destinations (in todays list you have the current positon for

example

...

as a default, this app could extend that approach depending on

stuff

...

from the route list). Or if a gasoline station app adds a refueling stop into the route list for a location to be reached at a time where the car runs

low

...

on

...

fuel, a restaurant app may uses this information to add

recommended

...

...

cafeterias into the route list to align the breaks for the

driver.

...

...

Or if a restaurant app decides to add restaurant POIs as recommendations into the route list for a location to be reached

at

...

a

...

time where a break would be wise, a installed “coupon” app may

add

...

...

available discounts available at this location. etc.

I don’t think I can fully understand these points without agreeing

on

...

the terminology at the top of the e-mail. Andre: ok, hope my comments given where helpful in that regard. In the current version of the design, these use cases are handled

by:

...

• The gasoline station application exposes gasoline stations as points of interest via the POI API (https://wiki.apertis.org/Points_of_int

er

...

es t). • The restaurant application exposes restaurants as points of interest via the POI API (https://wiki.apertis.org/Points_of_interest). • The navigation application contains the logic to:

• Detect where in the route the vehicle is likely to need

refuelling, query the POI API (https://wiki.apertis.org/Points_of_interest) for gasoline stations, and add them to the route.

• Detect when in the route the driver is likely to need food,

query

...

the POI API (https://wiki.apertis.org/Points_of_interest) for restaurants, and add them to the route. I can’t think of a sensible way of handling coupons at the moment. They don’t really fit into any of the existing APIs. The design is this way round, rather than allowing the restaurant

and

...

gasoline applications to ‘insert’ recommendations into the route

list

...

because it leaves the navigation application in charge of which restaurants (for example) are shown. It means the code for determining when is ‘a good time to stop for food’ is in one place (the navigation application) rather than many (each restaurant application), each

of

...

which could end up using different definitions of when is ‘a good time to stop for food’ in order to gain competitive advantage. Andre: like said above, the design philosophy is an app-centric solution is, to bundle the policy / logic within the provider app.

So

...

its not one central intelligence, orchestrating all others, its

vice

...

versa all the others are providing things accordant to their implemented logic. Apps can compete in providing the same service with another policy or using another service with a similar policy. The user decides by choosing the App which fits best his needs. And he can do in the smallest granularity, per App . So he is able to adopt the overall solution by making dedicated decisions per source (App). (Above, I am using ‘navigation application’ to mean the entire navigation application bundle, including any UIs, agents, or

services

...

which it provides.) Philip

Hi Philip,

thx for your answers. Seems that my concern in regard to responsibility split has been clarified with that. So there is a "service" belonging and deployed with the Apertis OS, who creates an output to Apps based on input received from Apps.

Now lets focus on a feature scope of that service:

"..." In the design as I see it, there is no ‘combined data set’: the SDK route list API service maintains the route list which has been set by one of its backends (with the backend chosen by the user; typically a navigation application bundle), but it does not combine different routes. It could provide multiple alternative routes from the different backends, although, I suppose.

The ‘combined data set’ of POIs is formed at each application where it receives POIs from other applications — in the diagram, this is where all the red arrow heads meet. The application may combine these POIs in a database, or do whatever else it likes with them. Typically, it would combine them with the planned navigation route, which it has received from the SDK route list API (via the yellow arrows in the diagram). "..."

I am exactly asking for a service doing this task _centrally_ for all Consuming Apps. On a the one hand, this does not restrict apps doing whatever they like based on some low level APIs - because the way you explain is still possible anyhow. But since we are talking about which functionality we like to build into our OS, it does not matter what Apps can do by themselves.

There are various benefits of providing a central service for this - it eases the app-development for Apps interested in the aggregated data, because it frees them to do the pain by themselves - it grants consistency, because all apps using this data are using the same foundation instead of app-specific differences - we can push the aggregation capabilities of the central service w/o impact to app-code / responsibilities - we can optionally tune the aggregation policies / algorithms accordant to OEM requirements per product - we can process the aggregated information by further system applications, e.g. by optional system chrome applications (ala notification center), or automotive domain services - etc

So we are discussing here a more powerful service. With that the design proposed based on some low level mechanisms does fit to the intention. Please forget in the first hand - the pipe based mechanism to transfer POI data - the route-list data

We are _not_ asking for an API tailored (or limited) for the special case of sharing a route-list. Its more like a "focal point", the route-list information is included but its not limited to. What we intend to create is a "service" exposing a "horizon". The horizon exposes "data ahead of the vehicle". A navigation app can provide its route-list to it. But in general, its neither limited to the route-list nor to the navigation app. The service aggregates data from various sources (Apps).

And I am not only talking about combining routes from various Sources(Apps). That’s only an example to point out challenges. So don't forget the more common case to add additional objects like POIs to a given Route, as also to add attributes (metadata) to already available objects.

Once this service is available, we do _not_ need any public route-list API exposed to other Apps anymore, because the route-list data is included in the horizon. So if Apps like to get route-list information, they will find them in the horizon data.

However, even though the route list information is distributed via the horizon service to arbitrary Apps, the route-list data itself is delivered by participating navigation Apps. With that the route-list data is provided at a more dedicated API (more private between horizon service and navi app), only relevant for navigation Apps and only if they like to participate as a horizon provider.

In addition we can even discuss the implementation steps/roadmap. So once we have agreed on the complete scope of this service, we can discuss when to introduce which (aggregation) functionality. And in this point of view, the first implementation step could even be limited to provide a route-list only capability, but we would have awareness about what will come up next and with that we could take care about future proofness of introduces APIs.

Rgds Andre

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Freitag, 5. Februar 2016 15:34 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; devel@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document

Hi Andre,

On Thu, 2016-02-04 at 09:56 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

since I still do not know where the blocking factor is let me give some range of feedback, maybe one hits the point

• Apps do not change the system scope, they do not install stuff

(e.g. backends) into the system. They may ship a backend, but all that belongs and gets installed to its black box environment. However, they may exposes data to some already available system service via some SDK-API.

We agree on this. The backends for the SDK route list API in my diagram are provided by application bundles.

• App UI (like "Fuel Station application UI" or "Navigation

UI") belongs the "application bundle"

We agree on this. I did not show that in the diagram in order to keep it legible.

• So the Navi is completely handled as a App-Bundle covering the

"Backend" (including route planning) as also the "UI" in its own black box.

We agree on this. Again, I did not show that in the diagram in order to keep it legible.

• since the "navigation UI" belongs the nav app-bundle, it is

directly connected to its backend The Navi UI can use whatever black-box internal ways to interact with its backend to create its UI. Same like for each other App-Bundle. The Navi is just another App. However, in addition its proprietary backend may exposes some data to a SDK-API service (route-list "horizon"), and the backend may also consumes aggregated data form (this) SDK-API service.

OK, I have noted the potential for an arbitrary connection between the navigation backend and navigation UI.

We agree on the rest: in the diagram, the ‘backend provided by navigation application bundle’ exposes data to the SDK route list API (which is actually a service/process — it’s a box in the diagram). It can also consume data from that API, although that’s not shown in the diagram. There is nothing to prevent that.

• its not like discussed for libchamplain or tts or other topics,

where the "backends" reside in the OS scope (functionality embedded in the OS). In these areas the backend of choice gest decided by the system integrator at point in time of product definition (it cannot be changed by the User). In contrast to that, for navi we enable flexibility during runtime. Installing an app changes the "backend used". So the Navi App Bundle ships the backend and its UI, but does not change installations in the OS. The App bundle exposes data to the SDK.Route List (Horizon) APIs to other Apps. So we shift the responsibility by keeping the app-centric approach - from the integrator to the user and from OS-scope to App-scope.

We agree on this.

• With that flexibility, the User has the option to decides for the

Navi of his choice.

We agree on this.

• if the backend is located in automotive domain, then this is

coupled/bundled with one (maybe build in) "Navi App".

We agree on this.

• The rout-list "horizon" API, is not primary used to create a User-

Interface for a "Navigation" Application, neither from other Apps nor from the App bundle who provides the "backend". The primary purpose for the route-list API "horizon" is _not_ to serve for the navigation build-in functionality. Its for location based services/Apps.

OK, I had been assuming it could be used for the navigation UI, but if the navigation UI and backend want to use an arbitrary connection to communicate routes, that’s fine (as agreed a few points above).

We agree on the fact that the SDK route list API (which you call ‘route-list API "horizon"’) is used for location-based services and applications.

• POIs transferred via the pipe mechanism lands in the App specific

local "database" (not directly at the UI), the App takes over the data responsibility/management, its like an import. The App decides about if and how to persistently store it, when to delete etc. These data runs like all the other local app data though its app-specific business logic / functionality. Its even possible that these data gets only consumed by some algorithms and never lands natively at the UI.

We agree on this, although I have not discussed the possibility of applications storing points of interest in an internal database. What applications do with points of interest once they have received them is up to the application developer — they can store the POIs in a database, display them directly in the UI without storage, or process them without ever putting them in a UI, as you say. That’s why I haven’t mentioned databases.

• think about a setup w/o any navigation installed. Then there is no

navi backend installed. Nevertheless, the is a route-list "horizon" API where Apps can consume data from and expose data to (accordant to their app internal functional scope).

We agree on this: the SDK route list API still exists even if no navigation applications are installed. As I said: it’s a service provided by the SDK (and hence is represented as a box in the diagram I sent). It can be running and providing the SDK route list API to applications and services even if no backends are available from navigation application bundles (or other bundles).

• It could even be the case that some Apps who are not being a

"navigation App" provide some most probable path information to the horizon. Its not a route -since no destination is set and even no navigation installed), but guessing about the way ahead. It could be limited in length (e.g. only until next intersection, or a little ahead of this with even multiple pathes from each intersection, etc). And this can also be added in case a route is given, adding more information about alternative links at intersection could be benefitail for some other Apps to know. So finally its not only POI.

We agree on this: such applications could provide a backend for the SDK route list API just like navigation application bundles can.

so some questions:

• which "component" represents the glue (the framework) between the

LBS-Apps (like Navi, Restaurants, Sightseeing, etc), to receive dedicated data from individual producers (LBS Apps), creates and maintains a combined data set, and deliver the data exposed as route- list "horizon" API to consumers (its not the "backend" located in the App Bundle if a a Navi App, this backend is itself a producer only) ?

This is a combination of the SDK route list API (and the service which provides it, which is part of the SDK and provided by Apertis), and the POI API with its peer-to-peer connections from any other application which provides a points of interest interface.

In the design as I see it, there is no ‘combined data set’: the SDK route list API service maintains the route list which has been set by one of its backends (with the backend chosen by the user; typically a navigation application bundle), but it does not combine different routes. It could provide multiple alternative routes from the different backends, although, I suppose.

The ‘combined data set’ of POIs is formed at each application where it receives POIs from other applications — in the diagram, this is where all the red arrow heads meet. The application may combine these POIs in a database, or do whatever else it likes with them. Typically, it would combine them with the planned navigation route, which it has received from the SDK route list API (via the yellow arrows in the diagram).

(Btw, a Navi Backend from a proprietary Supplier may do not has at all any of the capabilities needed to aggregate POI data from various sources into a combined set. )

In the design there is no need for the navigation backend to aggregate POI data — that is done by the applications which are consuming the POI data (the heads of the red arrows in the diagram).

• in which format/way gets this data forwarded to this component ? It

does not need to be the pipe based POI mechanism only because we have it. Geoclue also deals with coordinates and nevertheless uses another kind of API to exchange information with its backends. On top its not only POIs, ist also links(streets) etc to be provided to the "horizon" framework.

The design recommends (in §7.6 of version 0.3.1 of the design) a D-Bus interface for the SDK route list API which exposes each possible route as an array of (latitude, longitude) coordinates.

Are the areas in the diagram where I’ve highlighted components which have responsibility for making decisions correct, in your understanding? These are the blue circles in the diagram.

Philip

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Mittwoch, 3. Februar 2016 16:18 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; dev el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document

Hi Andre,

As far as I can tell, the design I suggested in my previous e-mail does match your requirements for which components have responsibility for different decisions or pieces of information: • Applications choose which POIs to advertise, and the navigation UI displays them unconditionally (subject to rate limiting) • The route list API is provided by the SDK, in the system, and supports multiple backends — the backend might be provided by the navigation application bundle, but might instead be in the automotive domain, or something else • The navigation UI is just another application, and has no special powers or functionality • Applications choose which waypoints to send to the route list API to be added into the route — this might result in the user being prompted ‘do you want to add this waypoint into your route’, or they might be added unconditionally

I have attached a diagram of the system as I described it in my previous e-mail, and have attempted to highlight all the data flows and the decisions which drive them. (Apologies for the crudeness of the drawing; I did it rapidly.)

Please could you take a look and see where our understandings differ, and highlight specifically what the differences are.

Thanks, Philip

On Wed, 2016-02-03 at 14:16 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

...

Hi Philip, Thanks for your answer, but we are still not on the same page. We talking about different things. There are other parts beside feature requirements which influence the decomposition. Its seems for me that you are focusing on features and if the design/decomposition proposed is able to realize it. My focus is alignment with app-centric design, so responsibilities & dependencies (I only use features to make things more clear). So if you are saying the design can provide the feature, then that’s not what I am talking about. I am talking about the design does not fit to the non-function requirements (app-centric solution). Parts of the functionality belongs to the wrong responsibility or we even do need to split an entity into parts to deploy the responsibility to different parties. Since we are iterating in cycles a little bit and I start to gets doubts about the efficiency of this kind of mail threads, let us limit the iterations. If within a few next ones we do not conclude, then lets have a call about it. But for now let me try to explain my intention again via email: So yes, one can technically pass everything through the navigation App, delivering all POIs to the App as also requesting a consolidated data from it. That’s possible. And the design is done in that way. And that’s not the way how it shall be. So its not the question if the current design can also realize the mentioned features. The POI mechanism defined already was motivation by the update of the navi-database with data needed for route calculation. Only for that purpose. So for now, please forget the POI mechanism defined already. Now we are talking about the “route list”. Maybe the naming is not beneficial, internally we typically use the term “horizon”. Its dedicated scope is to carry information related to the (expected) vehicle position, starting from the current location up to expected future positons. This is where the term route-list comes into the game. The goal now is to provide a framework, where all apps can consume data from for their internal processing as also provide data to this framework (to enrich it). This all is also valid w/o any route available. In that case the data focus more around the current vehicle position. It is even valid, if there is no navigation app installed at all. There is nevertheless the current geo position available (e.g. from geoclue, and maybe even only on WLAN based positioning so without any GPS solution, that doesn’t matter). The navigation App is just another App, optionally producing data to that framework and/or consuming data from it (e.g. the information about the current route, including its intermediate destinations etc). And it could even be that multiple Apps, dealing with most probable pathes exposes information to this horizon (not only the Navi App currently maintaining the active route). The framework is completely independent of the developer of a particular Navigation App, this solutions is completely out of the scope/responsibility of the navigation provider. It belongs to the system, the OS. And yes, intermediate destinations are provided and handled by a navigation app, again via another mechanism (the scheme mechanisms, not the POI one). And if a new intermediate destination has been defined via this way, and the route has been updated, then the navi app can expose it to the said horizon framework. And another App can consume this new information about an intermediate destination for their scope and may also add new data to this framework accordingly. So what I am asking for is, to keep the POI mechanism as a way of choice for database updates, and to add an additional framework – which we can call “horizon” or something else - where Apps can produce data to as also consume data from it. The Navi App shall be able to provide its route list information to it and update it. Rgds Andre -----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Dienstag, 2. Februar 2016 18:27 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; dev el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document Hi Andre, Replies inline. I’ve trimmed a few of the parts of the e-mail which we agree on. On Tue, 2016-01-26 at 13:03 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

...

However, my understanding of https://wiki.apertis.org/Points_of_interest design is, that only

the

...

control flow runs via a central SDK service, but if allowed it establishes a private point-to-point channel (pipe) between

producer

...

App and consumer App (w/o any SDK service inbetween anymore). With that, the content itself (the POIs) are untouched form the so

called

...

"central POI service", the POIs are neither stored/cached, nor distributed by them. With that, the "SDK-Service" (central POI service) does _not_ return points of interest like restaurants, filling stations and tourist attractions. As also there is no capability to define filters in that request, since in an app-

centric

...

approach the policies are belonging to the Source/Producer App. The SDK service itself only establishes private point to point connections.

That is correct. I guess when I’ve been saying ‘POI service’ or ‘POI system’ from the point of view of an application which is consuming POI data (such as the navigation UI, or another application which needs to display POIs), I would consider the ‘POI service/system’ to be the set of all applications which are providing POIs over peer-to-peer connections.

...

• Route list: a list of objects which describe the route for a navigation, i.e. the roads to take; this might include alternative routes; it _does_ include Point objects like intermediate destinations on the route so there are point type objects already included in that structure

as

...

also attributes/metadata for each object for further details.

Yes, although the metadata is limited to a description for the location and what type of point it is (start, waypoint, waypoint which is for routing only and isn’t a destination, final destination).

...

Please note, that the navigation "route-list" is something

different

...

than the navigation "guidance". The guidance focus on detailed description of turns ahead, the route-list has a different focus

it

...

describes the complete trip. So that’s 2 APIs and different structures/objects. I would recommend to adopt the document accordingly.

Noted — I will include this in the next update to the document.

...

And what I am talking about now is, that apps shall be able to augment the route list returned by the SDK-API . The route list exposed via the route-list SDK-API for sure gets provided (and updated) by the navigation app (somehow similar like it can do it

for

...

the geo-position to geo-clue), but Apps can augment data to it. The APIs realizing this capability have second priority for me, but nevertheless I like to cover it right from the beginning from conceptual point of view. With "create some functionality" I do mean the samples provided to explain use-cases where Apps consume and augment POIs to the route list:

• a Weather App may consumes Intermediate Destination

Information from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places

• a gasoline station app adds a refueling stop into the route

list for a location to be reached at a time where the car runs low on

fuel

...

• a restaurant app may uses information of gasoline stations in

the route list to add recommended cafeterias into the route list to

align

...

the breaks for the driver

• a restaurant app may decides to add restaurant POIs as

recommendations into the route list for a location to be reached at

a

...

time where a break would be wise

• a installed “coupon” app may add available discounts available

at

a

...

POI location available in route list. The major thing is, in an app centric approach, the policies are coupled with the source of the data. Its _not_ the navigation app which orchestrates the other apps - like in a systemic client-

server

...

model, what to deliver. This limits the capabilities to fantasy provided by the navigation app developer as also his capabilities

and

...

development work. In an app-centric approach its completely vice versa, each app focus on its essential service, a navigation calculates the route. That’s it. And a restaurant app deals the

POI,

...

and handles all policies and User Interaction to choose/handle

them,

...

even though they may finally gets used to set a new destination or they land in the route list.

OK. I think this fits with my proposed design and the Points of Interest design as they currently stand, although I should clarify things. The route list API continues to provide only the list of roads to take (i.e. the geometry of the route) as I described in my previous e- mail. Applications which provide POIs query this API to find out the current route, as described in the fourth paragraph of https://wiki.apertis.org/Points_of_interest#Recommendations. The navigation UI uses interface discovery to find applications which provide POI data. It then queries them (via peer-to-peer connections) for general and specific POIs, as described in the POI design. Its shall not be the responsibility of the Navigation to requests it/or not. Its done by the Providing Apps autonomously. It shall not depend on the code (responsibility) of the navigation App at all if this The logic for working out what POIs to send to the navigation UI lies within each application. The navigation UI does no filtering based on content (though for security reasons it might want to apply some rate limiting to prevent DoS attacks). It simply displays all the POIs it receives. It might be possible for an application to add metadata to a POI it sends to the navigation UI to say ‘please add this POI as a waypoint’, in which case the navigation UI could prompt the user about it (or add the destination anyway, or ignore it — this policy is up to the navigation UI developer). If the POI is added as a waypoint in the route, the SDK route list API would signal an update to the route, which would be received by the navigation UI and all applications providing POIs to it. This would allow for the coupon use case — if a restaurant gets added as a waypoint, the coupon application could start emitting a POI for using coupons there. If another application wants to display the same map view as the navigation UI, showing the route and POIs on it, it has to make the same API calls as the navigation UI: a call to the SDK route list API to get the route; and interface discovery followed by peer-to-peer retrieval of POIs from other applications. So, in short, the ‘augmented route list’ is provided by a combination of the route list API and the POI system (i.e. retrieving POIs from other applications using peer-to-peer connections). I hope that makes sense? Philip

...

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Montag, 25. Januar 2016 15:56 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com;

dev

...

el@lists.apertis.org Betreff: Re: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document Hi Andre, On Fri, 2016-01-22 at 17:16 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:

...

Hi Philip, I feel we are still not fully on the same page. We closed some

gaps

...

...

lately (in regard to the assist-window), but it seems to me that

we

...

...

still have a gap in regard to POI handling itself. So summarize, let me go one step back and start with

•   POI service is _not_ equal to route-list.
  

I am talking about a route list, you are talking about a central

poi

...

service.

To check, what do you mean by the terms ‘POI service’ and ‘route list’? I interpret them as: • POI service: an SDK service which returns points of interest

like

...

restaurants, filling stations and tourist attractions • Route list: a list of points which describe the plotted route

for

...

a navigation, i.e. the roads to take; this might include alternative routes; it does not include nearby POIs Andre: hope this is answered above

...

Let me add:

•   we do _not_ need a central POI service, or vice versa I
  

am

...

...

not aware about a related requirement.

All suggestions I have made about POI handling in the context of

the

...

Geolocation and Navigation document have been references to the existing https://wiki.apertis.org/Points_of_interest design. I am

not

...

suggesting changes to that design, nor am I suggesting copying

parts

...

of it into this design (or any of the navigation APIs). Andre: I see.

...

We do have the already mentioned 3 Use cases and the mechanisms discussed covers the use-cases already perfectly

1. for in app UI browsing: libchamlain. We have it, fine.

Yes.

...

2. for app import / handover: Pull mode for various types of

content

...

– also TPEG based POI data - https://wiki.apertis.org/Points_of_interest (For completion there is also a push mode for various types of content – so far no need for TPEG support - https://wiki.apert is

.o

...

rg

...

/Data_sharing ) again, we have it designed already.

Yes.

...

3. now we add the route-list to the SDK-API, where I also ask

to provide capabilities to add POIs to it (independent from the

navi-

...

...

app)

I think this is covered by the SDK navigation route guidance API (§7.6 of version 0.3.1 of the document), if we are using the same meaning for ‘route list’ (see above). Andre: see above, I think we do need 2 API scopes, one for “route- list” one for “guidance”

...

In any case we do need the route list, it has originally nothing

to

...

...

do with the POI discussion. Apps shall be able to consume

information

...

about the current route and to create some functionality. That

the

...

...

purpose of the route list essentially.

What do you mean by ‘create some functionality’? In the design as it stands currently, applications cannot augment

the

...

route list returned by the SDK navigation route guidance API. They can augment the list of POIs returned by the POI API (https://wiki.ap er

ti

...

s. org/Points_of_interest). Andre: see above, I do mean things like that

• a Weather App may consumes Intermediate Destination

Information from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places

• a gasoline station app adds a refueling stop into the route

list for a location to be reached at a time where the car runs low on

fuel

...

• a restaurant app may uses information of gasoline stations in

the route list to add recommended cafeterias into the route list to

align

...

the breaks for the driver

• a restaurant app may decides to add restaurant POIs as

recommendations into the route list for a location to be reached at

a

...

time where a break would be wise

• a installed “coupon” app may add available discounts available

at

a

...

POI location available in route list.

...

Based on that scope, I am asking for the additional functionality

to

...

add Metadata/Content from Apps directly to it, especially POIs.

Its

...

...

neither a first priority nor will it dramatically change the

design.

...

Its simple an add-on. We can even decide to implement it later.

For clarity, which API do you mean by ‘it’? Andre: I do mean the capability for Apps to augment POIs into the Route-List

...

Similar stuff is valid for the guidance & assist window

discussion.

...

...

The APIs for the “guidance” (which is “just another notification style API for a dedicated purpose”) as also the assist window

(which

...

is just another system chrome application where for example the

data

...

exposed via the guidance notification style SDK-API lands in) are optional and don’t have side effects to other SDK-APIs. So we can implementation wise realize it in a later step, its not of first priority. However, I like to have a common understanding about

the

...

...

overall scope early. If we provide capabilities to add metadata into an available

route-

...

...

list to Apps, other Apps (than the navi app) can add additional content/ additional metadata to available content, for example

POIs

...

...

into a currently shared route list. Since we have already libchamplain and also the Point_of_interest and sharing

mechanisms

...

...

design, My focus is on just one more method for that route- list.

I

...

am

...

_not_ talking about any big thing, especially not about a central

POI

...

service. I would like to propose we serialize the discussion. How about

first

...

finalizing the solution for the route list, including POIs into

it

...

...

from Apps via an SDK API. Then reflect, for what a central POI service could be beneficial

?

...

...

I have embedded some comments below in green.

I’ve put a few replies below too.

...

-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Mittwoch, 20. Januar 2016 16:57 An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com

...

;

dev

...

el@lists.apertis.org Betreff: Re: AW: AW: AW: [Devel] Updated geolocation and

navigation

...

...

design document

...

Please keep also in mind, that the navigation app itself is

somehow

...

...

special in regard to their output. Beside provides some UI to

control

...

its functions like all the other apps (e.g. media player), the

“route

...

guidance” information is very special. In addition to a black

box

...

...

...

build-in solution for the route guidance - like all the

smartphone

...

...

Smartphone solutions realizing today – (on prompt the guidance

is

...

...

...

only acoustic or an app-change transition to the navigation app appears) we will go a step forward for this driver related information. The guidance will be presented to the user

independent

...

...

of the current App in use in foreground. So you can “leave” the

navi-

...

app but the guidance shall continue. In fact we influence the internal design by requesting an agent to be provided by the

app-

...

...

...

developer to deliver these data. And that’s not only an

acoustical

...

...

prompt, its also data which gets finally a visual

representation

...

...

...

(turn icons, lane information, etc). In this approach via an

SDK-

...

...

API

...

the rendering gets done by some system service. Its more like a “notification”/“dialog-box”/“status framework” stuff (please

have

...

a

...

...

look to the running status framework and the relation to assist framework too). So the navigation App provides its data as

output

...

...

to

...

some SDK-API. In fact part of this is the route list, which

finally

...

...

land in that guidance dialog. Lets call it assistance window –

driver

...

related information.

I see. The way I would recommend doing this in the design is to implement the guidance UI separately from the navigation UI. It

could

...

potentially be part of the same application bundle, or part of a different one, or even implemented as part of the system chrome. Andre: to be honest, this all is optional. A navi app developer

can

...

...

decide to implement the guidance in its local app-bundle scope.

Then

...

the UI appears within its own App Screen Area. However, since it is beneficial (independent from the POI or

Assist

...

...

Window Discussion) that the guidance portion is separated from

the

...

...

rest of the full-fledge App (because it enables us to handle a separated executable with its own lifecycle, which means we can

keep

...

only that part running in background instead of the Full App) we should ask for an Agent for it. The App developer can decide to

do

...

so

...

or not. So the requirement for isolating the Guidance into an

Agent

...

...

is already valid w/o all the discussion about POIs and/or Assist Window. On top of that we like to also support an assist window solution

as

...

...

part of our system. Therefore we will provide a notification

style

...

...

similar API for driver related information. Guidance data will be covered by it, and if a Navi App developer decided to use this

SDK-

...

...

API, the guidance information will land there (but also

information

...

...

from route list will land in such an assist window). Similar like mentioned above, we like to ask the developer to provide an agent

for

...

the guidance data. However, the assist window (the UI for the guidance) is finally a system chrome element and not deployed

with

...

...

the App bundle. It belongs to the OS and gets distributed with

it.

...

OK, we would have to add a separate SDK API for handling guidance notifications, similar to the existing

org.freedesktop.Notifications

...

API for handling other notifications from applications. I will include a recommendation for that in the next update to the document. Andre: agreed

...

The guidance UI would take data from the SDK points of interest

API,

...

and from the SDK navigation route guidance API (§7.6). This would allow it to render the route (from the guidance API), and points of interest along the way (from the PoI API). The navigation UI (where the driver chooses their destination and plans the route) may retrieve points of interest from the SDK, or may choose not to if the developer thinks they will be distracting. i.e. The SDK API you are suggesting for the data from the

guidance

...

UI

...

is effectively the points of interest API plus the navigation

route

...

...

guidance API. Andre: like said, its not the “points_of_interest” API, its from

the

...

route-list API.

...

To this route list, other apps can directly add further data.

This

...

is

...

_not_ forwarded to the navi-app, it does not modify the route

list

...

...

nor does it gets stored by the navi-app. The navi app don’t has

any

...

...

interest in getting and managing it. This data, gets provided

by

...

...

the

...

source app to the rout–list and with that finally rendered to

the

...

...

...

user by some system service (assist window). On the other hand,

other

...

apps can consume this enriched route list again for their

build-

...

in

...

...

functions and policies. Its all outside the navigation, the

navi

...

...

only

...

provides the initial foundation.

That’s possible due to the split between the navigation UI and

the

...

...

guidance UI. The navigation UI can choose to not query for points

of

...

interest, or can heavily filter the PoI requests it makes. Conversely, the guidance UI can query for lots of PoIs. If other applications want to display something similar to the guidance UI, they must make the same navigation route guidance API and PoI

API

...

queries as made by the guidance UI. This should be simple to do,

and

...

allows each application to further customise the points of

interest

...

...

they display. Andre: to be honest, the use-cases behind that stuff is _not_ that

another

...

...

app will do something similar like the guidance UI.

Sorry, when I said “if other applications want to display something similar to the guidance UI” I meant something more like “if other applications want to display the current route, or the current

route

...

plus nearby POIs”. Andre: I would expect this is build-in behind the scene into libchamplain. So by using libchamplain, Apps get this information already embedded. Similar like they get the current vehicle

position

...

(from geoclue) already well embedded into libchamplain. The

usecases

...

for Apps to use route list information is the stuff mentioned

above.

...

Let me repeat to prevent misunderstanding:

• a Weather App may consumes Intermediate Destination

Information from Route List to show entries on top of the user stored locations in its UI to inform the User about weather at this places

• a gasoline station app adds a refueling stop into the route

list for a location to be reached at a time where the car runs low on

fuel

...

• a restaurant app may uses information of gasoline stations in

the route list to add recommended cafeterias into the route list to

align

...

the breaks for the driver

• a restaurant app may decides to add restaurant POIs as

recommendations into the route list for a location to be reached at

a

...

time where a break would be wise

• a installed “coupon” app may add available discounts available

at

a

...

POI location available in route list.

...

Other Apps uses information form that API for their essential service, e.g. if an App of a weather service does know

intermediate

...

...

destinations from the route list, it may decides to show entries

on

...

...

top of the stored locations for current destination and

intermediate

...

destinations (in todays list you have the current positon for

example

...

as a default, this app could extend that approach depending on

stuff

...

from the route list). Or if a gasoline station app adds a refueling stop into the route list for a location to be reached at a time where the car runs

low

...

on

...

fuel, a restaurant app may uses this information to add

recommended

...

...

cafeterias into the route list to align the breaks for the

driver.

...

...

Or if a restaurant app decides to add restaurant POIs as recommendations into the route list for a location to be reached

at

...

a

...

time where a break would be wise, a installed “coupon” app may

add

...

...

available discounts available at this location. etc.

I don’t think I can fully understand these points without agreeing

on

...

the terminology at the top of the e-mail. Andre: ok, hope my comments given where helpful in that regard. In the current version of the design, these use cases are handled

by:

...

• The gasoline station application exposes gasoline stations as points of interest via the POI API (https://wiki.apertis.org/Points_of_i nt

er

...

es t). • The restaurant application exposes restaurants as points of interest via the POI API (https://wiki.apertis.org/Points_of_interest). • The navigation application contains the logic to:

• Detect where in the route the vehicle is likely to need

refuelling, query the POI API (https://wiki.apertis.org/Points_of_interest) for gasoline stations, and add them to the route.

• Detect when in the route the driver is likely to need food,

query

...

the POI API (https://wiki.apertis.org/Points_of_interest) for restaurants, and add them to the route. I can’t think of a sensible way of handling coupons at the moment. They don’t really fit into any of the existing APIs. The design is this way round, rather than allowing the restaurant

and

...

gasoline applications to ‘insert’ recommendations into the route

list

...

because it leaves the navigation application in charge of which restaurants (for example) are shown. It means the code for determining when is ‘a good time to stop for food’ is in one place (the navigation application) rather than many (each restaurant application), each

of

...

which could end up using different definitions of when is ‘a good time to stop for food’ in order to gain competitive advantage. Andre: like said above, the design philosophy is an app-centric solution is, to bundle the policy / logic within the provider app.

So

...

its not one central intelligence, orchestrating all others, its

vice

...

versa all the others are providing things accordant to their implemented logic. Apps can compete in providing the same service with another policy or using another service with a similar policy. The user decides by choosing the App which fits best his needs. And he can do in the smallest granularity, per App . So he is able to adopt the overall solution by making dedicated decisions per source (App). (Above, I am using ‘navigation application’ to mean the entire navigation application bundle, including any UIs, agents, or

services

...

which it provides.) Philip