Store the question.
Keep the coordinates, direction, mode and duration attached to the search.
Implementation guide · Travel-time search
Start with the journey.
Then choose the search area.
A commute to work and a journey home are different questions. Decide which one your property search promises before computing a travel-time area.
Direction matters
“From” and “to” are different.
Scroll sideways to see all columns.
| Your user’s question | What to compute |
|---|---|
| Where can I get to from this home? | An outward isochrone with the home as origin. |
| Which homes can I reach from my office? | An outward isochrone with the office as origin. |
| How long from this home to my office? | A route with the home as start and the office as destination. |
An outward area around the office does not guarantee an exhaustive list of homes with the same commute time towards it.
An area, not a radius
Follow the network.
A straight-line radius cannot account for crossings, street connections or transport timetables. The reachable area follows the selected travel mode.
Matching against your catalogue
Keep the shape and its meaning together.
Handle both shapes.
Your code should accept Polygon and MultiPolygon outputs, as documented.
Apply your spatial matching.
Your backend identifies which listings fall inside the returned area.
Before launch
Test the boundary cases.
Opposite direction
Do not silently treat an outward area as an inbound commute guarantee. Routes can differ by direction.
Transit coverage
Confirm timetable availability in the markets you serve, including the areas outside major cities.
Search wording
Make the origin and travel mode visible. Describe approximate filtering honestly when your implementation uses it.