В этой статье наш ГИС-заказчик – это компания, которая работает в сегменте B2B (Business-to-Business. Это сегмент рынка, где компания-поставщик услуг работает с клиентами - юридическими лицами), поэтому мы акцентируем свое внимание на поиске не конкретных людей, а возможных адресов новых клиентов. Компания также использует веб-ГИС для ведения своих геоданных.
Смежное пожелание к поиску новых клиентов в контексте заказчика – подключение клиентов должно быть минимально по стоимости и задействовать только уже имеющуюся инфраструктуру.
Зачастую именно так и выглядят первые формулировки заявок. Давайте подумаем, достаточно ли этого знания для получения решения или нам потребуется сделать несколько итераций для достижения результата.
Итерация 1
Итак, на входе у нас уже есть:● цель: адреса. Значит, выходными данными будет набор зданий с атрибутом “адрес”, откуда мы можем или просто выгрузить перечень адресов, или же отобразить на карте нужные заказчику здания;
● исходные данные: объекты заказчика. Следовательно, на вход алгоритму будем подавать слои с объектами заказчика;
● критерии поиска: минимальная стоимость соединения инфраструктуры заказчика и найденного адреса. Соответственно, наш алгоритм будет похож на задачу поиска зон доступности и выявления зданий внутри этих зон.
Далее рассмотрим каждый пункт и зададим к ним вопросы. Это поможет взглянуть на наши исходные данные с точки зрения конкретной задачи и выявить, чего нам может не хватать, а также потребуется ли выполнять дополнительные действия с данными.
Получение зданий с адресами. До этой заявки заказчику было достаточно отображать свои объекте на карте-подложке. Теперь нам нужно найти векторный файл зданий, где будут указаны адреса. В целом, это задача посильная: можно взять данные OpenStreetMap и собрать компоненты адреса в один атрибут, или можно заказать такой слой у поставщиков геоданных. Просто отмечаем себе, что нам потребуется решить этот вопрос. В нашем случае заказчиком был выбран вариант использования данных OpenStreetMap. Следовательно, мы подготавливаем слой зданий в соответствии с выявленным требованием.
Слои с объектами инфраструктуры заказчика. Для этого пункта нам важно посмотреть, есть ли атрибуты, важные для выбора конкретных объектов, и насколько корректно они заполняются сотрудниками. Да, для случаев, когда мы реализовываем ГИС-проекты для самостоятельной работы с геоданными сотрудниками заказчика, требуется время от времени проводить аудит геоданных. И не всегда данные заполняются правильно:
● остаются незаполненные атрибуты – причем в большом количестве;
● вносимые текстовые значения содержат большое количество опечаток;
● объекты наносятся с погрешностью;
● и прочее.
И на этой стадии нам важно понять, подходит ли текущее состояние геоданных заказчика для решения задачи. И если нет, то потребуется искать пути исправления (и это уже совсем другая история…)
В рамках статьи будем считать, что геослои заказчика содержат все необходимые данные в допустимом качестве.
Определение критериев поиска. Можно сразу сказать, что для нашей задачи должны возникнуть вопросы:
● что означает стоимость подключения?
● нам надо найти некие зоны доступности, которые обычно рассчитываются на основании близости. Поэтому надо понять: что такое “близость” в нашем случае?
Подрядные ГИС-специалисты не могут самостоятельно принять решение по этим вопросам, так как ответы находятся в плоскости бизнес-процессов самого заказчика. Мы максимум можем предложить существующие в геоинформатике варианты расчета расстояний, чтобы заказчик мог “примерить” эти способы к своим бизнес-процессам.
После проведения такого анализа первичного запроса, мы снова обращаемся к заказчику для уточнений.
Итерация 2
Мы задали вопрос: что значит “близкие” к объектам инфраструктуры здания?Полученный ответ: это здания в том же квартале, что и объекты инфраструктуры. “Строительство” соединений между кварталами сильно увеличивает стоимость подключения нового клиента.
Из такого ответа делаем следующие уточнения:
● нужен слой городских кварталов,
● для выборки нужных адресов необходимо найти те кварталы, где есть объекты заказчика,
● для получения результатов потребуется найти все входящие в квартал здания.
Формируем схему алгоритма и проводим опытный анализ на отдельном участке, чтобы окончательно согласовать модель обработки с заказчиком.
Глядя на итог, возникает вопрос: действительно ли данный подход в полной мере отвечает задаче? Ведь есть кварталы разной площади и те, где объекты инфраструктуры сосредоточены в какой-то одной части квартала. Получается, что до части зданий потребуется “строить” более длинные подключения – это опять-таки приводит к увеличению стоимости.
Тем не менее с полученным результатом и своими комментариями мы обращаемся к заказчику. И тут случилось непредвиденное, хотя и не самое редкое событие… у нас поменялся представитель заказчика, отвечающего за данную задачу. Нас перенаправили к другому сотруднику, у которого иной взгляд на задачу.
Итерация 3
Теперь “близость” понимается по-другому: требуется найти те здания, которые расположены на расстоянии N метров от объектов инфраструктуры.Меняем подход:
● нужно построить буферы на расстоянии N метров, что, по сути, более привычное требование с точки зрения “близости”,
● для получения результатов потребуется найти все входящие в буферный слой здания.
Формируем схему алгоритма и снова проводим опытный анализ на отдельном участке для согласования с заказчиком.
Снова оцениваем результат. Да, он выглядит более привычно для ГИС-специалиста, и найденные здания действительно могут быть ближе к объектам инфраструктуры заказчика в зависимости от размера буфера. Но предыдущий сотрудник акцентировал наше внимание на большую стоимость “строительства” подключения между кварталами.
Итерация 4
Поэтому мы самостоятельно продумали еще один вариант – гибрид между двумя ранее озвученными вариантами “близости”.
Получилось следующее:
● нужно построить буферы на расстоянии N метров,
● нужен слой городских кварталов,
● нужно разрезать кварталами буферный слой и оставить только те части буферов, в которых есть объекты инфраструктуры. Получаем требуемые зоны подключений,
● для получения результатов потребуется найти все входящие в зоны подключений здания.
Такой вариант включает в себя плюсы обоих мнений представителей заказчика и позволяет учесть критерий по минимизации стоимости подключения.
Примечание: мы решали задачу для заказчика на территории Санкт-Петербурга, славящегося своими реками и каналами. Поэтому водные объекты также являются барьерными элементами для определения зон доступности, и при построении алгоритма требуется их учитывать аналогично основным улицам между кварталами и железнодорожным путям.
ГИС-специалисты могут самостоятельно дополнять исходное техзадание условиями использования вспомогательных данных. Часто представители бизнес-заказчика могут забыть учесть такие объекты, так как фокусируются преимущественно на своих объектах и процессах.
Такой проактивный подход помогает экономить свои трудозатраты и обеспечивать более устойчивое решение.
Теперь мы можем представить заказчику все варианты, чтобы обсудить, какой из них станет итоговым и ляжет в основу последующего создания скрипта, выполняющегося по расписанию без участия человека.
В качестве выводов можем сказать, что важно:
● критически относиться к заявкам заказчика (позиция “клиент всегда прав” работает далеко не всегда);
● максимально конкретизировать требования задачи;
● уметь посмотреть на данные с разных сторон, в том числе и со стороны применимости к задаче и оценки допустимой точности и качества;
● выявлять плюсы и минусы получаемых решений.
И не надо бояться предлагать заказчику гибридные алгоритмы, если вы видите, что они могут учесть максимальное число плюсов всех рассмотренных вариантов. Таким образом мы все вместе сможем создавать и внедрять полезные продукты, учитывающие разные мнения для оптимизации и автоматизации бизнес-процессов.