[Devel] Updated geolocation and navigation design document

Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski at de.bosch.com
Thu Nov 19 12:42:36 GMT 2015


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)

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)
- 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) 
- add UseCase: to share/subscribe (updated) route-information 
- 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.
- 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.
- add UseCase: for map-widget (with temporary integrated POI data) its integrated data sources (position, destination, route, 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 
- 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
NAVI:
- add UseCase: which describes the installation / exchange of a Navi App, and with that the Technology/Backend used can be exchanged
- 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
- 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)
- add UseCase: explains how a Navi App can produce data for other (LBS) Apps  (becomes a backend replacement / a data server for SDK-API)
- 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)

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 use-case "proprietary geo-backend in a derivative of Apertis may expose functionality beyond the standard set" is valid. But the proposal for realization should not be included into the UseCase Chapter. The one proposed should go for an extended SDK-API.
- 3.5 sounds for me its a Navi-App internal feature and uses the app-internal User preferences for route calculation. 
- 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.
- 3.7. sounds for me like a Navi-App internal feature
- 3.8. sounds for me like a Navi-App internal feature
- 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. 
-  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
- 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
- 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.
- 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
- 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.
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
3.20,21 great sample case. 
3.22 also a valid use-case, 3rd party navi apps has to use some system info APIs 
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). 
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.
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 
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.
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. 
 

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.
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
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.
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. 
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 
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.
5.17. for LBS-Apps, from my point of view this is more a lib-champlain feature. But maybe I am wrong.
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.
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
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.
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
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. 


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.


Following some comments in regard to section 6 - existing solutions
- please add a Reflection of what Genivi is doing
- 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.
- 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. 

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.
- 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.
- 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)


Rgds
Andre


-----Ursprüngliche Nachricht-----
Von: Devel [mailto:devel-bounces at lists.apertis.org] Im Auftrag von Philip Withnall
Gesendet: Donnerstag, 12. November 2015 17:40
An: devel at 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


More information about the Devel mailing list