Почему открытые данные никому не нужны

    В процессе работы над проектом для открытых данных пришлось изучить множество государственных источников данных. Это и федеральные порталы и муниципальные ресурсы. Вот наиболее известные источники открытых данных:



    У всех этих ресурсов одни и те же болезни. Вот они:


    • Невалидность данных.
    • Разрозненность данных и отсутствие стандартов.
    • Отсутствие единого механизма поиска.
    • Отсутствие API для доступа к данным.

    Этого достаточно чтобы отбить желание пользоваться ими и данными размещенными на них.
    Теперь подробнее по каждому пункту и что с этим делать.


    Невалидность данных


    Из статистики по документам data.gov.ru видно что большая часть данных размещены в CSV-формате:



    И это огромная проблема. Дело в том что большая часть CSV-файлов имеют невалидный формат. В CSV легко допустить ошибку, а если пользователь не разбирается в стандарте, то вероятность ошибки близка к 100%. И так, какие ошибки встречаются чаще всего:


    1 местолишние кавычки. Это бич всех CSV данных. Неправильная кавычка может сломать весь документ.


    Пример: Реестр лицензий на фармацевтическую деятельность Новгородской области первая же строка:


    "Фармацевтическая деятельность","ООО ГЕЛИОС"",...

    2 месторазное количество колонок в строках данных.


    Пример: государственный реестр лекарственных средств


    regnumber,regdate,enddate,cancellationdate,nameregcertificate,country,tradename,internationalname,formrelease,stages,barcodes,normativedocumentation,pharmacotherapeuticgroup
    
     П N009886,28.04.2011,,,,"ООО ""Валеант""",Россия,Бронхинол,,~,,"Производство готовой лекарственной формы,Херкель Б.В., Nobelweg 6, 3899 BN Zeewolde, the Netherlands, Нидерланды
    ",,"П N009886-280411,2011,Бронхинол; 
    ",отхаркивающее средство растительного происхождения

    Сопоставляем заголовок и данные, получаем:


    regnumber = П N009886
    regdate = 28.04.2011
    enddate =
    cancellationdate =
    nameregcertificate =
    country = ООО "Валеант"
    tradename = Россия
    internationalname = Бронхинол
    ...

    80% CSV-файлов приходится править перед использованием. Это не большая проблема для небольших и редко меняющихся наборов данных. Но если набор в сотню тысяч строк и обновляется раз в неделю, то это большая проблема.


    Отсюда возникает вопрос, зачем использовать CSV?


    Разрозненность данных и отсутствие стандартов


    Каждая служба публикует данные в произвольном виде.


    Например это заголовки колонки из CSV-файла перечня карантинных зон:


    "Название карантинного организма",
    "Административный район",
    "Площадь в пределах установленной карантинной фитосанитарной зоны (га)",
    "№ и дата приказа об установлении карантинной фитосанитарной зоны Представление в орган исполнительной власти субъекта РФ (№ и дата письма)",
    "Представление в орган исполнительной власти субъекта РФ (№ и дата письма)",
    "Решение органа исполнительной власти субъекта РФ о наложении карантина (№ и дата)",
    "Территориальное управление"

    Геокоординаты могут быть представлены в виде 2 колонок, в одной колонке через запяую или в GeoJSON.


    А вот несколько вариантов представления списков:


    "№ 223од от 02.09.2010            № 277од от 29.09.2011       № 136од от 14.10.2009        № 556од от 02.10.2013              № 452од от 19.10.2012"

    "4 номера: 3 апартамента, 9 люксов, 2 однокомнатных двухместных улучшенных, 4 одноместных, 37 двухместных номеров"

    "OVDPhone": [
        { "PhoneOVD": "(495) 601-05-36" },
        { "PhoneOVD": "(495) 601-05-37" }
    ]

    Ко всему прочему данные разбросаны по разным ресурсам:



    Как узнать что это официальные сайты? И почему бы не публиковать данные в одном месте?


    Отсутствие единого механизма поиска


    Из-за разрозненности данных, нет возможности осуществить поиск по всем государственным источникам открытых данных. Видимо не хватает национального поисковика по открытым данным…


    Отсутствие API для доступа к данным


    Чтобы использовать данные в своем проекте их нужно скачать. И в дальнейшем самому отслеживать их изменение и актуализировать. Это сопряжено со значительными сложностями для больших наборов данных.
    Избежать этих сложностей можно если не скачивать данные, а использовать их через API. Для этого API должен предоставлять такую функциональность, которой было бы достаточно для выполнения любой задачи по работе с данными.


    Того API который есть у некоторых ресурсов (например data.mos.ru) не достаточно для полноценной работы с данными. Плюс они не достаточно надежы для использования в реальных проектах.




    Все это приводит к тому что открытые данные есть, но судя по количеству скачиваний на data.gov.ru ими пользуются единицы.



    Чтобы раскрыть весь потенциал открытых данных они должны быть доступны в максимально удобном для использования виде. Чтобы сразу начать ими пользоваться, а не тратить время на приведение их к корректному виду.


    Как можно исправить ситуацию


    ИМХО, ресурс аналогичный GitHub но для данных дал бы сильный толчок в развитии открытым данным.


    Да, есть например data.world, но он пока не имеет всей той функциональности которая сделала бы его GitHub'ом для данных. Какими характеристиками должен обладать ресурс:


    • Визуализация — возможность визуализировать данные так как хочет автор и пользователи, а не так как это сделает система.
    • Стандартизованность — возможность задать структуру данных, отклонение от которой выдаст ошибку и не позволит загрузить данные.
    • API и интеграция — богатый API и возможность интеграции с различными источниками данных.
    • Социальность — обсуждение, оценка и рецензирование данных сообществом.
    • Международность — данные не должны размещаться на серверах в какой-то одной стране, чтобы избежать их блокирования со стороны государства.

    Уверен что в скором времени такой ресурс появится и открытые данные займут значимое место в жизни каждого человека.

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 57
    • +3

      Петиция? Письмо в курирующий орган?

      • 0
        С просьбой разъяснить наличие стандартов на эти самые данные, да.
        • 0
          Замечтался и прочитал вторую часть как «в конкурирующий орган».
          • +1

            Для начала проект на github.com с замечаниями, предложениями по функционалу и стандартизации, который надеюсь выродится в технический регламентный документ, потом он преобразуется в петицию + открытое письмо президенту.
            Думаю разработчики порталов и сами слабо представляют зачем они делают этот портал, по этому у них так кривовато и нерешительно идет разработка.
            У представителей местной аудитории наверняка найдутся задачи, которые они могут решить с помощью данных с этих порталов.

            • +1

              Я им отправлял уже три недели назад про экскейпинг (я не автор этого поста). Судя по всему, в opendata обратная связь идет в /dev/null, и это тоже огромный минус этого портала. (с Санкт-Петербурга ответили через неделю, что это не их компетенция)
              Форварднул в минэкономразвития.


              Заголовок спойлера

              Не могу воспользоваться открытыми данными в формате csv из за того, что не выполняется экранированией спец символов:
              Шаги для воспроизведения:
              Загрузить набор
              http://data.gov.ru/opendata/7825457753-transport
              В наборе существую строковые значения, которые содержат в себе символ кавычки (").
              Пример:
              1,"305","1","НАЛИЧНАЯ УЛ. — БЕЛООСТРОВСКАЯ УЛ.","Автобус","Прямое","22 165","2 246",0.28,"А.С. "НАЛИЧНАЯ УЛ."",59.9567858383426,30.2370663
              Эту строчку невозможно разобрать на значения, тк. символ кавычки играют двойноу роль — роль индикатор начала и конца строкового знаения, и значение символа внутри строки.
              Согласно RFC 4180 на Common Format and MIME Type for Comma-Separated Values (CSV) Files такие неоднозначности должны устранятся:
              Цитата:


              1. If double-quotes are used to enclose fields, then a double-quote
                appearing inside a field must be escaped by preceding it with
                another double quote. For example:


                "aaa","b""bb","ccc"


              • +1
                Это довольно иронично выглядит, когда жалоба на ошибки в данных сама содержит ошибки и опечатки практически в каждой строке.
            • +1
              Даже если в этом посте присутствуют ошибки, что говорить о данных.
              Данные есть? Есть. Птичку поставили перед руководством, премию получили.
              То что ими не пользуются — не дело СОЗДАТЕЛЕЙ.
              • –2

                Эммм… Как бы так сказать, чтоб не забанили… Плохие открытые данные, это не самая острая проблема этой страны. ФГУПы, прокуратура, СК, суды,- всем пое.ать на прямое нарушение федеральных законов, а вы про неудобность формата…

                • 0
                  Одна из самых больших логических ошибок — думать, что от нерешения маленьких проблем вдруг сами собой начнут решаться большие. Более того, тем, кто не способен правильно выгрузить данные на сервер, я бы проблемы федеральных законов не доверил решать в принципе.
                  • 0

                    Правовое регулирование и правоприменение действует по нисходящей (рыба гниёт с головы). То что в одном муниципалитете четкий программист сделал четкие скрипты и его данные валидны — ничто, когда все доходит до регионального или федерального уровня. Ибо кто в лес, кто по дрова.

                • –4

                  Я против предоставления доступа к API открытых данных. Ибо я как налогоплательщик не заинтересован в оплате доп. серверов и доп.структур которые будут этот доступ осуществлять. Главное чтобы выгрузки были регулярными и в удобном формате.

                  • +2
                    Выгрузки все равно лежат на серверах которые требуют денег на содержание, так почему бы КПД не поднять)
                    • +1
                      разный порядок затрат, на статику и на динамически генерируемый контент
                      • +1

                        Лучше так — на API принимается обязательный ГОСТ и эти данные больше никакие исполнители не готовят руками — потому что этим теперь занимаются автоматизированные рабочие места персонала и ERP-системы госорганов, которые обновляются централизованно в масштабах государства, в соответствии с текущим законодательством и независимо от хотелок местных начальничков. "Гитхаб для данных", под эгидой Росстата, нужен теперь как большой архив, связанный с ERP через API и необходимый на тот случай, если что то грохнется, нужно будет проследить исторические ряды и т. д.

                        • 0

                          А как тогда припиской заниматься?! Если статистика будет отражать реальную действительность этож скока голов госслужащих полетят.
                          Эта инициатива не дойдет и до первого чтения.

                        • –1
                          На статику, генерируемую девочкой в excel-e ежедневно и на динамику, отдаваемую из закешированного запроса к базе? База обгонит девочку на первой зарплате по операционным расходам и окупится за пару лет с учетом разработки.
                          • 0
                            База обгонит девочку на первой зарплате

                            Обычно этим занимается не "одна человека" а куча народа во всех госорганах всех субъектов и на всех уровнях, а нужно, чтобы занимался простейший скрипт — который ложил бы свежие данные из локальной базы в централизованное хранилище а другой, который в хранилище* — готовит из цифр кошек нужную расчётную статистику. При этом персонал занимается работой с людьми, а не с цифрами и не вникает в проблемы их предоставления, хранения, обновления образов своих АРМ и т. д. а закончив рабочий день — спокойно идёт домой: только вопросы правильного внесения данных в формы рабочих программ — остаются отчасти в их ведоме.




                            P. S. *Было бы интересно, если бы бизнес и жители страны могли бы государству заказывать/голосовать за разработку нужным им скриптов и фильтров, вычислительных программ статистических методик, которые добавлялись бы в такие централизованные хранилища данных для всеобщего использования.
                            Например, планировать бизнес-планы стало бы гораздо проще, с их помощью.

                            • 0

                              Вы подходите к вопросу как пролетарий, ну или просто прогматичный человек не наделённый властью и бюджетами. Не так давно был в населенном пункте с численностью где-то человек 100. Библиотекарь в фонде которого 5 полок с книгами получает зарплату 30 тысячи рублей. Вы что хотите чтобы ее работу отдали бездушной программе, а она умерла с голоду?! Вы что хотите развалить страну?! </сарказм>

                        • +1
                          некоторые открытые данные — большого размера. api в этом случае удобнее: можно взять лишь нужный кусок данных и сэкономить время, вместо того, чтобы раз за разом качать гигабайты, особенно если выгрузка обновляется ежемесячно или ежедневно. примеры: исполнительные производства по юрлицам (ФССП, > 2 Гб), bus.gov.ru, zakupki.gov.ru и т.д.
                          • 0

                            То что удобно, никто не спорит, но когда у НИХ начнут отваливается сервера, когда они никого не предупредив начнут менять форматы и протокола API, когда они введут авторизацию для доступа к данным и когда введут плату за предоставление данных — вы будете стоять в той же очереди недовольных с требованием "дайте мне выгрузку, я сам все распарсю!"

                          • 0

                            Вы, как налогоплательщик, оплачиваете всяких "тёток"(ТМ), вбивающих данные руками в этот ёксель и перебивающий ещё в несколько мест, вот что вы оплачиваете — симуляцию работы, результатом которой нельзя пользоваться.

                            • +1

                              Ага. И я не хочу, чтобы завтра выскачило очередное ведомство с инициативой, а давайте мы api запилим за миллиардов рублей. Деньги как всегда разворуют, никого не посадят, а при свернут.
                              И да, я как и все разумные человека хочу чтобы был удобный доступ к государственным и муниципальным данным (правовые документы, статистика, аналитика), но сейчас это ппц как дорого выходит для обычного гражданина. Из недавних примеров поисковик Спутник

                            • 0

                              Ремарка: в текущем политическом режиме, который поощряет воровство и коррупцию

                            • +1
                              Все познается в сравнение — в целом CSV хороший формат. Любые альтернативы для таблиц в рамках открытых данных хуже.
                              • +1
                                Да, проблема не в CSV, а в ошибках при его использовании. И по-моему проще поменять формат чем научить им пользоваться :-)
                                • +3
                                  CSV хороший формат… Если вместо запятой использовать символ табуляции. А еще лучше, если все равно стандартизировать — воспользоваться изобретенными в незапамятные времена ASCII Group/Record/Unit separator.
                                  • 0

                                    Так в конечном счёте к DBF придём.

                                    • 0
                                      А еще дальше — к HDF5/netCDF.
                                      Но их же никто не осилит. А просто вставлять другие символы вместо запятой и перевода строки — научить можно. И большую часть проблем использования обычного CSV это решит.
                                    • 0

                                      Зачем использовать табуляцую вместо запятой? Есть же отличный стандарт на csv RFC4180, который явно говорит использовать кавычки для строк со спецсимволами. если бы он появился чуть раньше, у нас бы тогда не было того ужаса, что сейчас есть на каждой формочке, которая делает "import from csv".

                                      • 0
                                        Потому что то, когда генерируют «csv», результат систематически этому стандарту не соответствует.
                                        С табуляцией, или как я выше написал, с ASCII unit separator, вероятность наступить на грабли при самопальной генерации меньше.
                                      • 0

                                        Табуляция не воспринимается "на глаз". А вот какой-то спец-символ типо < DEL > или ^D, или даже тройных пайпов (|||) — точно не будут встречаться в тексте даже случайно.


                                        В конечном счете разделителем в csv может служить даже рандомный набор символов. Хоть [ { < RAZDELITEL > } ].


                                        Правда тут вопрос в том, что контролировать валидность данных всё равно не получится.

                                        • 0
                                          Ну вот же уже в третий раз пальцем тычу. ASCII сепараторы именно в качестве символов-сепараторов и придуманы. Они вообще в текст не вставляются ни случайно ни специально, т.к. непечатные и смысла для текста не имеют. Если нужно с бинарными данными работать — это уже другой случай.
                                      • +2

                                        Судя по всему, формат используется правильно, т.к. на сайте opendata можно посмотреть данные по ООО ГЕЛИОС", (вкладка просмотр данных)
                                        Проблема в скрипте, который выдает эти данные на выгрузку в csv. Вот там действительно эскейпинг забыли. Я им писал об этом 27 июня. По RFC эти кавычки надо экранировать дополнительный кавычкой (что и делает питерский data.gov.spb.ru/)

                                      • 0
                                        Я как-то на такую заметку набрел. В целом, csv — удобный и простой формат; с другими сложнее и неудобнее.
                                        • 0

                                          Верно, csv нужно уметь готовить, как и любой другой формат. Просто сменой формата не избежать проблемы незнания тонкостей формата. Вот, скажем, чего проще чем json, но и в нем много тонкостей: https://habrahabr.ru/company/mailru/blog/314014/

                                          • 0
                                            В США для геоданных предлагают сразу 3 формата: табличный, xml и json. я думаю это правильно.
                                          • 0
                                            А что, есть формат решающий проблему кавычек?
                                            Был бы xml или json, страдали бы от избыточности и корявых тегов. По моему CSV логичный выбор.
                                            • –4
                                              ODT или XLSX. Их почему-то называют «неправильными», но зато ошибки такого рода в них сключены
                                              • +1
                                                у публикаторов существует возможность размещения набора с конвертацией из *.xls/*.xlsx, что значительно решает проблему некорректных csv, если им пользуются, конечно
                                                • 0
                                                  odt это xml зажатый зипом, также как и xlsx. Они тащут за собой еще больше проблем.

                                                  * 2 спецификации которым нужно следовать (xml + формат)
                                                  * избыточность данных из за тегов
                                                  * дополнительная нагрузка на память и процессор из за операций упаковки\распаковки

                                                  Научить обезьянку ставить 2 кавычки гораздо проще чем выдресировать следовать стандартам и синтаксису =)

                                                  Итого: csv — норм выбор

                                                  P.S. Проблема тут скорее в отсутствии конвертирующего api возвращающего данные в нужном формате. Хотя Вы о похожих вещах говорили в статье, по этому тут я с вами.
                                                  • +1

                                                    На прошлой работе я как раз делал возможность через админку формировать шаблон в xlsx и потом, после заполнения, загружать его обратно, валидировать по типам и количеству столбцов и формировать CSV автоматом. Ещё и RDFa выводили на страницах паспортов (у портала открытых данных есть валидатор разметки, кстати). Хорошо получилось. Однако, я вижу один из тех наборов в статье, а это значит, что что-то всё-равно пошло не так :trollface:


                                                    Собственно, с конвертацией «CSV набора → шаблон в XLSX → человек → заполненный шаблон → новая версия набора открытых данных в CSV» заморочились именно после того, как стало совершенно очевидно, что если дать человеку править машиночитаемые наборы — будет плохо. Нельзя человека туда пускать, особенно (как в случае открытых данных) если это рядовой сотрудник какого-нибудь гос. ведомства с зарплатой ниже среднего и отсутствием какой-либо мотивации к работе (вообще не понимаю, чего они там сидят).


                                                    В общем, только автоматизация и роботизация спасут открытые данные.

                                                  • +1
                                                    Логичный вывод RDF.
                                                  • +1
                                                    csv хорош еще тем, что его понимают все инструменты визуализации и аналитики (и веб-сервисы, и десктоп). с xml этого ожидать не приходится. максимум, что еще работает, — json (для неплоских таблиц, где csv уже не применишь)
                                                    • +3
                                                      Проблема форматов данных при публикации это наименьшая проблема в систему государственной и муниципальной власти. Главная — качество этих данных. Дело в том, что за качество данных в электронных хранилищах ни кто особо не несет. Может сейчас ситуация и начала немного меняться в таких учреждениях как ФНС и Роскадастр, но в остальных думаю все осталось по-прежнему. Дело в том, что правового регулирования оборота электронной информации у нас практически нет (законы об электронной подписи не в счет). Чиновники несут ответственность за информацию только на бумажных носителях. То есть если в базе данных и на бумаге, выданной каким то ведомством, есть разночтения, то главной информацией будет считаться та, что на бумаге. А сверять электронные архивы с бумажными ни кто особо не рвется. Ну так далее. то есть у нас электронная информация имеет крайне низкую юридическую значимость, а значит ее качество в база данных крайне низкое. Это по сути свалка вторичных отходов от производства главного продукта деятельности ведомств — бумажного документа. Это я по личному опыту сужу. Работал руководителем ИТ-подразделения в государственном учреждении.
                                                      • 0
                                                        У всех этих ресурсов одни и те же болезни. Вот они:

                                                        • Отсутствие API для доступа к данным.


                                                        Как минимум для data.gov.ru вроде как есть API:
                                                        http://data.gov.ru/api-portala-otkrytyh-dannyh-rf-polnoe-rukovodstvo
                                                        • 0
                                                          Есть документация, а вот есть ли API? :-)
                                                          Например там написано: «API находится в стадии разработки и поэтому методы могут быть изменены без предупреждения.» Можно ли пользоваться таким API?
                                                          • +1
                                                            API на data.gov.ru есть, но он умеет только отдавать тот же файл данных, который можно скачать руками. еще можно получить реестр всех наборов данных, которые лежат на Портале. кому интересно — ниже amgreen привел ссылку на методические рекомендации по публикации открытых данных, рекомендую взглянуть, это правда интересно. а вот сами данные, удобной выборкой в json, с data.gov.ru получить не удастся. в отличие, кстати, от сайта ГИБДД по статистике ДТП — там есть неплохой api, хотя и скрытый (спрятан под картограммой)
                                                        • +4
                                                          CSV — лучший выбор для дампов данных. Особенно tab-separated. Особенно записанный в файл не вручную, а используя какую-нибудь стандартную библиотеку. JSON раздут и страдает от некорректного форматирования куда сильнее (ибо фиг починишь).
                                                          XLSX — полупроприетарный формат, для которого зачастую нет нормальных библиотек. К тому же, люди, поддерживающие xlsx-файлы склонны туда пихать жирные шрифты и подобную лабуду. Или записывать несколько листов. Или ещё хуже: несколько разных по набору полей таблиц — на один лист. Или неправильно указывать тип полей (числа в строковых полях), что вызывает проблемы у парсеров. Ничего хуже, чем xlsx придумать вообще невозможно.

                                                          API иногда полезен, но он должен идти в дополнение к дампу, а не как замена. И зачастую дамп должен быть главным в этой паре, потому что по имеющемуся дампу API-шку можно хоть бы и самому сделать, а наоборот — не всегда. Да, поддержание данных в актуальном состоянии — неприятность, но далеко не такая большая, как попытка добыть данные из плохого API (а из API, который лёг — совсем беда). Пожелаете пример — напишите в личку.
                                                          • 0
                                                            Ничего хуже, чем xlsx придумать вообще невозможно.


                                                            Да ладно. Как бы Вам понравился doc-файл, в который картинками вставлены сканы распечаток?
                                                        • 0

                                                          Есть методические рекомендации по разработке открытых данных http://data.gov.ru/metodicheskie-rekomendacii-po-publikacii-otkrytyh-dannyh-versiya-30


                                                          Есть разнарядка выгружать открытые данные с региональных сайтов на центральный data.gov.ru. На нем установлен валидатор как раз по методическим рекомендациям.

                                                          • 0

                                                            Да ладно CSV — ФИАС (уже стал забывать это название, вспоминают "что-то с провалом связано..., а! фиаско". парсить это чудо, выложенное в виде changelog'а было отдельное увлекательное занятие, не говоря об объёмах, по крайней мере лет 5+ назад.


                                                            Отдельно доставляет фраза в поисковике "Возможно, этот сайт был взломан.
                                                            Федеральная информационная адресная система (ФИАС) содержит достоверную единообразную" (хотел посмотреть когда оно запустилось для уточнения когда использовал).

                                                            • 0
                                                              @Pacos, а с вызрузкой ФИАС в открытые данные не работали? с xml. структура у него, вроде, в порядке, но разобраться непросто — адрес собирается практически из атомов )
                                                              • 0

                                                                Это было задолго до, я уже много лет как покинул то благодатное место, только подёргивание глазика при воспоминаниях осталось.
                                                                Мы скачивали непосредственно с их сервера diff и периодически полный дамп (который представляет из себя полный лог изменений), был в xml архиве, который уже обрабатывали для заливки себе в базу (делал робот по расписанию). Отдельным бонусом было представление xml в виде одной строки — открыть по f3 в том же Far и посмотреть глазами было подобно пытке.

                                                                • 0

                                                                  ФИАС не так уж плох. Просто смотреть в него не надо. Открыли архив с помощью libarchive (начиная с 3-й версии умеет смотреть внутрь RAR-архивов), скормили нужные файлы из него SAX-парсеру, вытащили интересующие данные, сохранили, архив закрыли, как страшный сон забыли.

                                                                  • +1

                                                                    Windows как платформа накладывает ограничение (в госструктурах в основном так), потому сначала распаковка, потом парсинг.
                                                                    А смотреть внутрь очень даже надо чтобы понять что там и почему не грузится (напоминаю что это был момент запуска ФИАСа и того сервиса, который может быть сейчас, не было). Скачал страничку, распарсил, посмотрел наличие новых diff'ов и время модификации основы, решил что качать, скачал, если diff — долил в базу, если полный — перезалил в базу (не только у меня было впечатление что diff меньше, чем разница между полными).
                                                                    А ФИАС (и КЛАДР) плох хотя бы отсутствием районов внутри города.

                                                            • 0
                                                              заголовок некорректный. Можно подумать что открытые данные не нужны вообще и везде.
                                                              уточните, заголовок —
                                                              Почему открытые данные
                                                              от государственных источников в Российской федерации
                                                              никому не нужны
                                                              , кроме как самим государственным источникам, для их автоматической обработки.

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.