Hallo Philip, please find my answers enclosed in green Rgds Andre -----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>; devel@lists.apertis.org Betreff: Re: AW: [Devel] Updated geolocation and navigation design document Hi Andre, […]
- 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. 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.
- 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. […]
- 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 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. 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.
- 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). 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. 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
- 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). 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.
- 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.
From UseCase imaging a weather app, where the user can define the locations of interest. The User likes to type in cities like
“Berlin”, “Paris” etc, (including ambiguity resolution, i.e. there are many Berlins in the world, so some selection to be chosen from gets provided from the Backend service, a popup shown and the user select one) So the Weather App provides some action to add a new location, a keyboard appears where the User can type in something, at this point in time (encapsulated from the App) already all the handling takes place to process the location identification mentioned above and the app gets a result the location name as also representative geo-coordinates. The App adds the received location name into its list of user monitored weather locations and uses the received geo-coordinates to fetch the weather information at this place. […]
- 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).
- 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. 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. 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. […]
- 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”. […]
- 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” […]
- 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 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. […]
- 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,
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.
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. 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. […]
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. […]
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. […]
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. […]
- 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. Andre: great. I will also add an alternative design for the address completion component, using the Google Places API. Andre: thx. 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.