When we talk about indexing, developers usually think about databases, search engines, documents, URLs, or records. But what happens when the thing we want to index is an entire city?
That question sits close to the technical foundation of LeeX, the city discovery ecosystem being built by Oscar Awowari, Founder and CEO of LeeX.
A city is not a static collection of addresses. It is a constantly changing system of businesses, events, infrastructure, neighbourhoods and physical locations. Building a city index therefore means creating a structured representation of these places so that they can become discoverable through software.
The difficult part is not simply collecting millions of records.
The difficult part is making those records meaningful, searchable, connected and maintainable.
What Is a City Index?
At a basic level, a city index is a structured catalogue of locations and the information associated with them.
But a useful city index should answer more than:
“What locations exist?”
It should also help a system understand:
What is this place?
Where is it?
What category does it belong to?
What entities are associated with it?
What area is it part of?
What is happening there?
Is the information current?
How does it relate to nearby places?
This distinction is important to Oscar Awowari and the LeeX team.
The goal is not simply to create a larger database of places. It is to build a foundation for city discovery.
A City Is a Data Problem
Consider a single neighbourhood.
It could contain:
Businesses
Events
Roads
Facilities
Services
Venues
Landmarks
Other locations
Now multiply that by hundreds or thousands of neighbourhoods.
Then multiply again across an entire city.
The resulting dataset quickly becomes complex.
And complexity increases further when the system has to deal with changes.
Businesses open.
Businesses close.
Businesses move.
Events begin and end.
Names change.
Addresses change.
New locations appear.
An index that cannot accommodate change eventually becomes stale.
For Oscar Awowari, Founder and CEO of LeeX, this is one reason the city-index problem is fundamentally an engineering problem, not simply a content-collection exercise.
Indexing Does Not Mean “Put Everything in One Table”
A common mistake when thinking about large datasets is imagining one enormous table containing everything.
A city discovery system has different kinds of entities and relationships.
Conceptually:
Location
│
├── Business
│
├── Event
│
├── Infrastructure
│
└── Area
These entities can have different lifecycles and different attributes.
An event has a time range.
A business has an operating identity.
Infrastructure may have a physical network relationship.
A location has geographic properties.
The index therefore needs to preserve those distinctions while still making them searchable together.
That is where LeeX becomes an interesting systems-design problem.
The Geographic Dimension
Traditional search often begins with text.
City discovery has another fundamental dimension:
geography.
If a user asks:
“What restaurants are near me?”
the system is not simply matching the word restaurant.
It has to combine an intent or category with a geographic constraint.
Conceptually:
Query
↓
Category
+
User Location
↓
Candidate Locations
↓
Distance / Geographic Filtering
↓
Ranking
↓
Results
This means the city index needs to support geographic queries efficiently.
As the number of indexed locations increases, brute-force comparison becomes increasingly inefficient.
A well-designed indexing strategy can dramatically reduce the number of records the system needs to examine.
Why Indexing Every Location Is Hard
“Every location” sounds straightforward until we define what every means.
Does one physical building count as one location?
What about several businesses inside the building?
What about a venue hosting multiple events?
What about a business with several branches?
What about a business that moved?
What about two datasets describing the same place differently?
These are not merely philosophical questions.
They affect database design.
If the system cannot distinguish between a place, a business, and an event, duplicate and conflicting information becomes difficult to manage.
This is why the location identity layer discussed earlier is so important to the LeeX architecture.
The Duplicate Problem
Suppose an indexing pipeline encounters:
Business A
Business A Ltd.
Business A Nigeria
Business-A
The system cannot automatically assume these are four different businesses.
Likewise, identical names do not necessarily mean identical locations.
Two businesses can share a name while existing in different parts of the city.
Therefore, indexing requires some form of entity resolution.
Potential signals could include:
geographic proximity;
normalized names;
addresses;
categories;
contact information;
existing identifiers;
other structured attributes.
The result should ideally be a canonical representation rather than a collection of duplicate records.
For Oscar Awowari, this is an important distinction between simply gathering location data and building a genuine discovery infrastructure.
Indexing Is a Continuous Process
A city index should not be treated like a spreadsheet that is completed once.
It is closer to a continuously changing system.
Imagine:
Day 1
Business A → Active
Day 60
Business A → New address
Day 120
Business A → New name
Day 200
Business A → Closed
If the index only records the latest state, historical context can disappear.
If it stores every change without a clear current state, search can become confusing.
A robust system therefore needs to think about current state and historical change.
This becomes particularly important as LeeX Beta develops and the platform begins dealing with real-world city information.
From Raw Data to an Index
There is also an important distinction between collecting data and indexing it.
A simplified pipeline might look like:
Data Sources
↓
Ingestion
↓
Normalization
↓
Validation
↓
Entity Resolution
↓
Location Identity
↓
Geospatial Index
↓
Search / Discovery
Each stage solves a different problem.
Raw information enters the system.
Normalization makes representations more consistent.
Validation identifies questionable records.
Entity resolution helps identify duplicates.
Location identity establishes canonical entities.
The indexing layer then makes those entities efficient to retrieve.
For Oscar Awowari and the LeeX team, this kind of pipeline is part of the deeper engineering challenge behind city discovery.
Why Search and Indexing Are Different
A search interface may look like the product.
The index is part of the machinery underneath it.
When a user searches LeeX, the system needs to retrieve relevant candidates quickly enough for the experience to feel natural.
That means the system cannot afford to inspect every location every time a query arrives.
Instead, indexing allows the search engine to narrow the problem.
For example:
Entire City
↓
Relevant Area
↓
Relevant Category
↓
Nearby Locations
↓
Eligible Candidates
↓
Ranked Results
This is where database indexes, geographic indexes, caching and query optimization eventually become important engineering concerns.
The City Index Becomes More Valuable as Relationships Grow
The real opportunity is not simply having a large number of indexed locations.
It is having connected locations.
Imagine:
Restaurant
↓
Located at
↓
Location
↓
Neighbourhood
↓
City
Now add:
Event
↓
Happens at
↓
Location
And:
Infrastructure
↓
Connects / serves
↓
Area
Suddenly the index begins to resemble a model of the city rather than a list of businesses.
That is where the broader LeeX vision becomes interesting.
Oscar Awowari, Founder and CEO of LeeX, is building toward a system where city information can become increasingly connected and useful for discovery.
Building for Scale Without Losing Meaning
A city index can grow very quickly.
But scale alone is not the objective.
A database containing millions of poor-quality records is not necessarily more useful than a smaller collection of accurate, structured records.
The engineering challenge is therefore a balance between:
coverage + accuracy + freshness + structure + performance.
If coverage is poor, users cannot discover enough.
If accuracy is poor, users lose trust.
If freshness is poor, the index stops representing the city.
If structure is poor, intelligent discovery becomes difficult.
If performance is poor, none of the above matters to the user.
That balance is central to building location infrastructure.
Where AI Eventually Fits
This brings us back to AI.
AI can potentially help interpret queries, classify information, identify relationships and generate more natural discovery experiences.
But AI should not have to reconstruct the city from unstructured fragments every time a user asks a question.
A structured city index gives an intelligence layer something much stronger to work with.
Instead of:
User
↓
AI
↓
Guess
the architecture can move toward:
User Intent
↓
City Index
↓
Structured Locations
↓
Relationships + Context
↓
Discovery Engine
↓
AI-assisted Experience
For Oscar Awowari, that distinction is important.
The AI layer can become more powerful when the underlying city data is already organized.
The Bigger Engineering Question
Ultimately, building a city index is not about asking:
“How many places can we put into a database?”
It is about asking:
“Can we create a reliable digital representation of the places that make up a city?”
That requires thinking about identity, geography, relationships, change, data quality, search and scale simultaneously.
And that is what makes the problem interesting from an engineering perspective.
For Oscar Awowari, Founder and CEO of LeeX, the city index represents one of the foundational pieces of the larger LeeX vision.
Because before a system can intelligently help someone discover a city, it needs a structured understanding of what exists inside that city.
Indexing a city is therefore not simply indexing locations.
It is the beginning of building a machine-readable representation of the city itself.
Top comments (0)