Our address sorting is bad

[pmk01]

Addresses which aren't a simple [n] [street name] get pushed to the bottom of the list. This is bad for users, who expect 32A to come between 32 and 33.

[chris48s]

Related issues:

• Review address sorter against test datasets uk-geo-utils#11
• Improve address ordering for addresses like 11A Foo Street uk-geo-utils#10

The relevant code is

https://github.com/DemocracyClub/uk-geo-utils/blob/master/uk_geo_utils/helpers.py#L277
https://github.com/DemocracyClub/uk-geo-utils/blob/master/uk_geo_utils/tests/test_address_sorter.py

Its not awful, but I think in order to sort all those cases correctly without breaking loads of other stuff, you need to move from a model where address is stored as single string to a model where you keep the addresses broken down into parts, sort them and then concatenate all the bits together for display.

This is further complicated by the fact there are 2 different formats depending on whether it is a PAF address or Local Auth address.

[GeoWill]

Thanks @chris48s

[chris48s]

Just came across https://github.com/openvenues/libpostal (it has python bindings - https://github.com/openvenues/pypostal and a postgresql extension https://github.com/pramsey/pgsql-postal ) and thought back to this thread.

I suspect it is imperfect, but I wonder if using that to:

• parse the address into bits
• sort the bits
• stick them back together for display

might be a way to improve on my crude attempt to do that without eating the entire elephant of the "proper" solution.