search

agrc / api.mapserv.utah.gov

An asp.net web api system for geocoding addresses and performing spatial queries
https://api.mapserv.utah.gov/
MIT License
5 stars 5 forks source link

matchAddress doesn't return the actual city #245

Closed stdavis closed 4 months ago

stdavis commented 9 months ago

If I submit an address in Holladay: 4055 S 2300 E, Holladay the matched address returned is 4055 S 2300 E, SALT LAKE CITY which is the wrong city. I'm assuming that this is because we are returning the address grid, not the city. I wonder if it would be worth trying to figure out how to return the correct city/county. This may be a breaking change. Not sure if it's worth it. Someone from West Jordan brought this up saying that West Jordan addresses were returning the city as Salt Lake City.

steveoh commented 9 months ago
image
stdavis commented 9 months ago

Oh yes. I remember that blurb in the docs. I wonder if there's a way that we could configure the geocoding services to return the correct city. I believe that there are folks out there that would love to use our geocoding service that don't have the ability to make a secondary request to the search service to get the correct city. For example, Esri/AGOL configurable apps, etc. For what it's worth, the Esri geocoder does a better job of returning the correct city:

https://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer/findAddressCandidates?SingleLine=8000%20Redwood%20Rd,%20west%20jordan,%20utah&f=json

image

steveoh commented 9 months ago

The API geocoding endpoint doesn't try to mimic or replace the esri world geocoder. Masquerade seems to fill that gap and would probably be a better place for this request.

We can explore what data is available in the locators to provide more context but we can't provide everything that everyone could want. Currently, the api and endpoints are setup so clients can make subsequent requests for any sgid data they require with the location returned by the geocoding endpoint.

We also have some interest in exploring postgis locators which may diverge more from the esri locator service responses.

stdavis commented 9 months ago

I didn't consider that Masquerade could make the second request. I'll create an issue in that repo. However, I still wonder if the geocoders could be updated to return the correct city.

steveoh commented 9 months ago

I think since we made the choice to use the address system instead of the city to improve the geocoding match rates, it wouldn't be trivial to change. I wonder if it would be considered a breaking change by the clients?

We can certainly explore ways to provide access to some other fields available in both source data sets. That comes with it's own challenges e.g. which side of the road do you choose the value from if the right and left are different?

stdavis commented 9 months ago

Even if you could add additional fields to the candidates without messing with the match address, masquerade could make the switch without having to query city/county data again. That would be an awesome improvement.

which side of the road do you choose the value from if the right and left are different?

I believe that our roads data has support for defining left/right values for city/county data. I can't speak to the quality of the data.