Hi Philip, please find my feedback enclosed in green
Rgds Andre
-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Dienstag, 12. Januar 2016 18:43 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; devel@lists.apertis.org Betreff: Re: AW: AW: [Devel] Updated geolocation and navigation design document
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 mailto:Andre.Barkowski@de.bosch.com >; dev el@lists.apertis.org mailto: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
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.
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.
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.
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)
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.
- 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 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?
Andre: hope it became more clear. But please don’t hesitate to ask.
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?
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.
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, vehiclecursor)
Information (maybe a subset) from the route list, i.e. thedestination (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.
Andre: yes
- 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.
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.
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.
Andre: great
- 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. Andre: yes, lets do that.
- 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 (alignedwith App lifecycle/)
in “route list” as extended information / attributes (alignedwith lifecycle of a route)
in “Navigation” (via on pull-mode and interface discovery https://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?
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.
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.
- 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
