Пользователь
0,0
рейтинг
5 августа 2014 в 19:44

Разработка → Парсинг почтовых адресов из строки на C#

.NET*
imageНе так давно передо мной встала задача выгрузки данных одного моего заказчика в очередной около-государственный формат. Помимо прочего, в выгрузке требовалось структурированно предоставлять почтовые адреса клиентов-физлиц, включая индекс, область, район и так далее до номера квартиры.

Все бы хорошо, только засада в том, что исходные адреса клиентов были забиты в виде простой строки типа «Китежград, ул.Волшебная 22 дом кв.15». То есть, с одной стороны, о почтовых индексах никто слыхом не слыхивал, с другой же, текстовое поле ввода предлагает широкий простор для самовыражения и народно-прикладного творчества.

Ничтоже сумняшеся я полез искать решение сей проблемы в сети, рассудив, что подобная ситуация должна быть весьма распространенной и кем-то однозначно побежденной. Так и оказалось, правда, вместо исходников или просто скомпиленных либ на меня жадно пялились онлайн-сервисы, предлагающие с использованием их API парсить почтовые адреса за вполне реальную мзду (минимальный прайс, который мне удалось найти, составлял 10 копеек за адрес).
Так как отдавать добровольно доходы какой-то сторонней организации мне не нравилось, да и к тому времени появился некий азарт, захотелось сколхозить решение самостоятельно, по возможности минимальными усилиями. Облегчало задачу то, что заказчику не требовалась высокая точность парсинга – наличие ошибок любого рода не приводило бы к фатальным проблемам.

Для начала посмотрел в сторону Томита-парсера, но после знакомства с многостраничным конфигом примера, позволяющего по тексту определить, в каком городе кто живет (http://api.yandex.ru/tomita/doc/dg/concept/example.xml), оптимизма несколько поубавилось, но укрепилось желание написать какой-нибудь свой велосипед.

Естественно, с достаточно жесткими ограничениями на входные данные, при которых будем продолжать изыскания:
  1. Адрес всегда написан без опечаток: «проспект Арфографии» пусть останется на совести вводящего.
  2. Запись адреса ведется от максимально общего элемента (область) до максимально частного (номер квартиры).
  3. С учетом пункта 2, забиваем болт на слова-подсказки типа «область», «улица», «проспект», «дом». Так что если в городе есть и проспект Телепузиков, и улица имени их же, то уловить столь тонкую грань мы не сможем. С учетом редкости подобной ситуации и наличием права на ошибку – вполне себе рабочий вариант.

Далее я озадачился поиском источника данных, из которого смог бы черпать сведения по почтовым индексам. Как оказалось, на сей день КЛАДР – это уже вчерашний день, ФИАС рулит (http://fias.nalog.ru). Загрузив оффлайновую копию этой базы, я принялся изучать предоставляемые ею возможности.

Особо заинтересовали меня там две таблицы: ADDROBJ – в ней хранится древовидный список всех адресных объектов, начиная с субъекта РФ и заканчивая улицей, и HOUSE<номер региона> – где хранятся номера домов с привязкой к записям в ADDROBJ вместе с их индексами. Хранящейся в этих двух таблицах информации достаточно для достижения обеих целей: проверки правильности парсинга адреса (если удалось найти адрес в базе данных, значит, мы его распознали верно), а так же для определения почтового индекса.

В голове начал вырисовываться алгоритм:
  1. Разделяем строку почтового адреса на адресные элементы. Под адресным элементом подразумеваю то, запись о чем можно найти в виде строки таблицы ФИАС-а: район, город, улица, дом, а так же номер квартиры.
    1. К безусловным разделителям адресных элементов относятся точки, запятые, точки с запятой, слэши.
    2. К условным разделителям относится дефис/тире, если адресный элемент после дефиса является числом. Например в «переулок Депрессии, 38а-117» дефис является разделителем, а в «г. Усть-Зажопинск» – нет.
    3. Пробел может являться разделителем, а может и не быть им. Так в «Восьмого марта д.15» пробел между «Восьмого» и «марта», очевидно, не должен делить элементы, а между «марта» и «д.» – должен. Самый простой вариант в лоб – составить все возможные варианты разделения адресных элементов пробелами и продолжать дальнейшую работу алгоритма с каждым из них в отдельности.
  2. Такие адресные элементы, как «улица» («ул»), «область» («обл») и так далее полностью выкусываются.
  3. Начиная с самого первого элемента, все они последовательно прогоняются по базе ФИАС.
    1. Если элемент находится в базе, то запоминается его GUID и LEVEL (уровень в иерархии), при этом следующий элемент ищем с бОльшим значением LEVEL и фиксированным PARENTGUID равным GUID предыдущего найденного элемента.
    2. Если не найдено элемента по заданному PARENTGUID, пытаемся построить цепочку, включающую промежуточные элементы.
    3. Первоначальный поиск ведется в таблице ADDROBJ, как только ищем следующий после улицы элемент (LEVEL улицы равен 7), переключаемся на таблицу домов HOUSEXX.
    4. Если адресный элемент не найден, просто игнорируем его.
  4. Побеждает вариант (а их по итогам шага 1.3. может быть несколько), у которого получилось самая длинная распознанная цепочка.
  5. Для порядку она достраивается по таблице ADDROBJ до самого верха. Это нужно потому, что, например, в исходной адресной строке не было указано области и района, а сразу город.
  6. Дальше немного схитрим. Номером квартиры считается последний адресный элемент (если он не был распознан как номер дома), а корпусом, строением, литерой и всем прочим – адресные элементы между распознанным номером дома и номером квартиры. Можно было бы построить более детальный анализ – таблица HOUSEXX это позволяет – но мне показалось это излишним хотя бы потому, что вряд ли почтовые индексы будут различны для домов «113» и «113 ст.1 корп 4 лит.Ж».

Алгоритм получился эмпирическим, наивным, предусматривающим не все возможные ситуации… Но для ограничений по скорости реализации и обширным правам на ошибку – он выглядел вполне удовлетворительным. Сочинить и реализовать его удалось примерно за 1 вечер.

Для привычки и удобства работы перегнал таблицы ADDROBJ и HOUSEXX из DBF в MS SQL (как их можно легко отконвертировать, прочел здесь: http://blogs.technet.com/b/isv_team/archive/2012/05/14/3497825.aspx).

В результате получился класс AddressParser, забирающий на входе строку адреса и выдающий в ответ экземпляр класса Address. В конструктор AddressParser можно подавать собственную реализацию IKnwonAddressComparator, если текущая реализация, заточенная на MS SQL чем-то не устраивает.

По скорости парсинга получилось что-то около 2-5 адресов в секунду. Плохо, но все лучше, чем ручками. Основная проблема: серьезное количество вариантов для проверки, генерируемое пунктом 1.3. По-хорошему, этот момент стоит полностью переписать, используя базу адресов уже на этом этапе для проверки существования адресных элементов. В качестве промежуточного варианта можно ограничить количество вариантов неким значением.

По случайной выборке качество парсинга составило 62% на реальных данных. Для оценки считалось, что адрес может либо быть полностью распознан (вплоть до квартиры), либо нет. Никаких полутонов.

Распределение по ошибкам получилось следующее:
  • 37% — опечатки. Как правило, банальные пропуски-добавления букв: «Киирова», «Москв»…
  • 21% — использование сокращений: «К.Маркса», «Р.Люксембург»…
  • 42% — отсутствие домов в базе ФИАС, и, в результате, невозможность определить индекс и завалидировать всю цепочку. Весьма неожиданная для меня причина, хотя многие пишут, что ФИАС все еще сыроват для промышленного применения

Какие выводы можно сделать?

Если нужно, как и мне, невысокое качество парсинга и низкая скорость – можно использовать.

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

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

Но все это – уже совсем другая история.

Исходные коды можно загрузить отсюда: https://yadi.sk/d/muzi9b6qZ8DWh
Тестовую MS SQL базу с домами по 38 и 78 регионам можно взять здесь: https://yadi.sk/d/ERXyDXv7Z8Dab
Илья Тихонов @t13s
карма
37,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (49)

  • +14
    Глянул ваш код — повезло вам, что нет такой улицы как ' DROP TABLE ADDROBJ :-).
    PS: код лучше выложить на GitHub.
  • 0
    А что, хорошее название для какого-нибудь района, куда лучше не ходить.
    Ну и полагаю, это не самая страшная проблема, хоть и легкопочинимая.
    Спасибо за советы :-)
  • 0
    У меня в городе есть и улица, и проспект Шевченко (он в нашем районе родился). То есть, с моим городом возникли бы проблемы) А у него население всего-то 20к.
    • 0
      А в городе, где я родился, все еще хуже: есть 19 квартал, и есть 19 микрорайон. И это разные штуки.
      Но пока забил. Хотя грязный хак, который побеждает проблему, следующий: при выкусывании слов «улица» («ул»), «квартал» («кв-л», «квл»)… добавлять их православно-фиасовскую форму (поле SHORTNAME) в отдельный список. И если при поиске на очередном шаге нашли несколько элементов с одним названием, но разным SHORTNAME, выбирать тот, у которого SHORTNAME есть в выкушенном списке.
  • +1
    Естественно, с достаточно жесткими ограничениями на входные данные, при которых будем продолжать изыскания:
    Адрес всегда написан без опечаток: «проспект Арфографии» пусть останется на совести вводящего.
    Запись адреса ведется от максимально общего элемента (область) до максимально частного (номер квартиры).
    С учетом пункта 2, забиваем болт на слова-подсказки типа «область», «улица», «проспект», «дом». Так что если в городе есть и проспект Телепузиков, и улица имени их же, то уловить столь тонкую грань мы не сможем. С учетом редкости подобной ситуации и наличием права на ошибку – вполне себе рабочий вариант.

    К сожалению, в реальной жизни эти три пункта плохо применимы. Мы тут как-то гоняли один не очень публичный адресный сервис на совершенно реальной базе адресов — получили точность распознавания процентов в 20-30.

    Мой вам совет — помимо всего прочего, в общем случае парсер должен отдавать не один вариант, а несколько, с указанием веса (точности распознавания) каждого из них.
    • 0
      Видимо, мои подопечные подходили к делу более аккуратно, т.к. 62 тестовых результата из сотни распарсились корректно. Несколько вариантов парсер и сейчас прорабатывает, но отдает только победителя, так что модификация будет несложно. Но, возможно, бессмысленной, т.к. без работы с опечатками ценность весов теряется.
  • 0
    Занимаюсь, в свободное время, тем же самым. Правда уже дошел до переконвертации фиас в нужный вид). Чуть комментариев:

    Адрес всегда написан без опечаток: «проспект Арфографии» пусть останется на совести вводящего.

    Сфинкс отлично справляется с этой задачей. Думаю, можно и MSSQL приспособить. Гуглить по «поиск по триграммам» ;)

    Запись адреса ведется от максимально общего элемента (область) до максимально частного (номер квартиры).

    Это зря. Не должен порядок влиять на качество )

    С учетом пункта 2, забиваем болт на слова-подсказки типа «область», «улица», «проспект», «дом».

    Пока тоже забиваю, но есть мысли как использовать. Доделаю — накатаю пост на хабре)
    • 0
      Гуглить по «поиск по триграммам»

      Спасибо! На самом деле, когда писал заключение про недостатки, гуглил, как их можно обойти. В PostgreSQL это нативно вроде как работает (http://habrahabr.ru/post/78566/), а под MS SQL нужно что-то городить. В общем, пока решил подзабить, а там посмотрим.

      Не должен порядок влиять на качество

      Согласен, тем более, что Артемий Татьянович наметил тенденцию использования обратного порядка (http://www.artlebedev.ru/kovodstvo/sections/163/), да и в цивилизованных странах он же используется.
      Но тогда забивать на слова-подсказки вообще никак нельзя. А они могут стоять как перед значащим словом (ул. Декабристов), так и после него (Иркутская обл.)
      • 0
        В общем, пока решил подзабить, а там посмотрим.


        Я начинал с этого поста. По сути — этого хватит именно для опечаток.

        Но тогда забивать на слова-подсказки вообще никак нельзя.


        Эмм… Не вижу связи, если честно.
        • +3
          Без слов-подсказок трудно будет различить «Иркутская обл. пос. Лесной Смоленская ул.» и «ул. Иркутская Лесной пос. Смоленская обл.»
  • 0
    А такой (не совсем честный) вариант не рассматривали:
    Отправлять адрес в поиск Яндекс/Гугл Карт и из результатов извлекать распарсеный адрес.
    Конечно, есть шанс быть забаненым, если адресов очень много, но, думаю, это тоже решаемо, если подобрать оптимальные задержки между запросами или затариться несколькими прокси.
    • 0
      Пробовал такой вариант для тех адресов, которые не удалось распарсить своим методом. За исключением опечаток, Яндекс/Гугл-карты тоже не смогли дать внятный ответ. В периферийных регионах гугло-яндексовые карты местами хуже, чем ФИАС.
      Ну и потом, затачиваться на сторонний сервис, для этой цели изначально не предназначенный — это обрекать себя на постоянный головняк с поддержкой.
  • 0
    del
  • 0
    Те 10 копеек за адрес идут за реальную работу людей, потому как реальный парсинг адреса требует еще и работы оператора. То что описали вы этой статье врядли можно назвать парсингом, подобную задачу доводилось решать один раз в качестве модуля к црм системе одного крупного банка, кроме разбиения и сопоставления с эталоном делалась умная самообучаемая система для операторов, которая давала в процентах 10 результат достоверный, в остальных выдавала предположения и варианты на основании расстояния левенштейна и предыдущем опыте работы оператов с системой.
    • 0
      10 копеек за адрес, конечно, идут за реальную работу людей — например, разработчиков сервиса :-) Парсить вручную адреса по 10 копеек никто не будет.
  • 0
    Двойственное ощущение от таких статей.
    1. Автор поучился, изучил предметную область и явно разобрался. LevelUP =)
    2. С другой стороны поступил как программист. Зная о наличии сервисов высоким уровнем качества по 10 копеек за запись потратил не один день на написание своего кода с выходом ~70%
    3. Странно отношение к адресу как просто в тексту, по сути это или адрес доставки корреспонденции или разрез аналитики. Доставка и корреспонденция стоит денег (70% аналитика — не аналитика=))
    4. с точки зрения экономики просто умножите объем своей базы на 10 копеек и спросите стоило ли оно того при таком уровне разбора?

    Результат работы программиста не код, а решенная задача.
    • 0
      Зная о наличии сервисов высоким уровнем качества по 10 копеек за запись

      С неизвестным уровнем качества, будем честными.
      • 0
        Ну почему же?
        Уважающие себя сервисы предоставляют демо версии и демо аккаунты. Некоторые даже пишут парсеры демо страниц и через них строят разбор адреса. =)
        Можно сравнить свой разбор и предлагаемый.
        • 0
          Вот именно, что можно сравнить. После этого можно будет говорить о качестве сервиса. После, а не до.
          • 0
            Сейчас средний уровень коммерческих сервисов 95-99% от возможного разбора.
            Обрабатывают даже ситуации "… зеленая дверь налево, звонить три раза, спросить разведчика Исаева"
            • 0
              Поживем — увидим. Результаты своего тестирования одного такого специализированного сервиса я показывал выше.
              • 0
                20-30% это кто ж так разбирает? еще и за деньги.
                ИМХО в лидерах сейчас post-address.ru/ и dadata.ru/
                C обоими знаком, но не одних не работаю.
                Некоторые интеграторы пишут свои модули на различных Data Quality решениях, но пока до 90% добрались единици
                • 0
                  20-30% это кто ж так разбирает? еще и за деньги.

                  К сожалению, не могу сказать.

                  ИМХО в лидерах сейчас post-address.ru/ и dadata.ru/

                  Мы планировали их тестировать для своих задач, но пока не начали.
                  • 0
                    Если не затруднит вывод в личку киньте после тестов. В своё время проводил сравнение IQ, HF, и двух решений которые не выжили на рынке.
                    Интересно как изменилась ситуация за 5 лет.
    • 0
      1. Да, это мотив!
      2. Я и есть программист :)
      Не факт, что уровень качества сервисов за 10 копеек высок. Я просто отметил их наличие, но не регистрировался и не проводил тесты. Были еще сервисы за 70 копеек. Возможно, между ними есть разница.
      Потратил я как раз один день (точнее, вечер), на реализацию, и еще один — на доводку, тестирование и эту статью.
      3. Задача заказчиком была утверждена именно так: «распознавать как-нибудь, без дополнительной оплаты за парсинг каждого адреса». Вариант с внешним сервисом, разумеется, предлагался.

      С таковой точки зрения задача решена.
      • 0
        1. Согласитесь, тема не так проста как выглядит на первый взгляд. Если долго всматриваться там видны и нейронки и генетические алгоритмы=)
        2. Относительно цен. Качество — цена не имеет корреляции. Те кто делают дешевле чаще всего выезжают на объемах.
        Относительно сроков реализации — производительно для такой задачи.
        3. Заказчик странно относится к данным. Видимо постановка такая была от «бизнеса»
        • 0
          1. Тема ни разу не простая, поэтому я постарался как можно больше рассказать о недостатках такого «наколенно-однодневного» решения. С другой стороны, какое-то решение чаще все же лучше, чем никакого.
          Нейросети, возможно, смогли бы оказаться полезными в классификации уровня адресного элемента (область, район, город, улица, дом, корпус, квартира) по рядом лежащим словам-подсказкам. Я с ними совсем не работал, поэтому, спасибо за наводку, попробую при наличии свободного времени поэкспериментировать. Но опять же, потом нужна будет фактическая база, по которой придется пробивать почтовый индекс. Ибо вряд ли получится обучить сеть экстраполировать индексы. :)
          А вот чем тут могут помочь генетические алгоритмы?

          2. Не стану спорить. Нужны тесты.

          3. Это не ключевая для бизнеса функция. Поэтому так и относится.
          • 0
            1. Фактическая база — тот же ФИАС и различные почтовые и прочие базы для набора критической массы. Как в интервью сказал один из разработчик такой системы «после 80-90 % каждый следующий процент требует ровно столько усилий сколько было приложено до этого».
            +
            Есть же еще, т.н. «обратная ошибка», т.е. адрес разобран и помечен как правильный, а он не верно был разобран и указывает совершенно другую точку в пространстве.

    • 0
      Вы так пишете о сервисах за 10 копеек, как будто ими весь рунет завален :-) Я только один знаю.
      • 0
        Ну почему же один. Ваш и конкурентов=) это минимум.
        Наверняка есть умельцы кто еще не вышел на большой рынок, а работает локально
        • 0
          Да, конкурентов я знаю много, а вот 10 копеек за запись только у нас :-) Черт, это нескромно.
  • 0
    Не понял из статьи, была ли решена бизнес-задача, заказчика устроили результаты парсинга?

    Еще интересно, о каком количестве адресов шла речь.

    P.S. «жадно пялились онлайн-сервисы… за вполне реальную мзду» — это прекрасно. Да как они посмели!
    • 0
      Заказчика результаты парсинга устроили, так что можно сказать, данная задача была решена.
      Объемы адресов: периодически (примерно один раз в неделю) по 50-100 штук.

      PS. Вот-вот! Нахалы, да и только! :)
      А если серьезно, я не против подобных сервисов совсем. Опечалило лишь отсутствие открытых альтернатив (пусть и худшего качества).
      • +1
        Прелестно.
        1. Пересчитайте свои трудозатраты в количество недель обслуживания «нахальных сервисов». Хватило бы на годы =)
        2. Можно просто прогонять через демо аккаунты объемы позволяют=)
  • 0
    Вы потратили время своей жизни на то, чтобы некачественно воспроизвести сервис dadata.ru. Я не понимаю мотивацию вашей работы.

    Не хочется отдавать добровольно доходы?
    Сколько стоит ваш час? Умножьте его на количество часов, потраченные на разработку алгоритма. Теперь сравните с 10 копеек за запись. Каков результат?

    Появился некий азарт
    Есть еще столько нерешенных интересных проблем в мире в области софта, почему вы не используете свой азарт для них?
    • +1
      Каков результат?

      Личное удовлетворение, деньги в кармане от заказчика, пусть хреновая, но доступная желающим реализация.

      почему вы не используете свой азарт для них?

      Очень хороший вопрос. Надеюсь, человек все еще может заниматься тем, чем он хочет?
      • 0
        Я спрашивала про результат в денежном выражении. Это оказалось выгодней, чем 10 копеек за адрес или нет? Если по вашей часовой ставке?

        Безусловно, вы можете заниматься чем хотите. Интересна мотивация писать то, что уже написано для вас. Зачем писать очередную «пусть хреновую» реализацию? Это перекликается с вопросом про деньги, мне прежде всего интересно, сэкономили ли вы :)
      • 0
        И еще интересна бизнес-задача, для которой нужно «невысокое качества парсинга» с алгоритмом, ошибающимся в случайных местах. Поделитесь или это секрет?
    • 0
      С чего вы решили, что dadata.ru обрабатывает адреса корректно? Я во время тестов отправил им с десяток разных адресов, которые они обрабатывали не правильно. Простой пример, про который я им говорил месяца 3 назад: берем ИХ-ЖЕ почтовый адрес со страницы dadata.ru/about/, загоняем к ним и видим, строение и этаж не определились.

      Я не против dadata.ru, наоборот — очень полезный инструмент. Но все-таки пишу свой велосипед, в более-менее свободное время. Это полезно для развития, потенциально выгодно для компании, в которой работаю, интересно, в конце-концов…
      • 0
        Было бы очень интересно почитать про Ваш подход к работе с адресами, мне кажется, это было бы очень интересно и всему сообществу.

        P.S.: по поводу адреса с сайта дадаты — это наша боль:) Мы не умеем нормально работать с бизнес-центрами, воспринимаем их как мусоррную информацию и не учитываем в разборе. В том числе некорректно работаем когда бизнес-центры расположены внутри домового расширения: попробуйте разместить название БЦ в другом месте предложения и получите корректный разбор. В основном такое поведение продиктовано бизнесом (мы исходим от адресов, которые чаще встречаются у заказчиков), но перфекционизм не даёт покоя, и, надеюсь, что в этом году мы ещё всех удивим.
        Если Вы отправили нам адреса с неправильным разобром, то отдельное Вам спасибо, мы их учитываем при разработке новой версии адресного парсера.
        • 0
          Обязательно напишу, как только доделаю до такого качества, которое устроит меня. По прикидкам — осталось не много, как получится на деле — кто-же знает).
          Но мне странно видеть, что определение корпуса/строения/этажа зависит от названия и, тем более, местоположения в строке определенного набора букв. Видимо, у нас абсолютно разные подходы.

          Из последних неправильных адресов (так и не поправили):
          — 6 рощинский 2
          — Пахра дом отдыха пгт Подольский р-н, Заводская ул, д. 19
          — Нижний Новгород, ул.Веденяпина, 2Б, ТЦ «Парк авеню»
          — Воронеж, ул.Дмитрова, д.47 (Литер А, 1 этаж, номер на поэтажном плане:3,5-9,12-26)'

          и т.д. Это все реальные адреса курьерских служб.
          • 0
            Да, этими адресами мы занимаемся. Мы сейчас работаем над совершенно новой версией парсера, куда включаем сложные кейсы вроде представленных вами, так что в скором будущем почти всё будет обрабатываться правильно.
          • 0
            Кстати, а что странного в определении домовой части в зависимости от месторасположения в строке? Вы же сами приводите пример такой зависимости: 6 рощинский 2. Смотрите сами:
            Москва 6 рощинский 2 = Москва 6-ой Рощинский проезд дом 2
            Москва 2 рощинский 6 = Москва 2-ой Рощинский проезд дом 6
            • 0
              Позиции чисел необходимо учитывать, без этого никак. Я говорил про местоположение в строке определенного набора букв, т.е. названия бизнес-центра, например.
              • 0
                Просто обычно доп информация добавляется сбоку от адресного компонента, но не внутри него. Вот пример от заказчика:
                — 3-я Мытищинская улица, 14а Москва 3
                Справа добавлена доп информация с числом, по Вашей логике следует разбирать адрес как дом 14а квартира 3, тогда как на самом деле речь про дом 14а, который находится рядом со станцией Москва-3.
                • 0
                  По моей логике будет «Москва, 3-я Мытищинская улица, дом 14а». Квартиры тут нет, т.к. нет указания на квартиру и число 3 идет не сразу за номером дома.
                  • 0
                    А как Вы определяете квартиру? Основываясь на своём опыте, могу сказать, что обозначение квартиры далеко не всегда присутствует. Плюс интересно какое число считать за квартиру: слева или справа от обозначения. Например,
                    Улица Мытищинская 3-я 3 кв 1 и Улица Мытищинская 3-я 3 1 кв — одно и то же?
                    а Улица Мытищинская 3-я 3 к 1 — тут про корпус или квартиру?
                    Часто можно понять о чем идет речь только исходя из порядка следования элементов в домовой части
                    • 0
                      Улица Мытищинская 3-я 3 кв 1 и Улица Мытищинская 3-я 3 1 кв — одно и то же?

                      Да. В первом случае есть явное указание, во втором числа идут рядом, о чем говорил выше.

                      а Улица Мытищинская 3-я 3 к 1 — тут про корпус или квартиру?

                      Корпус.

                      Часто можно понять о чем идет речь только исходя из порядка следования элементов в домовой части

                      Не, по моему опыту как-раз нельзя исходить из этого. В одних системах прямой порядок, в других обратный, в третьих случайный, в зависимости от настроения оператора колл-центра.
                      • 0
                        Понятно, спасибо!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.