ДАТАМАП-ЕВРОПА разработи и демонстрира прототип на продуктова иновация в геопозиционирането

Проектът

Целта на проекта беше да бъде разработен значително подобрен софтуер за геопозициониране – нова версия на уеб-базираната адресна услуга DataMap Address Service, която да разпознава и позиционира географски адреси, с които наличните на пазара решения не се справят. Проектът беше изпълнен по процедура BG16RFPR001-1.001 „Разработване на иновации в предприятията“, договор BG16RFPR001-1.001-0314-C01. Разработката премина през четири последователни нива на технологична готовност – от TRL 3 до TRL 6 – и беше изпълнена изцяло от деветчленен екип на компанията.

Проблемът, който иновацията решава

Адресните системи в България и в останалите бивши социалистически страни носят следите на десетилетия промени. След политическите промени в края на 80-те и началото на 90-те години бяха преименувани масово улици, квартали и дори населени места. Едновременно с това градовете се разраснаха и присъединиха съседни територии и селища. Така се появиха дублирани имена на улици, преименувани обекти и адреси, които са били валидни, но днес не съществуват в една актуална база данни. Процесът продължава и днес: за последните 35 години в София са преименувани над една четвърт от улиците, а във Варна за последните години са именувани над 200 нови улици.

Последиците са реални за всеки, който работи с адреси. Лични карти, документи за собственост, банкови и застрахователни договори съдържат адреси, които са били изписани вярно към момента на създаването си, но днес не могат да бъдат открити на картата.

Петте иновативни признака

1. Стари адреси. Разпознаване на стари имена на населени места, квартали, улици и блокове, както и на променени номера на сгради, и намиране на съответния актуален адрес, като се показват и двата.
2. Напълно дублирани адреси. Анализ и разпознаване на адреси, получени при присъединяване на част от една улица към друга, без да се промени номерацията в съответния участък.
3. Блокове със собствени имена и буквено-цифрени обозначения. Разпознаване и геолокиране на жилищни блокове с имена, както и на блокове и улични номера с буквено-цифрени комбинации, например „151А“, бл. „Потсдам“
4. Обекти с напълно съвпадащи имена. Разграничаване на улици, булеварди, квартали и местности с еднакви имена в едно населено място по контекста на адреса.
5. Адреси, които не следват правилото „улица + номер“. Разпознаване и геопозициониране на валидни адреси от вида  квартал и номер, селище и име на блок, както и адреси със селище и номер.

Защо е нужна иновацията

Етапите на разработване

Разработката продължи 18 месеца и премина през четири последователни нива на технологична готовност – от експериментална проверка на идеята до демонстрация на цялостната система в реални условия. Всяко ниво завършваше с проверка на постигнатото, преди да започне следващото. Работата беше изпълнена от деветчленен екип: ръководител информационни и комуникационни технологии, ръководител на екипа програмисти, програмист, ръководител на звеното картографи, четирима картографи и експерт по технологично поддържане. Съчетанието на програмисти и картографи беше съществено, защото повечето трудни адреси не са само програмен проблем, а изискват и познаване на историята и особеностите на адресната система.

TRL 3 – Концепция, доказана с експеримент

Какво беше направено. Първата стъпка беше да се разбере в детайли защо стандартните системи не разпознават определени адреси. Екипът събра и анализира натрупания практически опит от предходните версии на услугата и от реални казуси, постъпили от клиенти. Основно внимание беше обърнато на случаите със стари, дублирани или нестандартно изписани адреси. Създадена беше вътрешна база знания с типовите проблеми, начините за решаването им и особеностите на адресните формати в различните населени места. Честите грешки и неточности в адресните заявки бяха категоризирани – дублирани имена, липсващи или неправилно изписани елементи. Работата на услугата беше сравнена и с алтернативни световни решения, за да се видят техните предимства и слабости.

Какво беше установено. Анализът потвърди, че проблемните адреси се групират в пет ясно разграничими вида и всеки от тях изисква собствен подход. Един общ алгоритъм за всички адреси не би могъл да ги обработи надеждно. Стана ясно също, че без връзки между старите и актуалните адреси в базите данни разпознаването на исторически адреси е невъзможно.

Резултат. Концепцията за всяка от петте функционалности беше проверена експериментално с реални адресни казуси. Беше направена първоначална оценка, че решението е постижимо, и беше определена основата на бъдещата софтуерна архитектура.

TRL 4 – Технология, валидирана в лаборатория

Какво беше направено. Беше изготвена детайлна софтуерна архитектура, а алгоритмите бяха валидирани чрез ръчно асистирано тестване. Следваше детайлен технологичен план, който определи последователността на реализацията на етапи – от приемането на адреса до определянето на крайния резултат. Планът беше разделен на седем взаимосвързани работни процеса с ясни отговорности за всеки член на екипа и с контролни точки, в които програмната работа и подготовката на адресните данни се синхронизираха. Програмните модули бяха разработени поетапно и качени на тестов сървър. За картографите бяха създадени специални тестови приложения, в които те проверяват резултатите и сравняват очаквания с действителния отговор на системата.
За проверката беше подготвен представителен тестов набор от адреси в шест групи – по една за всяка от петте особености и една с реални клиентски адреси. Всеки адрес беше включен както в автентичния си вид, така и в различно „зашумени“ варианти, например със съкращения, пропуснати елементи или разместен ред. За всеки адрес картографите предварително определиха верния резултат. Тестването беше непрекъснато: след добавянето на всяка нова функционалност тя се проверяваше самостоятелно, в съвместна работа с останалите и спрямо целия набор от вече изпитани случаи.

Какво беше установено. Функционалното верифициране разкри отклонения, които бяха възпроизведени и разделени по причина. Една част бяха програмни грешки, а друга – неточности в адресните данни и номенклатурите, които изискваха картографска проверка. След всяка корекция засегнатите тестове бяха повторени, а наборът за повторна проверка беше допълнен с откритите гранични случаи.

Резултат. Специализирано становище потвърди, че необходимите корекции са изпълнени и че не се налага промяна на архитектурата. Потвърди също, че и петте вида адреси са обхванати от специализираната обработка и проверките. Технологията беше валидирана в лабораторни условия и готова за следващия етап.

TRL 5 – Технология, валидирана в релевантна среда

Какво беше направено. Системата беше валидирана поетапно на три нива: отделните компоненти, връзките и интерфейсите между тях и системата като цяло. Беше изготвена финална техническа и потребителска документация. Тя описва и новия начин, по който услугата съобщава резултата: еднозначно разпознат адрес, няколко възможни съвпадения, липса на съвпадение, невалиден вход или технически отказ. Разработените функционалности бяха пренесени в производствената среда на компанията при контролирани условия, отделно от текущото обслужване на клиентите. Като входни данни бяха използвани архивирани реални клиентски заявки, включително такива, при които клиентите в миналото са получили непълен или неподходящ резултат. Работата на системата беше проследявана чрез автоматичен контрол и ръчен преглед на записите (логовете) на приложението.

Какво беше установено. Тестовете с реални данни потвърдиха ползата от изпитването извън лабораторията. Беше открит вид адреси, който не присъстваше в лабораторния набор – улици и квартали с числови имена, например „41-ва“, „Първа“ или „64“. При тях числовото име може погрешно да бъде прието за номер на сграда, а адресът – да бъде разпознат грешно. Отклоненията бяха документирани и коригирани.

Резултат. Проблемът с числовите имена беше решен в рамките на съществуващата архитектура. Коригираната версия беше инсталирана на сървър в производствената среда и целият процес на тестване беше преминат отново, без нито една от вече работещите функционалности да бъде засегната. Резултатите бяха финално валидирани спрямо предварително определени критерии. Беше потвърдено и че са възпроизводими – при същата версия на програмата и данните системата дава същия отговор.

TRL 6 – Технология, демонстрирана в релевантна среда

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

Какво беше установено. Всички резултати бяха събрани в единен регистър и класифицирани по причина: потвърдено правилно поведение, допустима нееднозначност, програмно отклонение, неточност в адресните данни, неудачно представяне на сигнала към оператора или ограничение на входните данни. Така всеки проблем беше насочен към правилното решение. Програмните отклонения бяха поправени с допълнително програмиране, неточностите в данните – с картографски корекции, а сигналите към оператора бяха прецизирани така, че да са по-ясни и по-бързи за обработка. Регистрирани бяха и отделни силно зашумени адреси, изписани смесено на кирилица и латиница, с множество грешки в имената. Те представляват самостоятелен проблем, различен от петте особености, които решава иновацията, и са определени като насока за бъдещо развитие на услугата.

Резултат. След всяка корекция конкретният реален случай беше проверен отново, а петте вида адреси – повторно изпитани, за да се гарантира, че подобрението не влошава останалите резултати. Системата беше фино настроена, а работният процес на оператора – оптимизиран. Накрая беше окомплектована цялостната техническа документация на иновацията, която проследява разработката от първоначалната концепция до демонстрацията в реални условия.

Решенията, до които доведе разработката

• Специализирана обработка за всеки проблемен вид адрес. Вместо един общ алгоритъм за всички адреси, в прототипа беше реализирана отделна логика за всяка от петте особености, в рамките на многоетапен аналитичен поток.
• Връзки между стари и нови адреси. Адресните бази данни бяха допълнени с връзки, които позволяват на исторически валиден адрес да бъде намерен неговият актуален еквивалент.
• Честен резултат при нееднозначност. Когато адресът може да има няколко значения, прототипът връща подредени възможности и пояснение, а не привидно точен, но грешен отговор. Резултатът изрично съобщава състоянието си: еднозначен резултат, няколко възможни съвпадения, липса на съвпадение, невалиден вход или технически отказ.
• Непрекъснато регресионно тестване. Всяка нова функционалност и всяка корекция беше проверявана спрямо целия набор от тестови случаи, така че подобрението на един вид адреси да не влошава разпознаването на останалите.
• Работен процес за оператора. Нееднозначните случаи се сигнализират и маркират директно в уеб приложението.

Постигнатите резултати

• Разработена беше цялостна софтуерна система, която включва функционалностите и по петте иновативни признака и коригираните интерфейси на уеб приложението.
• Системата беше демонстрирана в производствената среда на компанията с реални адреси и казуси от текущия работен процес, подадени без предварителна обработка.
• В тестовете на всички нива бяха обхванати и петте групи адреси, към които по време на разработката беше добавен и класът на улиците и кварталите с числови имена, открит при тестовете с реални заявки.
• Установените отклонения бяха отстранени в рамките на приетата архитектура, без необходимост от нейната промяна, а повторните и регресионните проверки потвърдиха, че корекциите не са засегнали вече работещите функционалности.
• Резултатите бяха финално валидирани спрямо предварително определени критерии и потвърдени като възпроизводими.
• Беше изпитан и оптимизиран целият операторски процес в уеб приложението – потвърждение, избор между кандидати и корекция на резултата.
• Беше окомплектована цялостната техническа и потребителска документация на иновацията.

Следващи стъпки

Информация за проекта

„Тази публикация е създадена с финансовата подкрепа на програма „Конкурентоспособност и иновации в предприятията“ 2021-2027, съфинансирана от Европейския съюз чрез Европейския фонд за регионално развитие. Цялата отговорност за съдържанието на публикацията се носи от ДАТАМАП-ЕВРОПА ООД и при никакви обстоятелства не може да се приема, че този документ отразява официалното становище на Европейския съюз и Управляващия орган.“