- Общий
-
Вопросы
Возвращаемое значение source отличается от переданного
При массовой обработке адресов через Стандартизацию, возвращаемое значение source отличается от переданного. Происходит своего рода "нормализация" строки.
Передаем адрес типа "Архангельская(тут МНОГО пробелов)область, (прочие части адреса)"
Возвращается ответ в котором поле source "нормализован" - "Архангельская(тут остался ТОЛЬКО ОДИН пробел)область, (прочие части адреса)". В процессе "нормализации" удаляются множественные пробелы, символы табуляции, и еще некоторые неотображаемые символы (был адрес в котором вместо пробелов стоял символ с кодом 160). Ориентировочно проблема с нормализаций началась 6-7 июля, до этого адреса с множественными пробелами возвращались неизмененными.
При автоматизированной массовой обработке адресов - определять какой ответ для какого адреса вернулся стало проблематично.
Если это стало стандартов в возвращаемом результате - подскажите - какие еще правила применяются при "нормализации" адреса запроса.
Спасибо.
Ответ
Коллеги, добрый день.
Действительно, в этих числах мы обновили сервис. Теперь мы преобразуем последовательные пробелы, символы перевода строки, возврата каретки, а также некоторые 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
Коллеги, добрый день.
Действительно, в этих числах мы обновили сервис. Теперь мы преобразуем последовательные пробелы, символы перевода строки, возврата каретки, а также некоторые UTF-символы в одиночный пробел.
Сделали это из соображений производительности и надежности.
По поводу правил – мне кажется, не очень имеет смысл их приводить, потому что мы можем их в любой момент изменить, и вы об этом не узнаете, или узнаете с опозданием. Мы рекомендуем добавить в исходные данные ID записи, чтобы сопоставлять данные по ней. Так вы не будете зависеть от особенностей ответа API. И это менее затратное для вас решение задачи, чем подгонка результатов под правила каждый раз.