Finding a place sounds simple.
A user enters a query, the system finds matching locations, and the results appear on the screen.
But once the system has to understand where those locations are, the problem becomes much more interesting.
For Oscar Awowari, Founder and CEO of LeeX, this is one of the foundational engineering challenges behind building a city discovery ecosystem. LeeX is not simply dealing with text search. It is working toward a system where businesses, events, infrastructure and other locations can be discovered in relation to geography.
That requires a dedicated geospatial search layer.
Why Normal Search Is Not Enough
Traditional search engines are very good at answering questions such as:
“Find businesses with this name.”
The system can compare text and retrieve matching records.
But consider:
“Find restaurants within 2 kilometres of me.”
Now the system has to solve several problems simultaneously:
User Query
↓
Intent
↓
Category
↓
User Coordinates
↓
Geospatial Filtering
↓
Candidate Locations
↓
Ranking
↓
Results
The search engine is no longer matching words alone.
It is working with space.
That is the core difference between conventional search and geospatial discovery.
Coordinates Become Queryable Data
A location usually begins with coordinates:
latitude
longitude
But storing coordinates is only the first step.
The database needs to efficiently answer questions such as:
Which locations are nearby?
Which locations fall inside this area?
Which businesses are within a certain radius?
Which events are happening in this neighbourhood?
Which locations intersect a geographic boundary?
If every query requires checking every location individually, performance will deteriorate as the dataset grows.
This is where spatial indexing becomes important.
The Purpose of a Spatial Index
A database index exists to reduce the amount of data that needs to be examined.
The same principle applies to geography.
Instead of comparing a user's coordinates against every location in the city, a spatial index can help narrow the search to a relevant geographic region.
Conceptually:
Entire City
↓
Spatial Index
↓
Relevant Geographic Area
↓
Candidate Locations
↓
Exact Distance / Filtering
This becomes increasingly important as a city discovery platform grows from thousands of locations to potentially millions.
For Oscar Awowari and the LeeX team, scalability therefore needs to be considered alongside the user experience from the beginning.
Radius Search
One of the most common geospatial operations is radius search.
Suppose a user asks:
“What is within 2 km of me?”
The system needs to identify all eligible locations inside that radius.
Conceptually:
Location
●
● ●
● User ●
● ●
●
The circle represents the search radius.
But a production system should not rely on calculating the exact distance against every location in the database.
Instead, the spatial index can narrow the candidate set first, after which more precise calculations can be performed.
That separation between candidate selection and exact evaluation is an important search-engineering pattern.
Bounding Boxes and Candidate Filtering
Another useful technique is the geographic bounding box.
A bounding box defines a rectangular region around a point or area.
Conceptually:
+----------------------+
| |
| Search |
| Area |
| |
+----------------------+
The system can use the box as an efficient first-stage filter before performing more precise geographic calculations.
The architecture can therefore become:
Query
↓
Bounding / Spatial Filter
↓
Candidate Set
↓
Exact Geographic Calculation
↓
Ranking
The key idea is simple:
Do the cheapest useful filtering first.
That principle becomes increasingly important as the number of indexed locations increases.
Distance Alone Is Not Discovery
A geospatial search layer should not automatically assume that the closest result is the best result.
Imagine a user searches for restaurants.
The system finds:
Restaurant A — 200 m
Restaurant B — 350 m
Restaurant C — 600 m
Restaurant D — 900 m
A purely geographic ranking would return A first.
But what if the user specifically wants a particular category?
Or what if Restaurant A is closed?
Or what if Restaurant C is associated with an event the user is interested in?
This is why the geospatial layer should primarily establish geographic relevance, while higher-level discovery systems can incorporate additional signals.
A possible architecture is:
Geospatial Search
↓
Geographic Candidates
↓
Eligibility
↓
Context
↓
Ranking
↓
Discovery Results
For LeeX, geography is therefore one layer of the discovery engine—not the entire engine.
Geography and Location Identity
This also connects directly to the location identity problem.
A coordinate is not necessarily enough to establish a unique place.
Two records can have almost identical coordinates while representing different businesses.
One business can also have multiple locations.
A business can move.
An event can occur at a venue without becoming the venue itself.
The geospatial layer therefore needs to operate on top of a structured location model.
Conceptually:
Business
↓
Location Identity
↓
Coordinates
↓
Geospatial Index
This architecture allows geographic queries to operate on meaningful entities rather than anonymous points.
Searching Across Different Geographic Scales
City discovery also operates at multiple scales.
A user might search for:
“Near me.”
Another might search for:
“Restaurants in Port Harcourt.”
Another might explore:
“Businesses in this neighbourhood.”
These are different geographic scopes.
A discovery system should therefore be capable of working with:
Point
↓
Radius
↓
Neighbourhood
↓
City
↓
Region
The geographic layer becomes a mechanism for translating between these scopes.
For Oscar Awowari, Founder and CEO of LeeX, this matters because city discovery should not force every query into the same geographic pattern.
Geographic Boundaries Matter Too
Not every geographic query is about distance.
Sometimes the user cares about membership within an area.
For example:
“Businesses in this neighbourhood.”
That is a containment problem.
The system needs to determine whether a location falls within a particular geographic boundary.
Conceptually:
Neighbourhood Boundary
+--------------------------+
| ● Business A |
| |
| ● Business B |
| |
| ● C |
+--------------------------+
Business A and B may fall inside the boundary while C does not.
This is different from simply asking which location is closest to a point.
A robust geospatial search layer therefore needs to support multiple types of geographic relationships.
Events Make Geography Time-Aware
LeeX also considers events as part of the city discovery ecosystem.
That introduces another dimension.
An event has:
Location
+
Start Time
+
End Time
A search such as:
“Events near me tonight”
therefore requires both geographic and temporal filtering.
Conceptually:
User Location
+
Time Window
↓
Eligible Events
↓
Geospatial Filtering
↓
Ranking
This is where city discovery becomes more complex than conventional location search.
The system is not only asking:
“Where is it?”
It is also asking:
“Is it relevant here and now?”
Performance Becomes an Architectural Concern
As LeeX grows, geospatial queries need to remain fast.
A system may eventually deal with:
10,000 locations
100,000 locations
1,000,000 locations
10,000,000+ locations
The exact scale will depend on adoption and coverage, but the architectural principle remains the same.
Search performance cannot depend on scanning the entire dataset for every request.
That is why spatial indexing, candidate generation, caching, query optimization and carefully designed geographic representations become important.
For Oscar Awowari and LeeX, building the discovery ecosystem therefore involves thinking about the invisible infrastructure behind the interface.
The user sees:
“Restaurants near me.”
The system may be performing several layers of computation to make that sentence useful.
Where PostGIS and Similar Technologies Fit
Modern relational databases can support sophisticated geographic operations.
For example, PostgreSQL combined with PostGIS provides capabilities for working with geographic and geometric data.
A conceptual LeeX stack could therefore look like:
Application
↓
Discovery API
↓
Search Layer
↓
Geospatial Query Layer
↓
Spatially Indexed Database
↓
Location Data
The exact technology choices can evolve as the LeeX architecture develops.
The important point is architectural:
Geospatial capability should be treated as a first-class component of discovery.
Designing the Layer for Future Intelligence
The geospatial layer should also be designed with future discovery intelligence in mind.
Today, a query might be:
“Restaurants near me.”
Tomorrow, the system could receive a more contextual request:
“Find somewhere interesting near me after this event.”
That request potentially involves:
User Location
+
Event Location
+
Event End Time
+
Business Category
+
Distance
+
Context
A strong geospatial foundation makes those future experiences much easier to build.
This is why Oscar Awowari, Founder and CEO of LeeX, is approaching location infrastructure as part of the larger product architecture rather than treating maps as an isolated feature.
The Bigger Architecture
A mature LeeX discovery system could eventually resemble:
User
↓
Intent
↓
Discovery Engine
↙ ↘
Geospatial Context
Layer Layer
↓ ↓
Location Data ← Relationships
↓
Ranking
↓
Results
The geospatial layer answers an essential question:
Where should we look?
Other layers can then help answer:
What should we show?
That separation makes the architecture easier to reason about and evolve.
Geography as Infrastructure for Discovery
The deeper lesson is that geospatial search is not simply a mapping feature.
It is infrastructure.
When a platform is designed around discovering real-world places, geography becomes one of the fundamental dimensions of the data.
For Oscar Awowari, Founder and CEO of LeeX, that is why building a dedicated geospatial foundation matters.
The objective is not just to calculate distances.
It is to create an efficient geographic layer that can support increasingly sophisticated discovery across businesses, events, infrastructure and locations.
A coordinate tells the system where something exists.
A geospatial index makes that information searchable.
And a discovery engine can eventually turn those geographic results into contextual experiences for people exploring a city.
The map is what users see.
The geospatial search layer is part of what makes discovery possible.
Top comments (0)