Открытые данные в России о которых многие не знают,

- Открытые данные ГУАП [1] ГУАП - это Санкт-Петербургский государственный университет аэрокосмического приборостроения, а на сайте у них есть раздел с API с информацией о ВУЗе. Есть внятное API, для полной открытости нехватает условий использования.
- Открытые API для сервисов Санкт-Петербурга [2] категорически малоизвестный портал Санкт-Петербурга с их официальными API к городским информационным системам. Развивают они его, почему-то, параллельно порталу открытых данных, а не совместно. Как и во многих других случаях, "забывают" написать про условия использования, но сами данные есть.
- Геопортал СВКНИИ ДВО РАН [3] и другие их ГИС сервисы [4] с картами и слоями карт по Дальнему востоку. Включает доступ к данным через открытое API сервера ArcGIS

Ссылки:
[1] https://api.guap.ru/data/
[2] https://api.petersburg.ru
[3] http://hags.north-east.ru:8080/geoportal/catalog/main/home.page
[4] http://www2.neisri.ru/index.php/ru/%D0%B3%D0%B8%D1%81-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B.html

#opendata #datasets #api #russia #geodata

Подборка полезных ссылок про данные, технологии и не только:
- drawdb [1] визуальное проектирование баз данных и SQL генератор на базе draw.io. Открытый код на JS, лицензия MIT. Выглядит очень даже неплохо
- quickwit [2] альтернатива Datadog и подобным сервисам, но с открытым кодом. Реализует поисковую систему для наблюдаемости процессов. Лицензия AGPL или коммерческая, для бизнеса. Выглядит как минимум интересно, очередной пример YAML программирования, огромного числа файлов для настройки.
- paradedb [3] альтернатива Elasticsearch на базе Postgres, обещают что внутри файлы parquet и многократно выше скорость аналитических запросов. Обещают облачный сервис, пока доступен open source продукт. Лицензия AGPL для всех и коммерческая для бизнеса.
- traefik [4] реверсный прокси для HTTP для развертывания микросервисов и API, похож на альтернативу Kong и Tyk. Открытый код под MIT лицензией

Ссылки:
[1] https://github.com/drawdb-io/drawdb
[2] https://github.com/quickwit-oss/quickwit
[3] https://github.com/paradedb/paradedb
[4] https://github.com/traefik/traefik

#opensource #data #datatools #api #dataviz

В рубрике *как это устроено в России* о том что должно было бы быть открытыми данными, но ими не является. У почти всех российских регионов есть инвестиционные карты. Это, либо отдельные геопорталы, либо разделы на инвестиционных порталах которые точно есть у всех. Например, инвестиционная карта Курганской области [1] или инвестиционная карта Волгоградской области [2]. Можно убедиться что на них есть слои карт и их от десятков до полутора сотен. Другие подобные инвестиционные карты легко находятся по ссылкам с портала инвестпроектов Минэка РФ [3].

Что можно о них сказать? Они все содержат то или иное недокументированное API. Там всего несколько вендоров геоинформационных систем и у них всё довольно стандартизировано. При очень небольших усилиях то же Минэкономразвития могло бы добавить на нацпортал открытых данных более 1000 датасетов и/или стандартизированных API по стандарту WFS. Очень небольшие расходы на всё это нужно, я бы даже сказал мизерные, а вероятность что эти данные были бы небесполезны, конечно, есть.

Но в России нет уже давно нацпортала открытых данных, деятельность в этой области на федеральном уровне, если не свернута, то подзабили на неё изрядно, особенно в Минэкономразвития.

Кстати, к примеру в Казахстане национальный геопортал [4] сделан довольно прилично и там публикуют открытые данные. Не со всех региональных геопорталов они их агрегируют, но и 571 слой карт - это неплохо.

Возвращаясь к ситуации в РФ. Мне бы вот, например, хотелось агрегировать данные с российских геопорталов в Dateno и даже недокументированность их API решается. У типовых систем, типовые API. Но тут уже другое ограничение, российские госсайты в большинстве своём недоступны с зарубежных IP адресов. Краулер работающий не изнутри страны не сможет достучасться до большого числа сайтов. Это, конечно, тоже решается, но требует больше времени и усилий.

В этом смысле поразительна ситуация с европейскими открытыми данными и открытыми данными в других развитых странах где именно геоданные составляют большую часть всего раскрываемого и опубликовано.

Ссылки:
[1] https://invest45.ru/investmap
[2] https://investmap.volgograd.ru
[3] https://invest.economy.gov.ru
[4] https://map.gov.kz

#opendata #data #geodata #russia #api

Нашёл презентацию Paul Bradshaw о недокументированных API веб-сайтов и как их искать [1]. Рецепты у него довольно простые:
- используйте Chrome Developers Tools и аналог в Firefox
- изучайте структуру ссылок и XHR типы запросов
- учитесь декодировать параметры

Ну и примеры недокументированных API тоже. Презентация должна быть доходчивой для журналистов, для которых собственно он и пишет как автор The Online Journalism Handbook.

У меня на эту же тему было несколько презентаций в контексте проблем с архивацией сайтов и в контексте поиска недокументированных API.

Так вот ключевой инструмент в работе с ними - это поисковые системы, возможность найти точки подключения проиндексированные ими.

Второй значимый инструмент - это "типовые", но недокументированные API многих программных продуктов. В первую очередь типовые API CMS.

И третий - это мобильные приложения, декодирование байткода которых или перехват их обращений к сайту также может дать много чего интересного.

Но, опять же, это всё полезно, в первую очередь журналистам, OSINT'щикам и хакерам. Для других задач нужно куда реже.

Ссылки:
[1] https://github.com/paulbradshaw/undocumentedapis/blob/main/Undocumented%20APIs.pdf

#api #readings #datajournalism

Подборка ссылок на продукты публикации датасетов для API и аналитики:

С открытым кодом:
- SQLite Studio [1] быстро первращает базы SQLite в веб интерфейс. Можно смотреть структуру таблиц и делать запросы. А также есть демо [2]. По ощущениям очень простой и удобный для этой небольшой задачи.
- Datasette [3] хорошо известный в узких кругах продукт, очень быстро превращающий датасеты в веб интерфейс. Умеет в разные данные, разные API, разные интерфейсы и куча расширений. Когда хочется конструктор и разного
- CSVBase [4] простой до безобразия для превращения CSV файлов в API. Внутри всё Python, одновременно и сервис для публикации данных онлайн для тех кто очень хочет делать это за деньги
- APIReady [5] написанный мной 11 лет назад очень простой движок по превращению CSV файлов в API. Честно говоря с той поры я его даже не развивал, просто как демонстрация самой идеи.
- APICrafter [6] тоже написанная мной утилита по публикации API к базам MongoDB. Развитие APIReady и необходимость поскольку MongoDB по умолчанию не давало и не даёт приемлимое API в их Community Server. Только в облачном сервисе есть уже что-то удобное. Всё на Python, управляется развесистыми YAML конфигами которые строятся автоматически на основе просканированных баз данных [7]

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

А я через какое-то время напишу про то какие есть бесплатные и коммерческие, не open source, онлайн инструменты делиться датасетами.

Ссылки:
[1] https://github.com/frectonz/sqlite-studio
[2] https://sqlite-studio.frectonz.io/
[3] https://datasette.io/
[4] https://github.com/calpaterson/csvbase
[5] https://github.com/ivbeg/apiready
[6] https://github.com/apicrafter/apicrafter
[7] https://github.com/apicrafter/apicrafter/blob/main/examples/rusregions/apicrafter.yml


#opensource #datatools #data #api

Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
1. Унификация. Хорошо опубликованные статистические данные практически всегда хорошо унифицированы. У них есть так называется code lists, стандартизированные справочники территорий, видов деятельности и тд. Они унифицированы в единые форматы и с ними можно работать унифицированным образом с любым индикатором. Можно сказать что почти во всех развитых странах базы индикаторов доступны таким вот унифицированным образом. В современных национальных системах управления статпоказателями такая унификация почти всегда увязана на внедрение стандарта SMDX от 2 до 3 версии.
2. Массовая выгрузка. На английском языке она звучит как bulk download, возможность выкачать базу индикаторов целиком с минимальным объёмом усилий. Может выглядеть как 1-2 zip файла со всем содержимым, так делают в FAO, или тысячи csv/csv.gz файлов по одному по каждому индикатору, со всем содержимым индикатора и каталогом ссылок на все файлы. Так делают в Евростате и ILO.
3. Универсальный поиск. Статистические продукты бывают разные, иногда в разных информационных системах, в разных форматах, включая архивные статсборники. Универсальный поиск позволяет искать по ним всем. Начиная с интерактивных таблиц и заканчивая архивными материалами и даёт возможность найти нужные данные в нужном формате за заданный период.
4. Открытые данные по умолчанию. Практика альтернативная возможности массовой выгрузки когда статистические показатели с самого начала публикуются на стандартизированном портале открытых данных с уже имеющимся API этого портала и доступны для выгрузки через это стандартное API. Например, так делают в ЦБ Бразилии с дата порталом на базе CKAN и в Катаре с их госпорталом открытых данных на базе OpenDataSoft
5. Экспорт данных и доступ через API. Не просто экспорт в Excel, а как минимум выбор из 5-6 форматов начиная от самых простых вроде csv, продолжая форматами для Stata и других продуктов, автогенерацией кода для Python или R и наличию SDK к хотя бы паре популярных языков разработки для доступа к данным. У многих европейских порталов статданных есть неофициальные SDK, в других вроде статданных Гонконга автоматически генерируется код на Python на страницах интерактивных таблиц.
6. Технологичность. Тут можно было бы добавить и соответствие лучшим дата-инженерным практикам. Это включает: доступность данных в форматах parquet, документация к API по стандарту OpenAPI, общедоступные примеры работы через Postman или аналоги, общая документация в стиле технологических проектов с интерактивными примерами, а не в форме отчетности подрядчика по контракту в PDF. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.

#opendata #api #statistics #thoughts

Полезная статья о которой хочется написать отдельно Deliver Your Data as a Product, But Not as an Application [1], она требует авторизации на Medium. но почитать её стоит.

Основная идея в том что данные - это продукт, но этот продукт не приложение. Иначе говоря если Ваша бизнес модель построена на предоставлении данных, то надо помнить что именно данные, являются продуктом и не надо смешивать их с кодом.

Собственно в статье отсылка к хорошо известной книге Principles of Data-Oriented Programming [2] и следующим принципам:
- Отделяйте код (поведение) от данных;
- Рассматривайте данные как неизменные (immutable)
- Отделяйте схемы/структуры данных от их представления
- Представляйте данные с помощью простых структур данных

Статья написана с прицелом на OOP разработчиков которые хотели бы понять отличия программирования с данными и без.

Идея отделения данных от кода, в принципе, не нова. Лично я при проектировании разных ИТ продуктов за последние годы придерживался принципа API-first, то есть вначале у тебя появляется API, а потом уже разные интерфейсы поверх него.

В случае с данными оно разделяется на 2+ сервиса API. Первый сервис API для бизнес логики/кода, второй для данных, как правило Data API отдающее JSON или Protocol Buffers. Реальные системы могут иметь больше вариаций по разделению и компонентам, но бизнес логика и доступ к данным разделять стоит всегда.

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

И это, конечно, относится не только к данным статистики.

Ссылки:
[1] https://towardsdatascience.com/deliver-your-data-as-a-product-but-not-as-an-application-99c4af23c0fb
[2] https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html

#itarchitecture #datasaproduct #data #api

В рубрике интересных открытых данных данные по трафику судов [1] от Finnish Transport Infrastructure Agency. Данные по портам, кораблям, движению, портозаходам и ещё много чему. Всё без ограничений и аутентификации, покрывает практически всё Балтийское море.

Тот случай когда API оправдано на 100%. Для полного счастья нехватает только исторических данных для bulk download.

Ссылки:
[1] https://www.digitraffic.fi/en/marine-traffic/#vessel-locations

#opendata #finland #API

Обновлённая подборка государственных каталогов открытых API. Последний раз я писал о них полтора года назад за это время список пополнился:
- API.GOUV.FR - каталог API, стандарты и рекомендации Франции
- API.GOVERNMENT.AE - каталог API Объединённых Арабских эмиратов
- API.GOV.UK - каталог государственных API Великобритании
- API.GOV.AU - австралийский государственный стандарт предоставления API и каталог общедоступных API
- DEVELOPER.VIC.GOV.AU - портал для программистов (каталог API) правительства штата Виктория, Австралия
- API.NSW.GOV.AU - портал открытых API Нового Южного Уэльса, Австралия
- PORTAL.API.IPAUSTRALIA.GOV.AU - портал API патентного ведомства Австралии
- DEVELOPER.HEALTH.GOV.AU - B2G (Business To Government) портал API Департамента здравоохранения Австралии
- DEVELOPER.TECH.GOV.SG - портал для разработчиков от Правительства Сингапура, API, документация и тд.
- ESERVICES.MAS.GOV.SG - портал открытых API главного монетарного управления Сингапура (аналог центробанка)
- MYGDX.GOV.MY - каталог API на малазийском государственном портале MyGDX

В реальности каталогов API сильно больше, не везде они сразу бросаются в глаза.

#api #openapi

Dateno Expands Data Capabilities for Professionals with API and Dashboard Tools!

We are thrilled to announce the launch of two powerful tools designed specifically for data professionals: the My Dateno personal dashboard and the Dateno API! These updates will greatly enhance your ability to manage and integrate data search into your workflows.

With My Dateno, users can now track their search history and access API keys, making it easier than ever to tap into Dateno's extensive data search capabilities. In the future, My Dateno will also provide access to premium features and additional data services. Plus, those who join our early access program will get free access to these new features during the testing period!

The Dateno API enables developers and businesses to integrate our platform’s search functionality directly into their products and infrastructure. This API offers fast, efficient search across 19 million datasets—including data files, geoAPI connections, and statistical indicators—with powerful filtering options. Retrieve comprehensive metadata and related resources, and streamline your data processing with ease.

We’re excited to empower data professionals with these new tools! 🚀

Learn more and sign up for early access at dateno.io

#Dateno #DataSearch #API #Innovation #DataIntegration #DataProfessionals