Как парсить почтовые адреса (своя реализация)?

Question

[Alexchexes]

1. Есть адреса РФ, записанные в произвольной форме, например:
ижсталь 1 2 16-я 1 массив 1 литер а
Который нужно привести к такому виду:

Удмуртская Респ, Завьяловский р-н, тер. СНТ Ижсталь-1-2, ул Массив 1-16-я, д 1А

2. Есть федеральный справочник ФИАС/ГАР, в котором хранятся все ныне существующие адреса

3. Есть своя база данных, в которой хранятся адреса в правильной ФИАСовской форме, разбитые по полям, но в ней не все адреса ФИАСа, а только те, с которыми мы работаем (есть предположительно все населённые пункты РФ, но вот снт, улицы, и дома есть уже не все, их слишком много)

4. Есть входные данные в виде списков из таких произвольных адресов, которые могут быть более-менее нормальными (г москва ул тестовская 1) а могут быть чем-то вроде примера выше.

5. Нужно, при обработке входных данных, обращаясь в первую очередь к своей базе данных (а не к ФИАС), находить, есть ли у нас такой адрес как Удмуртская Респ, Завьяловский р-н, тер. СНТ Ижсталь-1-2, ул Массив 1-16-я, д 1А, если нет адреса с точностью до дома, то находить посёлок типа тер. СНТ Ижсталь-1-2, если и его нет, то хотя бы находить район Завьяловский р-н в регионе Удмуртская Респ.
После такой первичной проверки, уже делать запрос в сервис распознавания адресов типа API Яндекса, Дадаты, Гугла и т.д.

Этот вопрос о том, как можно уверенно находить в БД PostgreSQL почтовый адрес, содержащий цифры в названии населённого пункта (СНТ Ижсталь-1-2) или в названии улицы (ул Массив 1-16-я), при том что в исходной строке для поиска всё это записано в другом порядке, формы слов могут отличаться или частично отсутствовать составные части, а ещё и номер дома прилеплен без разделителя к названию улицы/нас.пункта.

Осложняет ситуацию (наверное) ещё и тот факт, что улицы в адресе иногда нет, идёт название населённого пункта и сразу же номер дома, например СНТ Ижсталь 1 2 75, имея в виду СНТ Ижсталь-1-2, д 75, и это будет правильный, реально существующий адрес.

Как бы вы подступились к этой задаче на уровне приложения, на уровне базы данных?

Comments

[hint000]

Попробуйте копнуть с этой стороны: https://yandex.ru/yandsearch?text=fuzzy+search

[Alexchexes]

hint000, безусловно, нечёткий поиск здесь понадобится. Вопрос как корректно определять, что входная строка подразумевает адрес "СНТ Ижсталь-1-2" а не "СНТ Ижсталь, д 1 к 2", к примеру, т.е. в первую очередь искать совпадения по населённым пунктам, улицам, а уже потом вторым заходом - по домам.

Задаюсь вопросом, как всё это правильно делать

[hint000]

Alexchexes, первоначально искать "Ижсталь" без цифр. Если найден один вариант, то это он и есть. Если больше одного, тогда нечёткий поиск можно применить в обратную сторону, т.е. искать "СНТ Ижсталь-1-2" в исходной строке "ижсталь 1 2 16-я 1 массив 1 литер а", потом там же искать какой-нибудь "СНТ Ижсталь-3-4", если он тоже был наден в базе... И сравнивать уровень похожести.

[hint000]

Да и не надо сразу искать дом "СНТ Ижсталь, д 1 к 2", надо сначала определиться с населённым пунктом, заменить в исходной строке неточное название на каноничное название из базы, потом продолжить поиск улицы и дома.

[Alexchexes]

hint000, спасибо, навели на некоторые мысли.

Если больше одного...

Вот этим моментом особенно, видимо нужно формировать набор предполагаемых вариантов, после чего уже далее по каким-то критериям сравнивать вероятность того, что же из них имеется в виду. Ведь например "массив" может встречаться как в названии улицы, так и в названии нас. пункта (пример г Воронеж, Жилой массив Олимпийский - числится в ФИАСе как населённый пункт внутри Воронежа)

Да и не надо сразу искать дом ... надо сначала определиться с населённым пунктом

Да, так и размышляю, вот видимо нужно по иерархии идти и складывать варианты, уже потом из них выбирать.

Проблема например такая: входная строка "снт ижсталь 1 2", и у нас действительно есть "СНТ Ижсталь-1-2", и есть "СНТ Ижсталь-1", но адрес предполагает наличие дома, так что выбрать нам надо "СНТ Ижсталь-1", и дом - 2, а не "СНТ Ижсталь-1-2" без дома.

Это ведь на уровне БД уже не сделать, видимо, и всю логику в приложении нужно запиливать, я правильно мыслю?

[Alexchexes]

hint000, Да, и есть догадка, что без работы с полным справочником всех существующих адресов эту задачу не решить, т.к. используя только лишь свою неполную БД, о чём я писал в тексте вопроса, и нечёткий поиск, невозможно понять - нужный вариант действительно тот который имеется в виду, или он просто самый приближённый из тех, что мы храним у себя, а в полной базе адресов существуют более точные совпадения...

И нет даже ориентира, от чего отталкиваться чтобы понять, надо ли обращаться к полной базе, или же всё успешно найдено только по нашей БД. Я прав?

[hint000]

Alexchexes,

и всю логику в приложении нужно запиливать, я правильно мыслю?

Правильно. Но, возможно, в некоторых СУБД уже встроены функции нечёткого поиска, не буду врать о том, чего не знаю точно.

И нет даже ориентира, от чего отталкиваться чтобы понять, надо ли обращаться к полной базе

Ориентиром может быть некая метрика, показывающая, насколько близок результат поиска к искомому. Условно, если совпадение на 99%, то можно не обращаться к полной базе, а если совпадение на 50%, то нужно обращаться.

[mayton2019]

Вот интересно. Мы живем в эпоху нейросетей дипфейков и всяких там co-pilot которые чуть ли не за тебя код пишут. А вот старая бородатая задача такая как парсинг адресов осталась до сих пор нерешённой. Честное слово где там знаменитые проблемы Гильберта? Ну да ладно. Ворчу я.

По сути. Давайте посмотрим на исходные данные.

Удмуртская Респ, Завьяловский р-н, тер. СНТ Ижсталь-1-2, ул Массив 1-16-я, д 1А

Вот тут Респ - это республика. Сокращение тоесть. А могло-бы быть и Рес. И Респуб. Короче вы поняли. Fuzzy.
Я-бы предложил скачать все справочники ФИАС. Проиндексировать их триграммами и также построить соответствие для данного адреса. После такой процедуры мы сможем нечётко тегнуть какие элементы могут быть (!) взяты из какого справочника.

Что ожидаю на выходе. Токены и теги.

Удмуртская @resp 
Респ, 
Завьяловский @city, @raion @center 
р-н, 
тер. СНТ 
Ижсталь-1-2@factory, 
ул Массив 1-16-я, д 1А

Далее обратите внимание что Завьяловский может быть и городом и еще бох знает чем. Но упускать такой кейс нельзя ибо взято из справочника гордов.

Дальше - матчинг. Мы заполняем то что есть. И отбрасываем противоречия. Почему мой подход лучше? Потому что он не завязан строго на порядок элементов в адресе. Вот в США например адрес пишут ровно наоборот. Тоесть практики разные бывают. И адресная строка вообще никак не формализуется. А что касается квартал-дом-строение-корпус-дробь-квартира - ойойой там конь не валялся. Эту сущность я-бы оставил как есть.

[Alexchexes]

mayton2019, я тоже думал насчёт порядка слов, но проблема, как мне видится, в том, что название улицы может совпадать с названием одного из городов или областей (Карачаево-Черкесская Респ. и ул. Черкесская в Нижнем Новгороде).

Проблему можно было бы решить, проверяя, осталось ли что-то, подходящее в качестве названия улицы в строке, после того как мы забрали слово "Черкесская" в название региона, но если у нас будет улица "Черкесская 1-я", мы забираем "Черкесская" в регион, то у нас может получиться что-то наподобие "Карачаево-Черкесская Респ, ..., ул 1-я" при некотором неблагоприятном совпадении лексем в исходной строке и существовании улицы типа "ул 1-я".

Пока не придумал как с этим можно бороться.
Если бы нужно было только реализовать подсказки, из которых человек вручную выбирает вариант, то подойдёт, а вот если хотим в автоматическом режиме справочник заполнять, это уже не вариант.

[mayton2019]

Alexchexes, я-же говорю. После тегирования у тебя будут возможность не парсить а матчить варианты. Причем часть из них сразу отпадают как противоречивые. Например если Черкесская будет улицей и республикой и в то-же время уже детектирована улица Ленина то логический вывод будет только один.

По поводу подсказок. Какая-бы умная логика не была но всё равно будет 3-5% записей которые попадут в отстойник где человек пофиксит их в ручном режиме. Это тоже нормально. Не надо пытаться вообще автоматизировать всё.

[Alexchexes]

mayton2019, а с токенами вроде просто цифры "1" как быть? Тоже теги для них? Ведь в некоторых городах есть улицы с названием "мкр 1", и в исходниках, которые надо разбирать, "мкр" часто отбрасывается, остаётся просто "1" и остальная часть адреса.

[mayton2019]

Alexchexes, здесь ничего не могу сказать. Можно отдельной темой обсудить вероятностные фильтры. Тоесть считать что "1" с вероятностью 75% можно тегнуть как район если он стоит на расстоянии слова от @raion.

Попробуй сделай задачу-минимум. Не надо все сразу охватывать.

[Alexchexes]

mayton2019, Да дело в том что задача-минимум уже реализована, не в части парсинга но в части обработки и стандартизации адресов: используется по api сервис созданный именно для этого. Но он, во-первых, кушает адреса только с максимум 1 ошибкой и если встречается "лишнее" слово он уже ничего не распознаёт ("Фёдора Тютчева" он не распознает если реальное написание "Ф. Тютчева"), а во вторых, он платный.

Изначально этого хватало, но со временем накопились тысячи адресов для ручной проверки и исправления, при том что огромную часть уже исправляем по шаблону, вот и хотелось бы перед реализацией "правильного" решения, вычислить все pros & cons, и на опыте учесть все подводные камни перед тем как приступать. Вроде той же цифры "1".

[mayton2019]

Ничего не понимаю про платные API. Собственно их не интересно здесь обсуждать.

Дистанцию между Федором Тютчевым и Ф. Тютчевым считай в триграммах или в расстояниях Левенштейна. По крайней мере сможешь утверждать что Ф.Тютчев ближе чем Бонч-Бруевич.

[Alexchexes]

mayton2019, да, от сторонних api хочется отойти, максимум использовать их как вспомогательные, поэтому и задаю здесь вопрос.

[mayton2019]

У меня идеи закончились. Код давай. И модульные тесты.

[Alexchexes]

mayton2019, mayton2019, Хорошо, но это попозже, сейчас в роадмапе задача парсить и сопоставлять номера домов, пока они есть отдельным полем.
из такого "70кЛИТАВЛД" делать "влд 70 литера А", например.

Задача кстати похожая, даже попроще, базы не нужны. Но уже тоже пришёл к необходимости вычислять процент попадания, при сопоставлении двух номеров дома друг с другом, по нетривильной формуле ибо "1к1" может означать "1/1" и это должно иметь высокий % совпадения, тогда как "1а" и "1б" - очень низкий. А "1а\3стр4" и "1а\3стр5" - тоже высокий т.к. корпусом в такой детализации часто можно пренебречь.