Improve address scoring in latlng_to_address()

[nexushoratio]

I have at least one example where the reverse geocoding picks a really bad result.

https://developers.google.com/maps/documentation/geocoding/requests-reverse-geocoding

Right now we only allow a result_type of street_address, but with my example, premise is MUCH better. In particular, the good has a location_type of ROOFTOP while the other had RANGE_INTERPOLATED.

But, from a set of one, it is not yet possible to determine that premise is always better than street_address. More testing is needed.

Also, currently, scores are a simple summation of weights. A tuple-like solution would probably be better. Also, switch from a dictionary of weights to proper enums.

• Switch to geoalchemy/spatiallite #14

[nexushoratio]

Sampling some places demonstrates that it is NOT straightforward in any way. For some, the plus_code was the best, others, premise, others street_address.

Each result also has a ['geometry']['location'] associate with it. Maybe picking the one that is closest to the original latlng is best? Or maybe the results array is already sorted and the best is the first element (though I was unable to find any documentation on this)?

Anyway, the only place that uses this information is when we generate a KML file for the optimal route, and we are unable to do that right now anyway because the old libraries no long exist.

Figuring out if closest result is best would currently depend on pyproj anyway, and that might go away with #14 .

So, this is a pretty low priority item at the moment.

[nexushoratio]

A place like 38.455568,-122.497515 is interesting.

Some results have administrative_area_level_2, but not postal_code, while others are the opposite. None have both.