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