How to Build Road Segments from HERE Traffic API Response with FME

Introduction

In previous posts, we explored the HERE Traffic API and how to construct live traffic requests. In this article, we will walk through how to transform traffic data into geospatial line features using FME. This workflow is especially useful for developers and GIS professionals who want to visualize traffic flow, congestion, or incidents in a spatial context. It’s designed to be a practical reference you can return to for future projects.

Workflow Overview

Here is a walkthrough of FME Workbench that performs the following steps:

Step 1: Creator

The workflow begins with a Creator transformer, which initializes the process. This is typically used to trigger the workflow without requiring an input dataset.

Step 2: Connecting to the HERE Traffic API

To retrieve live traffic data, we use FME’s HTTPCaller transformer. This sends a request to the HERE Traffic API, which returns a JSON object containing traffic flow information.

Behind the scenes:

• A

  GET request

  is sent to the HERE API, targeting a circular area around a specific location.

• The response is stored in an attribute called response_body, which we’ll use in the next steps.

Note: You’ll need an API key from the HERE Platform to access the traffic data.

Tip: Use FME’s Inspector to explore the raw JSON response and better understand the structure of the data.

Step 3: Breaking Down the JSON Response

Once we receive the traffic data from the HERE API, it arrives as a large JSON object. To work with it in FME, we use the JSONFragmenter transformer.

Here’s what it does:

• It takes the full JSON response stored in _response_body.

• It uses a query (json[*][*]) to break the data into smaller, manageable pieces - each representing a traffic segment or data point.

• These fragments are kept in JSON format so we can extract specific values later.

• If a fragment doesn’t contain usable data, it’s automatically rejected to keep the workflow clean.

Step 4: Extracting Key Values from the JSON

After breaking the JSON into fragments, we use the JSONExtractor transformer to pull out the specific data needed to build our geospatial features.

Here’s what we extract from each traffic segment:

• description

  – A textual description of the location

• length

  – The length of the road segment

• shape_links

  – The raw coordinate points that define the shape of the segment

• speed

  – The current speed of traffic

• speedUncapped

  – The uncapped speed value

• freeFlow

  – The expected speed under free-flow conditions

• jamFactor

  – A value indicating congestion level

• confidence

  – The confidence level of the traffic data

• traversability

  – Indicates whether the segment is traversable

These attributes are extracted using JSON path queries from the response_body attribute, which holds the original API response.

An example of original JSON response viewed in the browser below:

Tip: You can inspect the original JSON response using FME’s Inspector to better understand the structure and verify your queries.

This step is crucial for isolating the data we’ll use to build geometries and enrich the final output with traffic metadata. Each Target Attribute in the JSONExtractor is mapped to a specific field in the JSON structure using the JSON Query field.

Step 5. Building and Assembling the WKT LineString

Now that we’ve extracted the raw coordinates from the HERE Traffic API response, we need to convert them into usable geospatial lines. The coordinates are nested under shape.links[*].points[*] and look like this:

{ "lat": 37.80131, "lng": -122.42466 }

To turn these into a WKT LINESTRING, we follow a two-part process:

Part 1. Cleaning and Reformatting Coordinates

A series of StringReplacer transformers are used to:

• Remove labels like lat: and lng:

• Strip out unnecessary punctuation

• Reformat the coordinates from (lat, lng) to (lng lat) — the format required by WKT

In StringReplacer_10 I use regex as suggested in FME Community

Text to replace: (\d+\.\d+),(-\d+\.\d+)(,*)

This pattern matches:

• (\d+\.\d+) → A positive decimal number (latitude), e.g., 37.80131

• , → A comma separating lat and lng

(-\d+\.\d+) → A negative decimal number (longitude), e.g., -122.42466

Note: This regular expression matches a negative decimal number, such as -122.42466, which is typical for longitude values in the Western Hemisphere (e.g., San Francisco). If you're working with global data - including regions with positive longitudes or latitudes- you'll need to make the minus sign optional. (-?\d+\.\d+),(-?\d+\.\d+)(,*)

• (,*) → Optionally, any trailing commas

Replacement text: \2 \1\3

This rearranges the match into:

• \2 → The longitude (second capture group)

• \1 → The latitude (first capture group)

• \3 → Any trailing commas (third capture group)

It flips the coordinate order from 37.80131,-122.42466 to -122.42466 37.80131 This is the correct format for WKT LineStrings, which require coordinates in the order: longitude latitude.

Part 2. Assembling the WKT Line

The cleaned coordinate pairs are passed into an AttributeManager.

There, we wrap the sequence in a WKT expression like:

LINESTRING(@Value(shape_links))

This creates a valid WKT geometry string such as:

LINESTRING(-122.42466 37.80131, -122.4251 37.80126, -122.42523 37.80124)

This WKT string is then ready to be converted into a real geometry using the GeometryReplacer in the next step.

Step 7: Creating Geometry from WKT

After building the WKT LineString, we use the GeometryReplacer transformer to turn that text into an actual geometry object that FME can work with.

• It reads the WKT string and converts it into a spatial line feature.

• This step is what makes the data “mappable” in FME or any GIS platform.

Step 8: Setting the Coordinate System

Next, the CoordinateSystemSetter ensures that the new geometry has the correct spatial reference.

• This is important for aligning the traffic lines with other map layers.

• You can set it to a standard coordinate system like WGS 84 (EPSG:4326), which is commonly used for web maps and GPS data.

Conclusion: From API to Map

The final result of this FME workflow is a clean, visual representation of traffic flow data of San Francisco. Each line corresponds to a traffic segment retrieved from the HERE Traffic API, processed through a series of transformations, and converted into geospatial features.

In the attribute table, we can see the original JSON responses preserved alongside the generated geometries, making it easy to trace each visual element back to its source data.

This workflow demonstrates how powerful and flexible FME can be for turning raw API responses into actionable, mappable insights.

Happy coding and see you in the next one!