Чем открыть fi фиас
ГАР БД ФИАС или очень полная БД ФИАС
01.06.2020 ИФНС опубликовала новый формат выгрузки данных
17.12.2020 Мягко намекнула, что в 2021 будет использоваться только он
01.09.2021 Это свершилось: теперь просто «полная БД ФИАС» перестала обновляться и требуется использовать ГАР БД ФИАС
Частично импортируем ГАР БД ФИАС в MySQL на PHP.
Новость, мягко говоря, не очень, для тех кому нужно получить иерархию улиц и список домов с почтовыми индексами, особенно учитывая, что КЛАДР до сих жив. А не очень из-за того, что файлик данных с 12Гб резко пополнел до 28Гб. Конечно, можно возразить, что скачал один раз и по чуть-чуть обновляйся. Да, можно, если хранить нужные файлы данных целиком и постоянно накатывать на них обновления, но. наличие багов (даже в полной версии) добавит радости.
Таблица gar_addr, ключевое поле id. Иерархию определяют указывающие на него owner_adm и owner_mun. Субъекты РФ (и Байконур) имеют level=1, owner_adm=owner_mun=0. Содержит информацию о названиях адресных объектов (NAME, TYPENAME) и говорящие за себя OKATO, OKTMO, KLADR. OBJECTGUID, ранее в ФИАС именовался AOGUID, является идентификатором адресного объекта (уникальный для актуальных записей; не уникальный, если используются исторические устаревшие записи). OBJECTID аналогичен по значению OBJECTGUID, но уже целочисленный.
Импорт и частичное описание структуры.
Всё описанное ниже реализовано в исходниках.
a) Прежде чем начать, проверим zip файл. Убедимся, что он похож на нужный нам и в нём хотя бы есть файлы as_addr_obj. для каждого интересующего нас региона.
Ранее в ФИАС был один файл со всеми регионами, теперь данные о каждом регионе в своей директории.
b) Импортируем файлы AS_ADDR_OBJ_(дата)_(идентификатор).XML, содержащие информацию об адресных объектах.
e) Проиндексируем дома по OBJECTID и убедимся, что все записи уникальны.
f,g) Настало время создать иерархию. Анализируем файлы AS_ADM_HIERARCHY_. и AS_MUN_HIERARCHY_. отбирая только актуальные записи. Пара OBJECTID и PARENTOBJID указывает на OBJECTID объекта.
В этих файлах собрана информация по всем объектам региона. В моём случае PARENTOBJID может быть только адресный объект, но реально в PARENTOBJID может быть и дом. Дочерним у него будет является, например, квартира (файлы AS_APARTMENTS_. ).
h) Проиндексируем gar_addr по owner_adm и owner_mun
ГАР, полная выгрузка
В файле AS_ADDR_OBJ_20210906_2a908987-3309-454e-9364-b75afd551e12.XML
есть объект с ISACTUAL=»1″ ISACTIVE=»1″
однако, его OBJECTID=»95254004″ вообще не встречается в AS_ADM_HIERARCHY_20210906_221e769c-cfac-4af6-9a20-04cc9c2e1fe5.XML AS_MUN_HIERARCHY_20210906_214fdb76-13c8-49cf-90ef-b5f05c4ee6df.XML
Надеяться, что дом обычно расположен на конкретной улице и owner_adm должен совпадать с owner_mun не получится. Крайне малое количество домов имеют разных владельцев, например один и тот же дом «Х»:
Башкортостан, Уфимский р-н, Зубовский с/с, д. «Х»
Башкортостан, Уфимский м.р-н, с.п. Зубовский сельсовет, тер. СНТ Авиатор, ул N1, д. «Х»
k) Настало время заполнить OKATO, OKTMO и KLADR. Информация о них в файле AS_ADDR_OBJ_PARAMS_. и надо выбрать VALUE из актуальных записей соответствующего TYPEID (6,7,11). Какие данные ещё есть в этом файле указано в AS_PARAM_TYPES_. XML
m) Удаляем вспомогательные столбцы и индексы
n,o) Выполняем слияние всех таблиц по регионам в одну общую.
p) Создаём нужные индексы
q) Переименовываем временные таблицы в нормальные имена
Чтобы получить этот результат надо обработать:
ФИАС с человеческим лицом
Всем привет. Некоторое время назад пришлось разбираться в ФИАСе, хочу поделиться своими наработками. Эта статья расскажет о том как базу развернуть, как её обновлять и как ей пользоваться.
О внутреннем устройстве таблиц ФИАС, будет другая статья.
К счастью мне не пришлось во всём разбираться самому, потому что на Хабре есть хорошая серия статей о ФИАС (Адреса ФИАС в среде PostgreSQL), и у этих статей не менее ценные коменты. На их основе у меня получилось написать скрипты и написать Докер образ, всё опубликовано на ГитХабе.
Спасибо товарищам @gladkov @QuickJoey @amakarov @ploop без вас я бы не справился..
Как работать с образом описано в README.md, здесь я распишу всё тоже самое но более подробно.
Требования
Для работы на базе Linux нужны:
Для работы на базе Windows нужны:
Не менее 200 гигабайт постоянной памяти: 8 + 90 Гигабайт для бэкапа базы ФИАС, и 80 гигабайт на собственно базу (без Земельных участков и без Докумнетов).
200 Гигабайт это минимум, конечно надо иметь в запасе хотя бы 50 Гигабайт, потому что апдейты в разархивированном виде весят по 4 Гигабайта, и конечно надо следить за свободным местом.
Как установить
Что бы развернуть базу надо иметь бэкап этой базы. Идём на сайт ФИАСа и выкачиваем полную базу в формате DBF (8 Гб).
Выбираем директорию для установки базы (в том числе набора скриптов для обслуживания базы), в этой директории разворачиваем гит репозиторий:
Для моего проекта нужны только Здания (HOUSE) и Помещения (ROOM), земельные участки (STEAD) и документы (NORDOC), мне не нужны, поэтому я их удаляю. Если вам в вашем проекте не нужны Помещения, то можно добавить их в маску поиска файлов для удаления: (STEAD|NORDOC|ROOM)
Переходим в директорию приложения
Все скрипты будут сделаны исполняемыми, будет создан docker-compose.yml
Образ разработан на основе официального, поэтому доступные опции пожалуйста смотрите в документации по ссылке.
Теперь всё готово к сборке образа и запуска контейнера:
База развёрнута, можно пользоваться.
Как пользоваться
Можно пользоваться прямо в контейнере, подключаемся к терминалу:
Конечно можно подключиться любым клиентом (любой IDE, любым другим приложением):
Пользуемся и получаем удовольствие.
Как обновить
Выкачиваем со странички обновлений, архив с обновлениями в формате DBF.
Переходим в директорию репозитория (допустим репозиторий мы развернули в директории /home/ ): cd /home/fias/
Удаляем «лишние» обновления:
Производительность
На Pentium Gold + HDD под WSL база работает очень не спеша, разворачивание занимает до 4-х часов, большое обновление занимает до 8 часов.
Разрабатывать в таких условиях конечно не продуктивно, и я попросил у админов машинку пошустрее, мне выделили:
10cpu | 18ram | 400hdd | nfs 10 раид из 16 sas дисков
На такой конфигурации затраты времени терпимые.
Разворачивание базы 1 час, обновление на 40 мегабайт (в архиве) раскатывается за полчаса, обновление на 400 мегабайт (в архиве) раскатывается около часа.
Выполнение построения полного адреса по uuid Здания занимает до 4-х секунд, но надо иметь в виду, что я не строил индексы для ускорения этой задачи, добавлены индексы только для ускорения разворачивания.
Применение разработки на практике, пока отложено, поэтому с составлением полного адреса я конечно разобрался, но оптимизаций не делал.
Хранимые процедуры для работы с базой смотрите в скриптах:
Спасибо за чтение. Пишите комментарии, будем обсуждать и делиться опытом.
Дополнительно
Это тривиальный код, но кроме вас его ни кто не напишет, для примера:
В целом, весь код лишён гибкости, и при добавлении новых регионов, код для их обработки, придётся дописывать самостоятельно.
Для ещё большего экономии места, колонки ID и GUID при импорте из DBF подтянутые как varchar(36), можно изменить на uuid, экономия до 5% от размера базы. Я сам не проверял, но в коментах несколько человек это подтвердили.
Загрузка ФИАС в БД на MSSQLSERVER подручными (SQLXMLBULKLOAD) средствами. Как это (наверное) не нужно делать
Эпиграф:
«Когда у тебя в руках молоток, всё вокруг кажется гвоздями».
Как-то давным-давно, кажется – в прошлую пятницу, обходя окрестности офиса, озаботилось окаянное начальство тем, что я провожу время в праздности и созерцании котиков и кошечек.
— А не загрузить ли тебе ФИАС, друг ситный! – сказало начальство. – Ибо процесс его загрузки что-то не нравится нашим бизнес-подразделениям. Долго, говорят грузится, грузит продуктовый сервер, да и чувак, который писал процесс загрузки, намедни уволился, года как три уже.
К тому же, все там давно нужно переделать, так что ты возьми, создай себе базу и обеспечь периодическую заливку ФИАСА. Всё, как говорится, не задерживаю!
Тут надо сказать, что к программированию я имею отдаленное отношение, т.к. являюсь, скорее, DBA. Хотя, с другой то стороны, загрузка больших массивов предварительно отпрепарированной информации – как раз задача DBA, nest pa?
— Да ладно… Щас сделаем – сказал я начальству, и ринулся на сайт ФИАСА, засучив рукава.
«О! Да тут есть dbf!» — подумал я, радостно потирая руки, параллельно подивившись отсутствию стандартного «де-факто» zip архива, и, наоборот, присутствию давно почившего в бозе arj и проприетарному пардон, открытому, конечно, 7zip [но который всё равно нельзя разжать с помощью powershell Expand-Archive]. Т.е. чистым powershell’ом это не скачаешь и не распакуешь. Придётся громоздить на сервер всякую хрень. Ну да ладно.
Инструментарий по массовой параллельной загрузке dbf файлов у меня написан лет уже как несколько, так что проблем возникнуть не должно.
Я распаковал dbf-ки, запустил программу загрузки, и пока данные грузились, набросал скриптик, который склеивал отдельные «почти-одноименные» таблички в одну, по принадлежности.
Загрузил данные, и уже хотел отправиться в кабинет руководства пожать, т.с., лавры, однако черт меня дернул посмотреть результаты импорта!
Большие таблицы грузились нормально, а маленькие – содержали кракозябры.
И так мне от всего этого стало грустно и тоскливо, что я мужественно взял себя в руки и занялся прокрастинацией и своими прямыми обязанностями. Возиться с битыми dbf-ками – жутко не хотелось.
Прокрастинировал я дня два, до тех пор, пока заявки не кончились, и на горизонте снова не замаячило начальство, с сакраментальным вопросом «А чё это мы сачкуем?».
И, так как ответить было нечего, а возиться с dbf – по-прежнему не хотелось, я решил загрузить ФИАС из xml, тем более что, как говориться, стильно, модно, молодёжно, и «dbf – умирающий формат».
На этом, разрешите затянувшийся вводный монолог закончить, и перейти к делу.
Итак, грузить было решено c помощью SQLXMLBULKLOAD – замечательной библиотеки, как раз и предназначенной для массовой (bulk) заливки структурированных xml файлов.
Для того, чтобы ее использовать, нужно скачать и установить библиотеку SqlXml 4.0 Service Pack 1 (SP1).
В случае ФИАСа, однако, «структурированность» не особо востребована. Т.к. файлы там не то, что не xml… они, конечно, xml, но, по сути – это плоские таблицы с данными, в каждом файле – одна таблица.
На сайте sql.ru я нашел процедуру spXMLBulkLoad уважаемого пользователя Mnior, чтобы совсем уж не вылезать за пределы SQL сервера, и не писать даже вызов SQLXMLBULKLOAD на CLR.
Вот слегка модифицированный ее вариант:
Однако, для осуществления массовой загрузки xml с помощью этой библиотеки необходимы аннотированные xsd схемы, в которых, собственно, и указывается, каким образом и куда что грузится.
Упоминания о том, что такие схемы есть, «но только старые» — я нашел аж на десятке сайтов, но нигде не нашел самих схем. И разозлился.
Модифицировать имеющуюся на сайте ФИАСа схему для импорта данных вручную – не сложно.
Но… в совокупности – там 271 поле! Это ж сколько сидеть и тупить надо!
Поэтому я решил модифицировать эти схемы автоматически, заодно и создав целевые таблицы в БД.
SQLXMLBULKLOAD умеет автоматически создавать таблицы для загружаемых данных из аннотированной схемы, но, с другой стороны, если я эту схему буду делать, то почему бы, попутно не сделать эти таблицы самому, так, как мне нужно?
Я скачал xsd схемы с сайта ФИАС и проанализировал их чисто визуально.
К счастью, они все – однотипные, поэтому создать целевую БД и модифицировать сами схемы для загрузки можно с помощью всего нескольких не очень сложных запросов.
1. Создадим пустую базу FIAS2.
Почему «2»? Ну, потому что «1» — была база из dbf-ок. Возможно, мы поговорим о ней позже.
2. Создадим в этой базе пару табличек.
Первая табличка будет содержать xsd схемы, а вторая – будет представлять из себя фактически схему данных, полученную из этих xsd схем.
xsd- схемы – это, вообще-то обычные xml файлы, так что и работать с ними можно как с обычными xml-ями.
Подробнее по запросам:
Первый – загружает xsd схемы в таблицу на сервере, попутно снабжая каждую схему аннотацией в поле [table] – именем таблицы, в которую я хочу грузить данные из соответствующей таблицы.
Безусловно, можно было-бы сделать так, что каждый раз, когда схемы поменяются, их можно было бы скачивать, подсовывать в какую-нибудь папку и пересоздавать по ним структуру целевых таблиц заново и автоматически, и заново же и автоматически модифицировать схемы, но т.к. структура меняется крайне редко, последний раз менялась – аж в 16 году – делать такой автомат крайне лениво. Лучше потратить 30 секунд на CTRL+C – CTRL+V.
Поэтому загрузка в табличку со схемами так захардкожена, и пути к загружаемым файлам, а также имена таблиц – прописаны руками.
Второй запрос – вытаскивает из схем информацию о структуре таблиц. Я не стал возиться с 3-нф, а развернул ее как одну таблицу.
Обратите, кстати, внимание на вот этот кусочек (+)
Довольно часто новички задают вопрос: можно ли вычислить какое-то сложное выражение в запросе 1 раз, а потом многократно использовать его в нескольких местах. Да, можно. Вот так, например:
Работает с некоторыми ограничениями, конечно. Но, начав пользоваться, вы быстро поймете, в чем они заключаются.
3. Создадим скрипты, создающие таблицы ФИАС, а потом запустим их, и создадим сами таблицы:
Кому лень всё это проделывать – скрипты на создание таблиц и аннотированные схемы ФИАС будут приложены в конце статьи.
4. Коль скоро в xsd есть нормальное описание таблиц и полей в них – используем его, и создадим описание структуры в расширенных свойствах таблиц и их полей:
5. Модифицируем сами схемы:
6. И, наконец, выгрузим xsd схемы на диск для дальнейшего использования:
Теперь осталось только вызывать процедуру загрузки для каждого xml файла с соответствующей схемой (сами распакованные файлы хранятся в папке e:\tmp, а схемы — мы выгрузили в c:\files\FIAS):
Ну вот, теперь наконец-то совсем всё.
Однако, вот что я вам хочу сказать, уважаемые коллеги!
Всё это работает просто дичайше медленно!
Я не про создание таблиц и схем, конечно. А про загрузку.
В тестовой среде загрузка у меня длилась без малого 5 часов (sic. ). И это еще без индексации таблиц.
При этом загрузка системы ввода-вывода была на уровне 3 Мб/с, и было задействовано всего пара ядер.
Загрузка адресных объектов шла со скоростью не более 3 тысяч записей в секунду, загрузка домов — со скоростью не более 8 тысяч в секунду. А их, на минуточку, 60 миллионов.
С чем это связано — я не могу сказать, придется еще поковыряться с кодом и, видимо, с настройкой ВМ.
Обратите внимание, что загрузка производится в кучи. А уже потом предполагается создать кластерные индексы по всяким их AOID.
Т.к. они представляют из себя GUIDы, лучше сделать именно так, потому, что если создать кластерные индексы ДО загрузки — на выходе получится таблица, фрагментированная где-то процентов на 50, не меньше. Ну и индексы лучше тоже создавать после загрузки, потому что вставка в индексы делает загрузку еще медленнее.
Именно поэтому имена таблиц у меня начинаются с подчерка ( _ ). Предполагалось, что я сначала загружу данные в них, потом воссоздам индексы целевых таблиц, и, затем, спокойно сделаю Alter table switch.
Также обратите внимание на не совсем оптимальные типы данных для полей таблиц ФИАС.
Например, использование int, там где достаточно tinyint, или nvarchar в полях, где предполагается хранение только числовых значений, типа кода региона или ОКАТО.
Так в схемах :-(.
Однако, ничего не мешает вам, после создания таблицы метаданных, [dbo].[_FIAS], поковыряться в ней руками и произвести тюнинг, а уже потом, создать новые загрузочные схемы на основе откорректированных метаданных.
Ну, а если изжить такую медленную загрузку всё же не удастся, видимо, придется вернуться к варианту с загрузкой из dbf, и расковырять, наконец, кракозябры в маленьких dbf. И написать еще одну статью.
dbf в 8 потоков нормально загрузилось за 1 час с копейками, и еще примерно час ушел на слияние отдельных таблиц в целевые, и построение индексов по ним.
… Ну, или, наконец, вытащить руки из жжж… эээ… афедрона, и наконец сделать нормальный data tier application, и грузить уже данные, как все нормальные люди, через SSIS.
Адреса ФИАС в среде PostgreSQL. Часть 4. ЭПИЛОГ
Это четвертая и последняя часть статьи, которая содержит примеры создания таблицы fias_AddressObjects в базе данных под управлением PostgreSQL, а также загрузки в нее данных об адреснообразующих элементах ФИАС. После этих действий можно самостоятельно испытать функции, рассмотренные в первой, второй, и третьей частях, скопировав и выполнив скрипты на их создание.
Полный текст статьи состоит состоит из 4 частей. В первой половине этой части статьи изложены комментарии к реализации скриптов создания таблицы адресообразующих элементов и заполнения ее данными. Во второй- исходные тексты скриптов.
Тем из читателей, кого интересуют только исходные тексты, предлагаем сразу перейти к
Приложению.
Эпилог
С чего начинать
Начать надо с посещения официального сайта Федеральной Налоговой Службы раздела «Федеральная информационная адресная система» (ФИАС) страницы «Обновления».
Загрузить на ваш компьютер последнее обновление или полную базу ФИАС, если вы только начинаете работать с ФИАС.
Перенести файл с архивом в рабочую папку. Извлечь файлы архива и найти файл ADDROBJ.DBF.
Далее предполагается, что загружен архив файлов с обновлением ФИАС в формате dbf.
Загруженный файл ADDROBJ.DBF преобразовать к формату csv. Для этого открыть исходный файл при помощи MS Excel и пересохранить его в формате в csv, не забыв при этом удалить строку с названиями полей записей. Далее преобразованный к формату csv будет именоваться «ADDROBJ24_20161020.csv», где 24 –код Красноярского края, а 20161020 – дата загрузки файла.
Создать таблицу fias_AddressObjects. Для этого можно воспользоваться скриптом приведенным в приложении «Создание таблицы адресообразующих элементов ФИАС fias_AddressObjects».
Загрузка ADDROBJ24_20161020.csv в базу данных
Рис. 7 Непосредственная загрузка данных в таблицу fias_AddressObjects.
Непосредственно загрузить данные из файла ADDROBJ24_20161020.csv в таблицу fias_AddressObjects можно так как показано на Рис. 7.
Но, к сожалению, простой путь не для нас.
Во-первых, кроме основного списка адресообразующих элементов поставляется еще и список адресообразующих элементов которые должны быть удалены из основного списка (DADDROBJ.DBF);
Во-вторых, в основном списке присутствуют нарушения связности, например, ссылки, которые никуда не ведут, т.е. в списке нет элемента или записи с идентификатором, указанном в ссылке. Поэтому не хочется восстанавливать ошибки, которые уже один раз исправлены.
В-третьих, не хочется каждый раз работать с полным список адресообразующих элементов ФИАС, а лишь загружать изменения, которые появляются на официальном сайте Федеральной Налоговой Службы два –три раза в неделю.
Поэтому в процессе загрузки обновления ФИАС используется две временных таблицы:
Рис. 8. Предварительная загрузка адресообразующих элементов во временные таблицы.
Далее данные таблицы fias_AddressObjects_temp служат для замены (UPDATE) значений в уже существующих записях и добавления (INSERT) вновь созданных записей основную таблицу. С подробным текстом этих операторов можно ознакомиться в разделе «Загрузка обновлений адресообразующих элементов ФИАС в таблицу fias_AddressObjects».
Так как в процессе обновления могут быть внесены нарушения целостности, можно загрузить записи, в которых ссылки на следующую (NEXTID) или предыдущую (PREVID) запись истории указывают на несуществующую запись.
Эта ситуация очень вероятна. Вот, например, данные по результатам загрузки полной базы данных по состоянию на 10.10.2016 года.
После того как обновления основной таблицы выполнены, необходимо присвоить значения NULL полям NEXTID или PREVID там, где их значения указывают на несуществующую запись. Например, так:
Перед завершением загрузки следует восстановить ограничения и удалить временные таблицы.
Создание справочника адресной информации с блекджеком и API
Часть 1. Трагическая. “За что мне все это?!”
Столкнулись мы как-то с необходимостью ввода корректной информации о местонахождении (прописке, регистрации) пользователей, и с тем, что проблема эта решается не совсем так легко и просто, как бы нам хотелось. Сначала мы попробовали КЛАДР, в его бесплатной ипостаси. Не то чтобы нам прямо-таки решительно все не понравилось, но было как минимум одно весьма раздражающее обстоятельство — некоторые адреса отсутствовали в справочнике. Например, дом 10 есть, а 10к1 — извините, не завезли. Вообще КЛАДР был привлекателен тем, что у него есть простой API и плагины (jQuery в частности), которые можно легко встроить в приложение, но отталкивал наполнением. Мы задумались — если нет такого ресурса, содержащего полную и наиболее актуальную адресную информацию, с API и плагинами, то единственный выход — создать такой ресурс самим.
Часть 2. Искательская. “Где собака зарыта?!”
И прослышали мы про ФИАС. О том как он бесконечно полон и прекрасен. А это выход! На сайте ФИАС есть базы, и все что нужно молодой растущей информационной системе! Правда, размер базы составляет более 4 Gb, ну да ладно, это же вся Россия! Обновляется база регулярно, так что есть где разгуляться. Дело за малым — развернуть базу, прикрутить API и плагины. Надо оговориться, что существует несколько релевантных и важных статей. К примеру, цикл вот этих статей, которые изначально очень помогли.
Часть 3. «Как это работает»
В большинстве случаев достаточно сформировать адрес вплоть до дома. Хотя, если кому надо, то можно углубиться и дальше.
Таким образом, создадим 2 таблицы в БД postgresql.
Таблица с адресами:
Таблица с номерами домов:
Импорт данных осуществляется простым способом. Открываем файлы в Excel и сохраняем их как csv. Дополнительно рекомендуется изменить кодировку, так как в отличии от xml файлов, которые представлены в кодировке utf-8, dbf файлы — в кодировке win-866. Открываем файлы в редакторе (для данной цели подойдет notepad++) и преобразуем в utf-8.
Импорт таблицы с адресами:
Импорт таблицы с домами:
Из чего сделана таблица ADDROBXX?
Несмотря на обилие полей, понадобятся только некоторые из них.
Важное в таблице HOUSEXX:
Далее, после того, как база была импортирована в Postgres — мы занялись созданием API и плагина для нашей системы.
Для API, дабы не изгаляться, использовали Laravel. Схема запросов получилась достаточно простой. Иерархия объектов выглядит следующим образом:
Схема запросов выглядит просто:
Регион и район можно убрать за ненадобностью, так как они подтягиваются вместе с городами.
При вводе высплывают autocomplete-подсказки, как и в КЛАДР. Правда разница заключается в том что КЛАДР-плагин предназначен для автодополнения, а здесь валидным считается только адрес, выбранный из подсказок.
В папке ASPUDcomponent — находится VueJs компонент для работы с адресной базой.
Исходники доступны в нашем репозитории.
Часть 4. Как это все обновлять?
С обновлениями ситуация следующая: для начала необходимо по протоколу SOAP получить версии обновлений. Посмотреть как это делается можно в классе UpdateController (метод: filesVersions()).
Примечание: версия, которая указана последней в полученном списке — не обязательно совпадает с той, которую можно скачать на главной странице. Но не стоит спешить скачивать только последнюю версию, так как она может оказаться “битой”. Случались и таким прецеденты. Далее скачивается архив с последней версией и распаковывается. Для работы необходимо использование расширения для php (php_rar.dll).
Ну а далее выбирается необходимый файл региона (или при необходимости все файлы) для обновления БД.