Results differ between Single Field Search and Address endpoints about geoclient HOT 5 CLOSED

This does seem to be a bug and I'll toss it on the pile. Taking a wild guess, the issue likely stems from the fact that the /search endpoint uses static data to map a finite set of city names to one of the five boroughs needed when calling Geosupport.

The single-field search capability is currently the only Geoclient feature that uses logic and data from outside of the Geosupport application/dataset itself. This feature was one of the reasons this project was originally created and it can be very helpful; the downside is that it relies on arbitrary external data that is not nearly as complete or accurate as what's built into Geosupport itself.

I can't provide an ETA for the fix until I investigate, but please continue to filing reports if you find other such issues.

Thank you for bringing this to our attention!

from geoclient.

Ok,

Thanks for explaining. So in general though then, since the city name isn't even required to use the /address endpoint, is providing just the address and the borough to the /search endpoint sufficient enough to get accurate geocoding? It would seem like it is?

Thanks!

from geoclient.

For all calls, it is always better to provide the borough if available. This is because all the supported Geosupport functions require a borough (address calls will accept either a borough or zip code). Similarly, when using the single-field search (SFS) API, providing the borough is always preferable because then Geoclient doesn't have to try to "guess" which borough to use; in this case, translating the city name "Laurelton" to the standard (to Geosupport) borough name "Queens".

The /search endpoint was created because for, e.g., user-driven searches from a web app or when geocoding a third-party dataset such information often isn't known or doesn't exist. The SFS functionality provides it's own free-form, NYC-specific location parser, fuzzy search and (limited) data-cross-referencing. It provides a limited degree of client-specified algorithm configuration and recursive search based of suggestions returned by Geosupport for unrecognized locations. However, these features come at the price of reduced accuracy because they rely on Geoclient-only logic/heuristics for parsing and interpreting the intended target of your search.

As an imperfect analogy, consider the difference between searching Google and the IMDb for a particular film. The former is great when you're not really sure of the movie's name but the latter is always more conclusive, if you know the name, director, year of release, etc.

Does that make sense or did I just make this more confusing?

from geoclient.

Yes, makes perfect sense, thanks! In our case we always know the borough, so this works out great for us-

from geoclient.

I'm closing this ticket for now; please reopen or create a new ticket as needed. Thanks, Matt

from geoclient.