Hacker News new | ask | show | jobs
by matrixgard 111 days ago
The anchoring point is real and you've framed it well. Most people don't even realize the first suggestion wins 80% of the time, they just go along with it.

The transit data angle is the differentiator here — straight-line midpoints are useless in cities with asymmetric transit coverage. Curious how you're handling cases where one person is in a transit dead zone and others are on a good line. Does the fairness score penalize that person's zone or just present the raw reachability overlap?

Also the budget filter suggestion in comments is interesting — have you thought about layering in venue ratings so the "fairest spot" is also the best-reviewed option in the overlap zone?

1 comments

Hey matrixgard

Good question on the dead zone case. Right now the system presents the raw reachability overlap rather than penalising anyone's zone explicitly. If someone is in a transit dead zone, their isochrone simply ends up smaller, which naturally constrains the overlap area. The Fairness Score then measures how equitably the resulting venues sit within that overlap — so a venue that’s at the edge of the smaller zone gets scored lower than one closer to the true intersection. It’s implicit rather than explicit penalization, which feels more honest than artificially adjusting one person’s weight.

On ratings — yes, already in. Google Places rating is factored into the venue ranking inside the overlap zone, so the output isn’t just the fairest spot geographically but the best-reviewed option within the fair zone. The two signals are combined rather than sequential. The gap I’m still working on is price level — Google Places has a price tier field but it’s inconsistently populated, which makes it not very reliable as a filter right now.