Example Use Case: Map Enrichment

The following use case provides an example of map enrichment achieved using HERE data. In this use case, the goal is to create an updated map data product using a combination of data from fleet vehicles and HERE data, both standard and premium, all while ensuring that updated map data is available to the fleet vehicles.

User Story

AS AN OEM Engineering Lead,

I WANT Updated speed sign information based on sensor observations from my fleet vehicles, including:

  • Hourly, for my internal management reporting via my application.
  • Daily, to provide map updates to my fleet of vehicles via my vehicle backend web service.

SO THAT My customers with connected vehicles can receive accurate and timely speed warnings and optimized routing information.

Use Case Diagram View
Figure 1. Use Case Diagram

Component Workflow

The following figure provides a solution workflow of the components involved in this use case.

End To End Service Solution Workflow Architecture
Figure 2. End To End Service Solution Workflow Architecture

Cost Estimation Inputs

The following tables provide information on evaluating the needs of this specific example use case and determining critical sizing inputs (usually done by a Solution Architect).

Business Use Case Details
  1. Volume of data per day (GB) coming into the system as observations
    1. This information translates into how much data will be stored and processed.
  1. Number of updates per day (Count), both archived and updated to the reporting application
    1. This information translates into how many times a day this data is stored and processed for the reporting application.
  1. Number of tiles at a specific zoom level (Zoom Level 9) to achieve a reasonable map update size which can be sent back to vehicles over a mobile network
    1. Typically, a reasonable vehicle driving area would be represented by hundreds of KBs to MBs chunks of data.
  1. Necessary retention policy (Days)
    1. This information is used for storage retention calculations.
  1. Average data point or single observation size (Bytes)
    1. This information influences the throughput which can be processed (i.e. the size the of message ingested into the system); more messages require more CPU.
    2. (1) and (5) inform the size and number of messages.
Technical Recommendations
  1. Determine number of partitions targeting MB range partitions because Blob storage works best for partition sizes between 1MB and 1GB.
    1. Partition by HEREtile to optimize distributed processing.
      1. Optimize speed and efficiency of processing by efficient caching; can load different parts of the map to different processing nodes all based on HEREtile.
    2. Partition by time for easy management of time sensitive data.
  1. Determine partitions on the output layer based on geography and sub-MB vehicle downloads, which is optimal for sending data to vehicles over a mobile network.
  1. Throughput chosen as 1/10 of map matching throughput.
    1. Greater complexity than simple map matching; this use case correlates, clusters and compares data.
    2. Default HERE Path Matching runs at 9k GPS points per second per core.
  1. Production software should not log more than 10MB per run.
  1. Most use cases do not require Internet access, and should not incur Pipeline IO costs unless the data or configuration is pulled externally.

Cloud Services: Points of Expense

A "point of expense" refers to any event where data is transfered, stored, or computed using billable cloud services or where Understanding and Managing Costs standard or premium data is used and results in costs being incurred. In this use case, there are 11 potential points of expense.

The following figure provides an overlay of where points of expense can occur.

Points of Expense
Figure 3. Points of Expense

results matching ""

    No results matching ""