[Devel] Updated geolocation and navigation design document

Philip Withnall philip.withnall at collabora.co.uk
Tue Jan 12 17:43:21 GMT 2016

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 at collabora.co.uk> Gesendet: Donnerstag, 26. November 2015 10:20
> An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>; dev
> el at 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:


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

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

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

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

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

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

Could you clarify this please?

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

OK, I’ll incorporate that into the document.

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

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

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

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

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

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


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

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

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

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

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

That’s all clear, thank you.

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

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

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

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

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

> > - add UseCase (or a reference in some way): to handover/import POIs
> > (e.g. Traffic information) which we do have already separately
> > covered in our wiki (add a reference). Via that usecase one can
> also
> > explain, how a user is able to select data sources to be used by a
> > Navi App by loading the one of interest from Store (out of various
> > alternative sources for traffic information)
> I have made sure there is a cross-reference to the POI design from
> the
> 'POI data' non-use-case section. I believe selecting POI sources for
> the navigation application should be internal to the navigation
> application.
> Andre: yes, but please keep in mind that the method of “selection” is
> _not_ based
> on “business logic” within the navi software, but by the User.
> So the User will make his decision in the context of the Navi App
> (its setting & preferences, similar like access to a camera roll gets
> granted or not).
> The Navi App exposes its interest, the User grants it or not and can
> it change at every
> Point in time. Via this mechanism, the user can “configure”, which
> sources to use.

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

> > Specific
> > - 3.2.1 the sentence "functionality may be exposed directly by the
> > backend and used by applications using specific APIs on the
> backend".
> > To be honest, I would love to go for some SDK-APIs also for this
> > extension. We can "tag" them as "product specific", but maybe
> > something similar will be provided from other backends too. To
> having
> > a "normalization" layer in-between is also beneficial from
> backwards
> > compatibility point of view. If we have direct dependencies to App,
> > we run short in compatibility tests.
> The point of this use case was that such backend-specific APIs expose
> functionality which is //not// covered in the SDK API — if it were
> covered in the SDK API, they would not be backend-specific APIs! I
> will
> amend the document to clarify that the SDK APIs can be extended in
> future if it seems appropriate to standardise some functionality from
> multiple backends which was previously only available as backend-
> specific APIs.
> Andre: for me it looks like this is a very specific use-case. An App,
> who
> uses APIs not part of the SDK becomes a build-in App (formerly named
> as core-apps)
> and needs to be updated with the OS. It has a tight relationship, and
> since we only guarantee
> backwards compatibility for the SDK, the update path (bundled with
> the OS) changes.
> (see applications proposal).
> We intend to use this way to bridge 'automotive backend'
> functionalities via representative
> Agents. These Agents becomes then “build-in” ones,  and they use some
> backend-specific APIs
> for implementation. But its not to expose this backend-specific APIs
> to other Apps, its more like
> a Web-App uses a proprietary API to connect to its Backend and the
> same will happen for the Agent
> using a proprietary interface to its automotive Backend. However, the
> connection to automotive
> Backends will be discussed further in the scope of “Interdomain
> Connection” Proposal. We will
> See on what we conclude finally.

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

> > - 3.6. from my point of view it’s a valid use-case, but to be
> honest
> > I do not see the specific topic which influences the requirements
> and
> > API proposal for the scope of this document. For me it is similar
> > like a Media Player app continues to render music if another App
> > takes foreground focus.
> The motivation for this use case was to ensure that routing is
> implemented as an agent and application, rather than purely as an
> application (which would stop being able to output audio if suspended
> or moved to the background).
> However, that's a navigation-application-internal feature, so I have
> dropped the use case.
> Andre: thx, that a valid one. We should put this into the special
> chapter
> Which explains to 3rd parties “how to integrate a navi app”.

Will do.

> > - 3.9 change the scenario from "Navi" to "LBS" app. But to be
> honest,
> > this is not a first priority goal. This is very special for
> "address
> > input", but since the SDK-API is for general purpose, one do not
> > really know If the user types in a "address" or a "POI name". So
> > "Eiffel Tower" is maybe not a valid address (in the meaning of
> city,
> > street etc.), but it describes a location. Text-ahead search is
> maybe
> > very challenging for that. This extended scope is very challenging
> > for offline solution, because the database will increase to a
> > significant size. This lead to online cloud based solution, which
> may
> > have issues with availability or performance. However, lets keep
> the
> > use case and see how far we come.
> Agreed. I will rephrase the use case to be LBS-only, and re-evaluate
> the implementation suggestion to see how feasible it is.
> Andre: yes, lets look about the capabilities of backends.
> In addition - since an installed Navigation _can_ become a data
> provide for one, multiple or all backends -
> this would one more type of data  which can be replaced/provided by
> an installed navigation backend.
> So we would have map tiles for libchamplain, position for geoclue,
> route-list for “tbd SDK-API”, etc
> and now “transformation of a location name to a geo-position with
> text-ahead support”

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

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

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

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

> > - 3.17 may can be changed to LBS App, consuming it. However, we can
> > also keep this in a sense, that a Navi app can replace the backend
> > and produce road info for the SDK-API.
> I have dropped this one, because I cannot think of a use case where
> an
> LBS application would need to know road information.
> Andre: see above in regard to use-cases, where an app likes to know
> road information of the track ahead. E.g. for Hazard spot warning,
> rest station, etc,

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

> > 3.18 from my point of view it’s a valid use-case, but to be honest
> I
> > do not see the specific topic which influences the requirements and
> > API proposal for the scope of this document. For me it is similar
> > like a last User-Mode.
> > 3.19 sounds for me like a Navi-App internal feature
> Dropped. I have tried to think of use cases for where an LBS
> application might need to be notified of the navigation destination
> (and when it changes), but I can't think of any use cases which
> aren't
> already handled by using geolocation or geofencing.
> Andre: again, see above. If the route changes, the restaurant app
> would like to update the rest stations recommended to the user. That
> not geolocation as also not geofencing.


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

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

> 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!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160112/f199b32a/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5445 bytes
Desc: not available
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160112/f199b32a/attachment-0001.bin>

More information about the Devel mailing list