Closed Yamakasi closed 6 years ago
Yeah, This is actually a "wont fix". It is the geocoder servers that decides that data to return and that is nothing we can change.
Mhh, that is strange, you can make a default what you want to output by modifying the object you get back, I think that should be done at any time to get it lined up, that is what a lib can and should do.
If I geocode the address “foobar” and google server tells me “the subLocallity is xxx” and the OSM tells me “the subLocallity is yyy”, there is nothing the geocoder provider can do to “correct” this. It is simply an api client.
If you think I’m wrong, please provide a PR that fixes this issue and I’ll be happy to review it.
I agree with @Nyholm here ; we rely on the information returned by the API. No reason to not "trust" what the API returns and I believe we shouldn't change (or mess) with what is returned by the API ; it will be confusing for the end users.
I don't agree. If you aggregate results you need to make sure the results are the same format, they are not. The library is the layer where it should happen, not somwhere outside as the library already gives another output then the provider does by itself, it's not 1:1 already.
I see what I can do in a while as I don't need it now and went full OSM, but multiple resources should give the same format in result if the value exists.
It seems that locality and subLocality are mixed between providers, is this known ?
I have tested this between Google and OSM/OpenCase
OSM and OpenCase seem to be equal.