Sample use case: Map enrichment

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

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 through my application
  • Daily, to provide map updates to my fleet of vehicles using 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 shows a solution workflow consisting 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 for evaluating the needs of this specific example use case, and determining critical sizing inputs (usually done by a Solution Architect). The pricing rates for estimating your costs are described in HERE Base Plan Pricing.

Business use case details
  1. Volume of data per day (GB) observations entering the system
    1. This indicates the amount of data which is stored and processed.
  1. Number of updates per day (Count), both archived and updated to the reporting application
    1. This information indicates how many times per day this data is stored and processed for the reporting application.
  1. Number of tiles at a specific zoom level (Zoom Level 9) to create a reasonably sized map update which can be sent to vehicles over a mobile network
    1. Typically, a reasonable vehicle driving area would be represented by hundreds of KBs to MBs 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 determines the throughput which can be processed, such as the size the of messages entered into the system. More messages require more CPU.
    2. (1) and (5) designate the size and number of messages.
Technical recommendations
  1. Determine number of partitions targeting MB range partitions, as 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, which can load different parts of the map to different processing nodes, and are based on HEREtile.
    2. Partition by time to easily manage 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 data, clusters data, 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 costs are 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 ""