A location platform can look remarkably simple from the outside.
A user searches for a business, sees a result, checks the location and decides whether to visit. The interface may contain only a name, address, category and map.
Behind that apparently simple experience, however, is a much harder engineering problem:
Can the platform trust the information it is showing?
For Oscar Awowari, Founder and CEO of LeeX, this question is fundamental to building a reliable city discovery ecosystem. LeeX is being developed around businesses, events, infrastructure and locations, which means the quality of the underlying information directly affects the quality of discovery.
A beautiful interface cannot compensate for bad location data.
Location Data Is Not Static
One of the biggest misconceptions about location platforms is that once a place has been added to a database, the job is finished.
Real cities do not work that way.
Businesses open.
Businesses close.
Addresses change.
Businesses relocate.
Names change.
Categories change.
Events begin and end.
New places appear.
Old information becomes inaccurate.
A location platform therefore has to deal with a continuously changing environment.
Conceptually:
Real World
↓
Location Data
↓
Discovery Platform
The problem is that the real world keeps changing while the database only changes when its information is updated.
That gap is where data quality problems begin.
The Wrong Address Problem
Imagine discovering a restaurant online, travelling to the listed address and finding an empty building.
The problem is not the search engine.
The search engine may have successfully found the record.
The problem is that the record no longer represents reality.
For a city discovery platform, this distinction is critical.
A location can be:
Accurate
Outdated
Incomplete
Duplicated
Incorrect
Unverified
These states can produce very different user experiences.
For LeeX, data quality therefore needs to be treated as part of the discovery infrastructure rather than something that can be addressed only after the search system has been built.
More Data Does Not Automatically Mean Better Data
Suppose a platform has one million location records.
That sounds impressive.
But what if:
100,000 are duplicates?
50,000 have outdated information?
thousands have incorrect coordinates?
many lack categories?
some businesses are permanently closed?
The platform may have extensive coverage while still providing an unreliable experience.
This creates an important engineering principle:
Data volume and data quality are different metrics.
A useful city index needs both.
Duplicate Locations
Duplicates are particularly difficult because they can look legitimate.
A business might appear as:
Example Restaurant
Example Restaurant Ltd.
Example Restaurant PH
Example Rest.
These records might represent:
the same business;
different branches;
historical versions;
or completely unrelated businesses with similar names.
A discovery platform needs mechanisms for determining when multiple records represent the same real-world entity.
This is where entity resolution and location identity become important.
The goal is to establish a canonical representation while preserving useful information from the different records.
Coordinates Can Be Wrong Too
Even when a location has geographic coordinates, those coordinates may not accurately represent the intended place.
A pin might be:
several metres away;
placed at the wrong building;
attached to the wrong branch;
located at a general address rather than the actual entrance;
or completely unrelated to the business.
This matters because geographic discovery depends on those coordinates.
If the underlying location is wrong, then:
Geospatial Search
↓
Wrong Candidate
↓
Wrong Result
A technically perfect geospatial query can still return a bad answer if the underlying data is inaccurate.
That is why Oscar Awowari and the LeeX team have to think about data quality before treating location search as a purely technical indexing problem.
Missing Data Is Also a Quality Problem
Bad data is not always incorrect data.
Sometimes the problem is that important information is missing.
A location might have:
Name ✓
Coordinates ✓
Category ✗
Status ✗
Address ✗
The record technically exists.
But its usefulness is limited.
Missing information can also affect ranking.
If the system does not know whether a location belongs to a particular category, it becomes harder to determine whether it should appear for a category-specific query.
This means completeness is another dimension of data quality.
Freshness Matters
A location record can be completely accurate when it is created and become inaccurate months later.
That creates another useful concept:
data freshness.
For example:
January
Business → Open
June
Business → Open
September
Business → Closed
If the database still says “Open” in December, the information may have been correct historically but is incorrect for the present.
A city discovery system therefore needs to think about both:
accuracy and recency.
For LeeX, this becomes particularly important because businesses, events and other city entities do not all change at the same speed.
Events Create an Additional Challenge
Events are especially sensitive to freshness.
A business might exist for years.
An event may exist for only one day.
Consider:
Event
Start: Friday
End: Saturday
Once Saturday passes, the event should not continue appearing as though it were an upcoming discovery opportunity.
This introduces time-aware data management.
The system needs to understand not only:
“Where is this?”
but also:
“When is this information valid?”
That makes event discovery a different data-quality problem from permanent business locations.
Data Quality Affects Ranking
Poor data quality does not only affect whether a result exists.
It can affect which result appears first.
Imagine two businesses:
Business A
Distance: 500m
Status: Unknown
Business B
Distance: 700m
Status: Active
If the discovery engine only considers distance, Business A may rank higher.
But if Business A is closed or poorly verified, that ranking could create a bad user experience.
This demonstrates why ranking and data quality cannot be completely separated.
A discovery engine needs reliable signals before it can make reliable decisions.
A Possible Data Quality Pipeline
A location platform can treat data quality as an ongoing pipeline rather than a one-time cleanup exercise.
A simplified architecture could look like:
Incoming Data
↓
Normalization
↓
Validation
↓
Duplicate Detection
↓
Entity Resolution
↓
Location Verification
↓
Canonical Record
↓
Discovery Index
Each stage addresses a different problem.
Normalization makes representations consistent.
Validation checks whether information satisfies expected rules.
Duplicate detection identifies potential overlaps.
Entity resolution determines whether records represent the same entity.
Verification provides another layer of confidence.
The result is a stronger dataset for discovery.
Confidence Can Become a Data Attribute
Another interesting approach is to represent confidence explicitly.
Instead of treating every location record as equally reliable, the system could conceptually maintain something like:
Location
├── Identity
├── Coordinates
├── Category
├── Status
└── Confidence
A confidence score does not magically make information accurate.
But it gives downstream systems another signal.
A highly confident record could potentially be treated differently from a newly discovered and unverified record.
For Oscar Awowari, Founder and CEO of LeeX, this kind of structured thinking can become important as the platform's location index grows.
Human Verification Still Has a Role
Automation can identify suspicious records.
It can detect duplicates.
It can flag unusual coordinates.
It can compare attributes.
But some real-world ambiguities are difficult to resolve automatically.
A platform may therefore benefit from human-in-the-loop verification for selected cases.
Conceptually:
Automated Detection
↓
Potential Problem
↓
Confidence / Priority
↓
Human Review
↓
Verified Record
The objective is not to manually review every location.
That would not scale.
Instead, automation can identify the records where human attention is most valuable.
Data Quality Should Be Measurable
If data quality is treated as infrastructure, it needs measurable indicators.
A location platform could eventually monitor metrics such as:
Completeness — How much required information is present?
Freshness — How recently was the record verified or updated?
Duplication rate — How many records may represent the same entity?
Accuracy — How reliable are the geographic and descriptive attributes?
Verification coverage — What proportion of records have stronger verification?
These metrics can provide a clearer picture of whether the city index is actually improving.
Why This Matters for LeeX
The broader LeeX vision depends on structured information about the real world.
If the underlying information is unreliable, every layer above it inherits the problem.
Poor Data
↓
Poor Index
↓
Poor Search
↓
Poor Ranking
↓
Poor Discovery
But the reverse is also true.
Better Data
↓
Better Index
↓
Better Search
↓
Better Ranking
↓
Better Discovery
This is why Oscar Awowari and LeeX cannot treat data quality as a secondary concern.
It is part of the product.
AI Does Not Eliminate the Problem
There is also an important lesson for AI-powered discovery.
An AI system can summarize information.
It can interpret queries.
It can classify entities.
It can potentially help detect duplicates or anomalies.
But AI does not automatically make incorrect information correct.
If the underlying location record is wrong, an AI system can potentially produce a more convincing explanation of the wrong information.
That makes data quality even more important in an AI-enabled discovery architecture.
For Oscar Awowari, Founder and CEO of LeeX, the goal should therefore be to build the structured information layer first and allow intelligence systems to operate on top of increasingly reliable data.
The Invisible Part of a Great Discovery Experience
Users rarely think about data quality when everything works.
They search for a place.
They find it.
They go there.
The experience feels effortless.
But that simplicity is supported by many invisible systems:
Identity
↓
Validation
↓
Freshness
↓
Geospatial Accuracy
↓
Indexing
↓
Ranking
↓
Discovery
The user sees the final result.
The engineering team has to build everything underneath it.
That is what makes location data quality such an important—and often overlooked—problem.
Building Trust Into the City Index
For Oscar Awowari, Founder and CEO of LeeX, the long-term challenge is not simply creating a large database of places.
It is building a city index that people can increasingly trust.
That means asking difficult questions about every layer of the data:
Is this the right place?
Is this the right entity?
Is this information complete?
Is it current?
Is it duplicated?
How confident are we?
Those questions may not appear in the final user interface, but they can determine whether the discovery experience succeeds.
A location platform ultimately has to represent the real world.
And the real world is messy.
The hardest part of location discovery may not be finding places.
It may be making sure that the places we find are actually the places that exist.
Top comments (0)