Да, действительно, две деревни Антониха в Варнавинском районе Нижегородской области. И таких примеров по России сотня-другая, даже с разными типами. Но в нашей модели на такой случай получится несколько разных Guid при привязке, так что гео-тёзки укладываются в модель. При запросе по имени мы найдём обе деревни.
Стоит отметить, что ГАР по сравнению с ФИАС (и тем более КЛАДР) - большой шаг вперёд в деле каталогизации. И в плане нормализации прогресс не стоит на месте (Yandex, DaData, Pullenti...). Головной боли стало значительно меньше, работаем...
Вы правы, некорректно сформулировано. На сайте переделал "Индекс для всей России входит в коммерческую версию SDK" на "Индекс для всей России и любого подмножества регионов можно получить из xml-файлов ГАР с помощью конвертера, который входит в коммерческую версию SDK.".
Резонно! Но есть нюанс - продаются не данные (ГАР-индекс), а код, который решает две задачи: (1) преобразует открытые ГАР-данные в проприетарный индекс, с которым производится работа (2) нормализатора адресов. Причём если индекс не использовать, то будет просто нормализация без привязки к ГАР. Сам преобразователь - это программа, и пользователь в любой момент может сам сгенерировать актуальный индекс.
OSM здесь - это дополнительная опция, если их данные указать преобразователю, то они будут использованы. В принципе, можно указать любые свои данные в csv-формате вида "Id гар объекта;GPS-координаты", и тогда они будут подтягиваться к атрибутам ГАР-объектов индекса.
К тому же для получения этого csv-файла я использовал не чистые данные OSM, а КУПИЛ выгрузку у компании NextGis, которая преобразует OSM-данные в удобоиспользуемый вид. Что-то они не сильно выкладывают в открытом доступе, потому что потратили усилия на это преобразование. А я потратил усилия на извлечение из их данных уже нужной информации с валидацией и привязкой к ГАР (12% так и не привязались).
Гаражи исключены из рассмотрения, как и устаревшие здания. Есть ещё немного экзотики типа шахт и пр., которая также игнорируется. То есть 32 млн - это именно актуальные здания в ГАР. Насчёт добавления в OSM - данные есть, но насколько это можно сделать автоматически и какие именно пригодятся - мне сложно судить.
Да, наверное WGS. Та, которая используется в данных OSM. Она же используется и на Яндекс-картах. Например, центр Москвы в этой системе: (55.751696, 37.617064)
У меня была задача дополнить данными из OSM и ПКК данные ГАР ФИАС (а именно - координатами GPS, которые там отсутствуют). Как следствие - получил оценочные данные о полноте OSM. Оказалось, что там около четверти от общего числа российских домов. Этой информацией и поделился. Если OSM не надо дополнять, то и не надо!
Я такую задачу решил на С# в проекте Pullenti Unitext с конвертацией в Java, Javascript и Python. Пытался конвертировать на Rust, но это не получилось. Понимаю всю сложность этой задачи и желаю автору удачи!
Немного запоздало, но всё-таки. В версии 4.14 это "побеждено" - теперь регистр символов не важен, также возможен пропуск ключевых слов. Варианты типа "г. москва кржижановского 15-2-1" теперь обрабатывает корректно.
Индекс ГАР ФИАС достраивать нет смысла - он фиксирован и полностью перестраивается от версии к версии. Там объекты имеют вполне определённую структуру, уникальные GUID и пр. Но он - лишь вспомогательный инструмент при анализе адресов, который даёт возможность убедиться в существовании того или иного объекта, а также убрать неопределённость в ряде случаев.
Для Вашей задачи больше подойдёт Адрессарий - в него можно неограниченно добавлять новые адреса. Правда, только в рамках существующего алгоритма.
Поясню на примере. В недавней загрузке было много вот так оформленных адресов: "196620,Санкт-Петербург г,Пушкин г,Анциферовская(Гуммолосары) ул", которые на самом деле "город Санкт-Петербург муниципальный округ город Пушкин территория Гуммолосары улица Анциферовская", то есть в скобках внутри улицы уровня 8 указывался объект уровня 7. После доработки алгоритма эти случаи стали обрабатываться корректно. Но без доработки алгоритма внешними настройками решить эту задачу проблематично.
Так алгоритм Pullenti совершенствуется от загрузки к загрузке.
Согласен. Думаю, в следующей версии SDK это будет учтено. Просто в тех довольно больших массивах адресов из разных регионов, которые мне приходилось обрабатывать, случаев названий полностью в нижнем регистре исчезающе мало, и я пока ими пренебрёг.
Человек всегда может придумать пример (в области обработки текстов), который будет не по зубам самому лучшему алгоритму. Здесь всегда останется процент ошибок, для этого и используются разные метрики - полнота, точность и F-мера. Если сравнивать разные системы, то по этим метрикам на некотором количестве адресов (аналогично как проводят конкурсы по NER и т.п.). А так всегда можно найти пример адреса, понимаемый одной системой и не понимаемый другой.
Да, с регистром пока неважно - алгоритмы ищут адреса в произвольных текстах, и если учитывать все слова в нижнем регистре, то можно зацепить много мусора. Планирую убрать это требование при обработке текста из одного адреса (в SDK две основные функции - выделение из произвольных текстов и обработка одного адреса из "поля ввода").
Насчёт разделителей - это вообще больная тема. 15-2-1 - это что? Тут даже человек не разберёт. Например, в Забайкальском крае 10/1 обычно обозначают дом 10 и квартиру 1. В других местах это просто номер через дробь. Часть неопределённости снимается при использовании информации из ГАР ФИАС. Но в общем случае неопределённость в таких случаях неразрешима.
При попытке зарегистрироваться на вашем AlpinaGPT выдаётся ошибка типа "MySQL read only regime" (для демо-доступа)
Но если убрать из запроса город, а только проспект Жукова, то привязки к ГАР не получится и запрос будет на условие мнемоник и типа:
anda.street_mnem = 'ЖУКОВ'and('ПРОСПЕКТ' = any(a.street_type))Насчёт запросов - SQL генерируется на основе запросов на естественном языке.
Пусть в таблице PERSONS - персоны, ADDRESS - адреса, PERSONS_ADDDRESSES - таблица связи.
Для запроса "
люди родившиеся после 1990 года и проживающие в москве на проспекте жукова" система сгенерирует:selectdistinctconcat('V=', p.full_name, ';PERSON=',p.id, ';SID=', p.source_id, ';BD=', to_char(p.birth_day, 'yyyy.mm.dd'), ';BY=', p.birth_year, ';G=', p.gender, ';')as "Персона"fromPERSONS pwherep.birth_day > '1990-01-01'andexists(select*fromPERSONS_ADDRESSES p_ajoinADDRESSES aonp_.id2 =a.idwherep_a.id1 =p.idandp_a.type_id = 3and'9e722ecb-da00-452a-b3b5-51b7bc208432' = any(a.street_guid))order by1Здесь из запроса сразу для город + улица получилась привязка к ГАР и добавилось условие на поле street_id.
Ещё раз отмечу, что поля можно не в отдельной таблице, а в той, где уже есть колонка с адресом. У меня в рамках этой модели отдельная таблица такая:
CREATE TABLE public.addresses (id bigint NOT NULL,text character varying(256) COLLATE pg_catalog.“default”,normal character varying(256) COLLATE pg_catalog.“default”,coef integer,message character varying(128) COLLATE pg_catalog.“default”,level integer,country_code character varying(2) COLLATE pg_catalog.“default”,region_mnem character varying(64) COLLATE pg_catalog.“default”,region_guid uuid[],city_mnem character varying(64) COLLATE pg_catalog.“default”,city_guid uuid[],district_mnem character varying(64) COLLATE pg_catalog.“default”,district_guid uuid[],location_mnem character varying(64) COLLATE pg_catalog.“default”,location_guid uuid[],territory_mnem character varying(64) COLLATE pg_catalog.“default”,territory_type character varying(32)[] COLLATE pg_catalog.“default”,territory_guid uuid[],street_mnem character varying(64) COLLATE pg_catalog.“default”,street_type character varying(32)[] COLLATE pg_catalog.“default”,street_guid uuid[],house_mnem character varying(32) COLLATE pg_catalog.“default”,house_guid uuid[],apartment_mnem character varying(32) COLLATE pg_catalog.“default”,apartment_guid uuid[],gps_lat real,gps_lon real,gps_level integer,misc character varying(32) COLLATE pg_catalog.“default”,CONSTRAINT addresses_pkey PRIMARY KEY (id) )Да, действительно, две деревни Антониха в Варнавинском районе Нижегородской области. И таких примеров по России сотня-другая, даже с разными типами. Но в нашей модели на такой случай получится несколько разных Guid при привязке, так что гео-тёзки укладываются в модель. При запросе по имени мы найдём обе деревни.
Изначально адрес - строка. Но строковое представление неудобно для разной аналитики, так что приходится решать эту проблему.
Стоит отметить, что ГАР по сравнению с ФИАС (и тем более КЛАДР) - большой шаг вперёд в деле каталогизации. И в плане нормализации прогресс не стоит на месте (Yandex, DaData, Pullenti...). Головной боли стало значительно меньше, работаем...
Вы правы, некорректно сформулировано. На сайте переделал "Индекс для всей России входит в коммерческую версию SDK" на "Индекс для всей России и любого подмножества регионов можно получить из xml-файлов ГАР с помощью конвертера, который входит в коммерческую версию SDK.".
Резонно! Но есть нюанс - продаются не данные (ГАР-индекс), а код, который решает две задачи: (1) преобразует открытые ГАР-данные в проприетарный индекс, с которым производится работа (2) нормализатора адресов. Причём если индекс не использовать, то будет просто нормализация без привязки к ГАР. Сам преобразователь - это программа, и пользователь в любой момент может сам сгенерировать актуальный индекс.
OSM здесь - это дополнительная опция, если их данные указать преобразователю, то они будут использованы. В принципе, можно указать любые свои данные в csv-формате вида "Id гар объекта;GPS-координаты", и тогда они будут подтягиваться к атрибутам ГАР-объектов индекса.
К тому же для получения этого csv-файла я использовал не чистые данные OSM, а КУПИЛ выгрузку у компании NextGis, которая преобразует OSM-данные в удобоиспользуемый вид. Что-то они не сильно выкладывают в открытом доступе, потому что потратили усилия на это преобразование. А я потратил усилия на извлечение из их данных уже нужной информации с валидацией и привязкой к ГАР (12% так и не привязались).
Гаражи исключены из рассмотрения, как и устаревшие здания. Есть ещё немного экзотики типа шахт и пр., которая также игнорируется. То есть 32 млн - это именно актуальные здания в ГАР. Насчёт добавления в OSM - данные есть, но насколько это можно сделать автоматически и какие именно пригодятся - мне сложно судить.
Да, наверное WGS. Та, которая используется в данных OSM. Она же используется и на Яндекс-картах. Например, центр Москвы в этой системе: (55.751696, 37.617064)
У меня была задача дополнить данными из OSM и ПКК данные ГАР ФИАС (а именно - координатами GPS, которые там отсутствуют). Как следствие - получил оценочные данные о полноте OSM. Оказалось, что там около четверти от общего числа российских домов. Этой информацией и поделился. Если OSM не надо дополнять, то и не надо!
Я такую задачу решил на С# в проекте Pullenti Unitext с конвертацией в Java, Javascript и Python. Пытался конвертировать на Rust, но это не получилось. Понимаю всю сложность этой задачи и желаю автору удачи!
А сама OCR система какая именно была выбрана?
Немного запоздало, но всё-таки. В версии 4.14 это "побеждено" - теперь регистр символов не важен, также возможен пропуск ключевых слов. Варианты типа "г. москва кржижановского 15-2-1" теперь обрабатывает корректно.
Индекс ГАР ФИАС достраивать нет смысла - он фиксирован и полностью перестраивается от версии к версии. Там объекты имеют вполне определённую структуру, уникальные GUID и пр. Но он - лишь вспомогательный инструмент при анализе адресов, который даёт возможность убедиться в существовании того или иного объекта, а также убрать неопределённость в ряде случаев.
Для Вашей задачи больше подойдёт Адрессарий - в него можно неограниченно добавлять новые адреса. Правда, только в рамках существующего алгоритма.
Поясню на примере. В недавней загрузке было много вот так оформленных адресов: "196620,Санкт-Петербург г,Пушкин г,Анциферовская(Гуммолосары) ул", которые на самом деле "город Санкт-Петербург муниципальный округ город Пушкин территория Гуммолосары улица Анциферовская", то есть в скобках внутри улицы уровня 8 указывался объект уровня 7. После доработки алгоритма эти случаи стали обрабатываться корректно. Но без доработки алгоритма внешними настройками решить эту задачу проблематично.
Так алгоритм Pullenti совершенствуется от загрузки к загрузке.
Согласен. Думаю, в следующей версии SDK это будет учтено. Просто в тех довольно больших массивах адресов из разных регионов, которые мне приходилось обрабатывать, случаев названий полностью в нижнем регистре исчезающе мало, и я пока ими пренебрёг.
Человек всегда может придумать пример (в области обработки текстов), который будет не по зубам самому лучшему алгоритму. Здесь всегда останется процент ошибок, для этого и используются разные метрики - полнота, точность и F-мера. Если сравнивать разные системы, то по этим метрикам на некотором количестве адресов (аналогично как проводят конкурсы по NER и т.п.). А так всегда можно найти пример адреса, понимаемый одной системой и не понимаемый другой.
Да, с регистром пока неважно - алгоритмы ищут адреса в произвольных текстах, и если учитывать все слова в нижнем регистре, то можно зацепить много мусора. Планирую убрать это требование при обработке текста из одного адреса (в SDK две основные функции - выделение из произвольных текстов и обработка одного адреса из "поля ввода").
Насчёт разделителей - это вообще больная тема. 15-2-1 - это что? Тут даже человек не разберёт. Например, в Забайкальском крае 10/1 обычно обозначают дом 10 и квартиру 1. В других местах это просто номер через дробь. Часть неопределённости снимается при использовании информации из ГАР ФИАС. Но в общем случае неопределённость в таких случаях неразрешима.
Думаю, здесь дело в том, что раньше был какой-нибудь аул или посёлок Михайловский, а потом стал поселением, но название менять не стали.