[Devel] Updated geolocation and navigation design document

[Barkowski Andre (CM-CI1/PRM1)]

Hallo Philip,

 

please find my answers enclosed in green

 

Rgds

Andre

 

 

-----Ursprüngliche Nachricht-----
Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk] 
Gesendet: Donnerstag, 26. November 2015 10:20
An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>; devel at 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.

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.apertis.org/pipermail/devel/attachments/20151201/e103cdb1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6749 bytes
Desc: not available
URL: <http://lists.apertis.org/pipermail/devel/attachments/20151201/e103cdb1/attachment-0001.bin>