From messy stadium data to a production-ready pipeline with HERE APIs and AWS Lambda

In previous blog posts, we explored the capabilities of HERE Geocoding & Search API and how to improve the datasets or applications with it. In this blog post, we will try to answer:

What does it take to turn unreliable geospatial data into something your applications can actually trust?

Next, you'll learn how to build a scalable data validation pipeline using AWS Lambda, Amazon S3 and HERE Geocoding & Search API—transforming messy, real-world location data into a clean dataset suitable for a production-ready tour planning application.

Imaginary scenario

The following workshop scenariodemonstrates how a dataset is used in a tour-planning app that calculates an optimized route around ingested points. Because the demonstration dataset contains high-quality location data, the resulting tour looks reasonable, as this uploaded CSV file shows below:

it generates the route:

Take a look at the tour in HERE WeGo. If you experiment with changing the order of stops, the starting point or the destination, you’ll notice that the original result provides an optimized tour based on the supplied stop set and configuration. This creates an efficient overall route with minimized travel time.

This is where our workshop scenario begins: a customer wants to build a Germany-wide tour of football stadiums and provides the location data to display in the tour planning app.

Your app is only as good as your data

Developers often jump straight into building applications but overlook the real bottleneck: data quality.

This is exactly what happened to me—my first attempt was to load the dataset directly into the application, but the application failed:

In many real-world projects, the first dataset you receive is rarely perfect. It may be compiled from multiple systems, contain manual edits, or combine old and new formats. Some values may be missing, entered incorrectly or appear complete while still containing errors.

So, what’s wrong with this dataset?

I opened the dataset to understand the actual issues. The dataset is messy!

Look closer at this file:

• Which row would you trust immediately?

• Which row would you reject?

• Which row would you investigate before accepting?

This is the mindset we need. We are not only filling empty cells. We are deciding which records should be trusted, corrected or reviewed.

Easy fix

Next, I took a practical approach and created a copy of the file, removing all rows with missing latitude and longitude fields. Uploading this modified file immediately revealed several issues that were not obvious at first glance.

A few of the results appeared outside Germany, so the first question I ask myself is: what is wrong with the dataset?

Reviewing the file uncovers several issues:

• Missing coordinates

• Incorrect coordinates

• Swapped latitude and longitude values

• Incomplete or inconsistent location metadata

Before validating the data, let’s pause and ask: what does the application actually require?

At a minimum, the app needs a list of stops, and each stop needs accurate coordinates. Every stop should also have a clear, meaningful name so users can immediately understand what they’re seeing. Ideally, each one includes additional metadata such as city, country, address or other location context.

If that data is wrong, the app may still function—but the results can be misleading. And misleading output is often worse than a visible error. When a system crashes, we know something failed. But when a system produces a polished, confident-looking, incorrect route, users may trust it.

Building the app isn’t the hard part. Trusting the data is.

Defining what the app actually needs

A data contract is simply an agreement that defines what a valid record must contain before another system can use it.

In this example, consuming system is the tour planning app.

So instead of asking, “What data do we have?”, we ask, “What does the application need?”

That is a critical difference. Raw data reflects the structure and limitations of the source system. A data contract reflects the requirements of the target system.

For our app, a production-ready row should include:

• a stadium or point-of-interest (POI) name

• a valid latitude

• a valid longitude

• location metadata such as address, city, country, or administrative area

From there, we can define the validation questions:

• Is the POI actually in Germany?

• Are the coordinates plausible?

• Does the metadata match the expected stadium or team?

• Is the row complete enough for downstream use?

• If the result is ambiguous, should we accept it automatically?

A coordinate field being non-empty does not mean the coordinate is correct.

Using HERE Geocoding & Search API

Now that we know what “good” data looks like, we can decide how to validate or repair each record. That brings us to geocoding and reverse geocoding. Although they sound similar, they solve different problems.

Geocoding turns text into coordinates. Reverse geocoding turns coordinates into location context.

Geocoding is useful when a dataset includes human-readable location information but lacks machine-usable coordinates.

For example, if a file contains “Allianz Arena, Munich, Germany,” a person can immediately understand the location—but an application needs coordinates.

Try the geocoding endpoint of HERE Geocoding & Search API:

https://geocode.search.hereapi.com/v1/geocode?q=Allianz%20Arena,%20Munich,%20Germany&apiKey=

Would you rather geocode “Allianz Arena” or “Allianz Arena, Munich, Germany”?

The answer illustrates an important principle: the quality of the result depends heavily on the quality of the query. A stadium name on its own may be ambiguous. But when you combine it with city and country information, you give the service the context it needs to return the expected result.

When designing data pipelines, it is not enough to simply call an API. How you construct the query has a direct impact on result quality.

Reverse geocoding becomes useful when a dataset already includes latitude and longitude values, but those coordinates cannot be fully trusted.

Try the reverse geocoding endpoint of HERE Geocoding & Search API:

https://revgeocode.search.hereapi.com/v1/revgeocode?at=48.21899563,11.62471026&apiKey=

The response provides a useful validation signal by returning location metadata such as "countryCode": "DEU" and "countryName": "Deutschland". This helps verify whether the coordinates align with the expectation that the stadium is located in Germany.

A practical decision flow might look like this:

• If coordinates are missing, use geocoding.

• If coordinates exist but seem suspicious, use reverse geocoding.

• If the metadata does not match expectations, compare the returned values with the expected values.

• If the results are still ambiguous, flag the record for review.

The key takeaway is simple: calling an API is easy. The real engineering value lies in deciding when to call it, why to trust it, and how to use the result.

AWS enrichment flow and Lambda code

My dataset contains only 19 records, so it is still practical to geocode, reverse geocode and validate the data manually. But what happens when a file contains hundreds or thousands of records—or when datasets are updated automatically and need to be validated immediately?

In those cases, we can design and implement a serverless geospatial validation pipeline that:

• reads raw CSV data from Amazon S3

• enriches missing location data with HERE APIs

• validates existing coordinates

• outputs a clean, review-ready dataset

The pipeline follows a simple but powerful flow:

S3 (Input CSV)

↓

AWS Lambda

↓

HERE Geocoding & Search API (/geocode)

↓

HERE Geocoding & Search API (/revgeocode)

↓

Validation Engine

↓

S3 (Clean Output CSV)

Running the file through the pipeline produces a validated dataset that is ready for downstream use and visualization in the tour planning app.

Review the full Lambda function here.

This pattern applies far beyond stadiums:

• Logistics and fleet management

  • Validate delivery locations

  • Ensure accurate routing inputs

• Retail and site selection

  • Clean POI datasets before analysis

• Mobility and navigation

  • Improve address accuracy for better ETAs

Conclusion

What began as a simple effort to visualize a dataset in a tour-planning app quickly revealed a deeper truth: data reliability is the foundation of every location-based application.

Along the way, we moved beyond the assumption that non-empty fields equal correct data and adopted a more critical mindset—questioning, validating and enriching each record before trusting it.

By combining the geocoding and reverse geocoding capabilities of the HERE Geocoding & Search API with a lightweight serverless architecture on AWS, we turned a messy, inconsistent dataset into a clean, production-ready data product.

APIs do not solve data problems on their own. Your validation logic does.

When you define a clear data contract, apply the right enrichment strategy, and automate validation through services like AWS Lambda and Amazon S3, you move from reactive data cleanup to proactive data engineering.

And this pattern extends well beyond the workshop scenario. Whether you are building logistics platforms, mobility applications or analytics systems, the same principle holds: trusted data enables trusted decisions.