Геокодирането – превръщането на текстов адрес в точни географски координати – изглежда решена задача, докато не се сблъска с адресните системи в България. Преименувани улици, дублирани имена, блокове с имена вместо номера и адреси без улица са ежедневие за всеки, който обработва адресни данни. Повечето световни услуги за геопозициониране обаче са изградени при допускането, че адресът е актуален, следва формата „улица + номер“ и името на улицата е уникално в рамките на населеното място.

Точно към решаване на тези проблеми е насочен проектът „Разработване на продуктова иновация – значително подобрен софтуер за геопозициониране и уеб-базирана адресна услуга“, който „ДАТАМАП-ЕВРОПА“ ООД изпълни в периода 07.03.2025 – 07.09.2026 г. по Програма „Конкурентоспособност и иновации в предприятията“ 2021–2027. В рамките на 18 месеца екипът на компанията разработи прототип на значително подобрена версия на уеб-базираната адресна услуга DataMap Address Service и го доведе до ниво на технологична готовност TRL 6 – технология, демонстрирана в релевантна среда.

Защо стандартните геокодери грешат

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

Преди старта на проекта компанията провери как се справят с подобни адреси три от най-използваните решения за геопозициониране – две глобални комерсиални картографски услуги и една отворена картографска платформа. Тестовете с идентични сценарии показаха, че нито едно от тях не поддържа история на адресите и не разпознава валидни стари адреси. При напълно дублираните адреси и трите връщат само една от двете сгради, а при обектите с еднакви имена и при адресите извън формата „улица + номер“ резултатът е неточен съответно средно в над една пета от случаите. Нито едно решение не съчетава обработката на всички тези случаи, което определи иновацията като новост на световно ниво в своята област.

Замисълът: пет иновативни признака

Анализът на реални клиентски заявки показа, че проблемните случаи се групират в пет ясно разграничими вида, които станаха петте иновативни признака на разработката. Първият са старите имена на населени места, квартали, улици и блокове и променените номера на сгради, за които трябва да бъде намерен актуалният адрес. Вторият са напълно дублираните адреси – те възникват, когато част от една улица е присъединена към друга, без да се промени номерацията, и така две различни сгради получават един и същ адрес. Третият са жилищните блокове със собствени имена и обозначенията с буквено-цифрени комбинации като „151А“ или блок „Перун“. Четвъртият са различни обекти с напълно съвпадащи имена – улици, булеварди, квартали и местности в едно и също населено място. Петият са валидните адреси, съставени различно от правилото „улица + номер“. Всеки от тези видове изисква собствена логика, а един универсален алгоритъм за съпоставяне не може да ги разреши надеждно.

Подходът, реализиран в прототипа

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

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

Как беше разработен и изпитан

Работата беше изпълнена от деветчленен екип от програмисти, картографи, ръководители и експерт по технологично поддържане и премина през четири нива на технологична готовност.

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

На ниво TRL 4 беше изготвена детайлна архитектура и технологичен план, разделен на седем работни процеса – от общия модел на данните и подготовката на номенклатурите до нормализацията, специализираната валидация, подреждането на кандидатите и интеграцията чрез API. Програмните модули бяха разработени поетапно и качени на тестов сървър, а за картографите бяха създадени тестови приложения за проверка на резултатите. Лабораторното изпитване използва представителен набор от адреси в шест групи – петте групи на иновацията и група реални клиентски адреси. Всеки адрес е включен в автентичен и в различно „зашумен“ вариант, а верният резултат е определен предварително от картографите. Тестването беше непрекъснато: всяка нова функционалност и всяка корекция беше проверявана самостоятелно, в интеграция и регресионно спрямо целия набор. Етапът завърши със специализирано становище, че корекциите са изпълнени и не се налага промяна в архитектурата.

На ниво TRL 5 системата беше валидирана на три нива – компоненти, интерфейси и система като цяло – и пренесена в производствената среда на компанията при контролирани условия, отделно от текущото обслужване. Като вход бяха използвани архивирани реални клиентски заявки, включително такива, при които клиентите преди са получили непълен или неподходящ резултат, а поведението на системата беше проследявано чрез автоматичен контрол и ръчен преглед на логовете. Реалните данни разкриха клас адреси, който не присъстваше в лабораторния набор – улици и квартали с числови имена като „41-ва“, „първа“ или „64-та“, при които името лесно се приема за номер на сграда. Проблемът беше решен в рамките на съществуващата архитектура, коригираната версия беше инсталирана на сървър и целият тестов процес беше повторен без регресия.

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

Какво беше постигнато

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