Address search fires incorrectly when selecting from duplicate street addresses about am-i-rent-stabilized HOT 1 CLOSED

Noting that this seems to be due to a bug in the NYC Geosearch API. For example, the response to this query still returns the address in Brooklyn as the first result (see the features array in the response object):

https://geosearch.planninglabs.nyc/v1/search?text=52%20HENRY%20STREET,%20Manhattan

Currently the AIRS frontend app grabs the first result from the search/ API endpoint response which is why the incorrect address is displayed.

Until the NYC Planning Labs team fixes this problem in the API a work around could be storing the lat, lon, and BBL for the selected address from the autosuggest results list (this is what is returned by the Geosearch API autocomplete endpoint once a user starts typing in the search box) when a user chooses an address from that list. This would require some additional branching logic that handles someone typing an address but not choosing an autosuggest result then hitting submit vs. someone selecting an autosuggest result and then hitting submit. The former scenario would still require the address text being passed to the Geosearch search/ endpoint while the latter would not. The existing implementation passes the address text to the search endpoint no matter what, because well I was lazy.

from am-i-rent-stabilized.