0
Отвечен

Возвращаемое значение source отличается от переданного

I T. 8 лет назад обновлен Антон Жиянов 8 лет назад 3

При массовой обработке адресов через Стандартизацию, возвращаемое значение source отличается от переданного. Происходит своего рода "нормализация" строки.

Передаем адрес типа "Архангельская(тут МНОГО пробелов)область, (прочие части адреса)"

Возвращается ответ в котором поле source "нормализован" - "Архангельская(тут остался ТОЛЬКО ОДИН пробел)область, (прочие части адреса)". В процессе "нормализации" удаляются множественные пробелы, символы табуляции, и еще некоторые неотображаемые символы (был адрес в котором вместо пробелов стоял символ с кодом 160). Ориентировочно проблема с нормализаций началась 6-7 июля, до этого адреса с множественными пробелами возвращались неизмененными.


При автоматизированной массовой обработке адресов - определять какой ответ для какого адреса вернулся стало проблематично.


Если это стало стандартов в возвращаемом результате - подскажите - какие еще правила применяются при "нормализации" адреса запроса.

Спасибо.


Ответ

Ответ
Отвечен

Коллеги, добрый день.

Действительно, в этих числах мы обновили сервис. Теперь мы преобразуем последовательные пробелы, символы перевода строки, возврата каретки, а также некоторые UTF-символы в одиночный пробел.

Сделали это из соображений производительности и надежности.


По поводу правил – мне кажется, не очень имеет смысл их приводить, потому что мы можем их в любой момент изменить, и вы об этом не узнаете, или узнаете с опозданием. Мы рекомендуем добавить в исходные данные ID записи, чтобы сопоставлять данные по ней. Так вы не будете зависеть от особенностей ответа API. И это менее затратное для вас решение задачи, чем подгонка результатов под правила каждый раз.

Ответ
Отвечен

Коллеги, добрый день.

Действительно, в этих числах мы обновили сервис. Теперь мы преобразуем последовательные пробелы, символы перевода строки, возврата каретки, а также некоторые UTF-символы в одиночный пробел.

Сделали это из соображений производительности и надежности.


По поводу правил – мне кажется, не очень имеет смысл их приводить, потому что мы можем их в любой момент изменить, и вы об этом не узнаете, или узнаете с опозданием. Мы рекомендуем добавить в исходные данные ID записи, чтобы сопоставлять данные по ней. Так вы не будете зависеть от особенностей ответа API. И это менее затратное для вас решение задачи, чем подгонка результатов под правила каждый раз.

Коллеги,


Правильно ли я понял ваши рекомендации:

- адрес для поиска будет выглядеть "ID=1234 Архангельская(тут МНОГО пробелов)область, (прочие части адреса)"

- в ответ будем получать "ID=1234 Архангельская(тут остался ТОЛЬКО ОДИН пробел)область, (прочие части адреса)"

- и справнивать запрос- ответ по ID=1234

Не совсем так.


Тут два момента. Первое: не совсем понимаю, в чем проблема сопоставить, какой ответ для какого адреса вернулся. Сервис стандартизации работает синхронно. Соответственно, всегда понятно, какой результат вернулся для какого адреса. Пример (псевдокод):

for source_addr in address_list:
  result_addr = clean(source_addr)
  save(source_addr, result_addr)

Явно есть пара (source_addr, result_addr) и понятно, что result_addr — это результат стандартизации для source_addr.


Второе: если по каким-то причинам хочется иметь в ответе явный идентификатор адреса, используйте метод https://dadata.ru/api/v2/clean вместо https://dadata.ru/api/v2/clean/address. Пример запроса с ID:

{
  "structure": [
    "AS_IS",
    "ADDRESS" ],
  "data": [
    [ "1024",
      "Москва, Норильская улица, 17 кв 25"
    ]
  ]
}

Ответ:

{
  "structure": [
    "AS_IS",
    "ADDRESS"
  ],
  "data": [
    [
      {
        "source": "1024"
      },
      {
        "source": "Москва, Норильская улица, 17 кв 25",
        "result": "г Москва, ул Норильская, д 17, кв 25",
        ...
      }
    ]
  ]
}

Сервис поддержки клиентов работает на платформе UserEcho