A fictional museum operates a traveling display that visits schools, libraries and community halls. A visitor searches for the nearest upcoming exhibit, but the database has both current stops and last year’s itinerary. Azure AI Search supports geo-spatial queries through geo.distance and geo.intersects. Those functions can find indexed coordinates, not confirm that a display is operating, that an accessible entrance is open, or that the visitor has permission to view a private event. A reliable listing must join location math with verified event metadata.
Treat a stop as an event, not just a point
Create a dedicated record for each scheduled appearance: stable event ID, venue ID, latitude and longitude, event date, time zone, public status, accessibility note and source revision. One library can host many events with different entry rules. Avoid making the building itself synonymous with a currently open display. A geo-filter against a stale location index could return a nearby stop that ended months ago.
For the example, imagine a community hall used last spring and a library hosting the display next week. Both have plausible coordinates, but only the second should appear for the requested date and public audience. Record which staff member approved the schedule and how updates propagate to the search index. Keep internal setup appointments separate from public hours so an apparently relevant geospatial result never becomes an invented invitation.
Index location in the correct geography type
Azure AI Search describes Edm.GeographyPoint and Collection(Edm.GeographyPoint) as geo-spatial field types. Set the location field to be filterable and confirm it contains a valid point before indexing. Store event dates and visibility classifications as separate filterable fields. If coordinates are missing or come from an unverified spreadsheet, do not substitute zeros or a guessed city center; route those records to a data-quality queue.
Validate coordinate ranges and the original geocoding source. A longitude and latitude reversal can place a valid-looking point in the wrong area; unit tests should detect the reversal rather than silently swap it during display. Store a venue’s approved address independently of its point to support human checking. A map pin is a locator, not evidence of a physical accessible entrance, a route or real-time opening.
Write an explicit distance filter
The documented OData expression uses geo.distance(Location, geography’POINT(longitude latitude)’) le radius. The function returns kilometers, not miles or meters. It takes a field point and a point literal; use the same field naming and API version that your actual index supports. Combine the radius clause with an event-date and published-status filter, and never let distance alone determine public visibility.
The example below is conceptual: a five-kilometer radius around a fictional visitor coordinate produces a candidate list that still needs a verified schedule. Use inclusive le for a boundary that should count and confirm behavior on the exact radius. When sorting by distance, the geography field must also be sortable. Write separate tests for missing locations, time zones and just-canceled appearances; don’t claim a driving or walking ETA from straight-line distance.
Use geo.intersects only for genuine boundaries
Azure also documents geo.intersects for testing whether a point falls within a specified polygon. A municipal arts district may be represented as an approved boundary rather than as a radius around one building. Validate the polygon geometry, coordinate order and source of its boundaries. The filter does not know whether a road is closed, a bridge is inaccessible or a venue is outside a visitor’s preferred travel mode.
For a program that changes districts each season, keep boundary revisions alongside event schedules. Test a stop exactly on the edge and confirm how the UI explains the result. Do not infer that an event is officially associated with a district simply because its location is inside a drawn shape. An operational claim should come from the program administrator, not from the shape’s geometry.
Compare wrong coordinates, stale stops and correct listings
A diagram can show an exhibit pin misplaced because the point’s axes were reversed. A second panel can show the correct map position paired with an event that has already ended. The reviewed panel should contain the published stop for the requested date, with its address and accessibility details verified against source records. These are synthetic examples, not a screenshot of Azure results.
Visual comparisons should make the errors obvious through different pin positions, canceled markers and document dates—not fabricated kilometer measurements. Relevance ranking and geo filtering solve different problems. Even when a result is inside the radius, the application should say ‘schedule unverified’ rather than ‘open now’ if it cannot obtain a current authoritative event record.
Apply permissions before presenting results
An educational organization may run public exhibits and private school visits from the same index. Filter for an authorized audience in addition to spatial and temporal criteria. Protect coordinates or access notes for restricted events, and ensure the API that supplies map pins enforces the same visibility rules as the search UI. A hidden result can still leak through counts, suggestions or a debugging endpoint if those paths lack filters.
Never use the user’s search location as permission to access other patrons’ bookings. Avoid storing precise visitor coordinates longer than necessary for a lookup, and explain what the application logs. Consider a broad location choice rather than collecting street-level data by default. Search is not an identity verification product, so authentication and visibility controls must live in the surrounding application and data pipeline.
Audit edge cases before launch
Create synthetic tests for reversed longitude and latitude, kilometer-versus-mile confusion, a canceled stop, a closed entrance, a future event in a different time zone, a missing location and an invited-only venue. Verify the response by checking both the underlying index record and the public schedule. A distance filter returning the expected number of records is not enough if one record is restricted.
Human QA should compare the stop name, address, event time, source revision and accessibility note with the approved calendar. Keep a clear exception path for disagreements between a library website and a promotional poster. If a visitor asks for travel time, use an actual routing service or avoid making an ETA claim. The diagrams in this article model validation gates; no live Azure index was queried.
Publish an honest nearby-events answer
Show the location and date of each verified event, disclose that radius matching uses point distance rather than road travel, and provide an official schedule link for changes. If no eligible stops fall inside the range, report ‘no verified stops found’ instead of lowering the access filter or inventing a nearby alternative. A person can then broaden the radius or pick another event date knowingly.
Recheck Azure API-version support, index field configuration, quotas and event-update procedures when implementing. Retest the same source records after each index rebuild because field mappings may alter coordinates and visibility flags. A correct geo.distance expression is only one component of a useful and trustworthy visitor-facing listing.
How We Research
For this November 2026 guide, we reviewed current official developer sources: Microsoft: OData geo-spatial functions; Microsoft: Query types and geospatial search; Microsoft: OData filter expressions. We compared documented API behavior, request structures and limitations with a fictional nonprofit scenario, then created original instructional diagrams. We did not run vendor APIs, inspect real donor documents, evaluate live locations, measure latency, or conduct a legal or security audit. The illustrations are conceptual, not product screenshots or benchmark output. A real implementation must confirm available regions, preview status, model or API version, cost, IAM rules, source permissions and applicable privacy policies.
Frequently Asked Questions
No. Azure AI Search reports distance in kilometers.
The WKT point literal uses longitude first and latitude second.
No. It is point distance, not road routing or live traffic.
No. Date, publication status, access rights and venue information need separate verification.
Yes, when the applicable GeographyPoint field is configured as sortable and the syntax is supported.