Одна из стран по которой пока в Dateno мало датасетов, всего 58 тысяч, это Индия. 58 тысяч датасетов на страну в более чем 1 млрд человек это очень мало хотя объективно причины и понятны.
В Dateno сейчас 46 каталогов данных связанных с Индией [1], они сейчас обновляются и не все доступны и не все включены.
Итак что с открытыми данными в Индии:
1. В Индии сильная централизация данных на национальном портале data.gov.in Это самописный продукт где заявляется 500+ тысяч дата ресурсов. У его создателей свое восприятие мира и по факту, эти 500+ тысяч ресурсов - это файлы, а то что принято в мире называть датасетами они называют каталогами. Их всего 12.6+ тысяч. Примерно по 40 файлов на один каталог. Поэтому, с одной стороны индийский портал данных кажется огромным, а с другой, совсем нет. Это всего +12.6 тысяч наборов данных для поискового индекса. А это уже не так много и не так масштабно. Что ещё показательно на нац портале не указываются объёмы хранимых данных, а это один из верных признаков что физического объёма там немного. В любом случае стандартизированного API там нет, надо делать парсер их API/веб страниц
2. Индия страна большая, но сравнительно небогатая. Не у всех регионов есть свои информационные системы, геопорталы и тд. Они постепенно появляются, но в общем то есть не у каждого штата.
3. Официальная статистика тоже не отдаётся стандартизированными интерфейсами, а отдельный портал открытых данных [2] и ещё несколько публичных ресурсов о которых я ранее писал.
В принципе же Индию я лично отношу пока к категории стран со своей большей спецификой в работе с данными. Сейчас это: Китай, Россия, Индия.
У меня пока ключевой вопрос в том как измерять качество покрытия поиска Dateno по странам. В пропорции к населению, к ВВП, индексу развития цифровой инфраструктуры (ООН), индексу демократизации или ещё чему-то? Или всем сразу?
При этом понятно что это, одновременно, оценка, и качество наполнения реестра и поискового индекса Dateno, и развитости культуры работы с данными в стране.
Можно свой индекс "забабахать" World data discovery index;)
Ссылки:
[1] https://dateno.io/registry/country/IN
[2] https://esankhyiki.mospi.gov.in
#opendata #india #datasets #datacatalogs
Полезные ссылки про данные, технологии и не только:
- Classifying all of the pdfs on the internet [1] автор проанализировал 8TB PDF файлов собранных через Common Crawl и использовал Llama-3-70B для их классификации.
- Loss Rider [2] библиотека для визуализации Line Rider диаграм. Наглядный импакт!
- quarto-live [3] расширение для Quarto добавляющее интерактивности для R и Python примеров. Хорошо подойдёт для любых онлайн учебных курсов.
- A Gentle Introduction to GDAL Part 8: Reading Scientific Data Formats [4] лонгрид про обработку научных геоданных HDF и NetCDF с помощью GDAL. Выглядит полезным
- LOTUS [5] движок для запросов к запросов к Pandas с LLM
Ссылки:
[1] https://snats.xyz/pages/articles/classifying_a_bunch_of_pdfs.html
[2] https://github.com/jndean/LossRider
[3] https://r-wasm.github.io/quarto-live/
[4] robsimmon/a-gentle-introduction-to-gdal-part-8-reading-scientific-data-formats-1a1f70d5388c" rel="nofollow">https://medium.com/@robsimmon/a-gentle-introduction-to-gdal-part-8-reading-scientific-data-formats-1a1f70d5388c
[5] https://github.com/stanford-futuredata/lotus
#opensource #readings #llm #ai
[RU] Больше открытых данных об Армении. На сайте Всемирного метеорологического агентства World Weather Information Service [1] публикуются данные прогноза погоды по 3467 городам мира [2] включая станции мониторинга прогноза погоды по Армении.
Данные доступны в виде страниц городов и могут быть выгружены с сайта в машиночитаемых форматах:
- Ереван https://worldweather.wmo.int/en/json/66_en.json
- Севан https://worldweather.wmo.int/en/json/68_en.json
- Капан https://worldweather.wmo.int/en/json/69_en.json
- Ванадзор https://worldweather.wmo.int/en/json/67_en.json
- Дилижан https://worldweather.wmo.int/en/json/2079_en.json
- Джермук https://worldweather.wmo.int/en/json/2080_en.json
Полный список городов включает идентификаторы [2] по которым можно получить данные используя документацию API на сайте [3].
[EN] More open data about Armenia. The World Weather Information Service [1] website of the World Meteorological Agency [1] publishes weather forecast data for 3467 cities of the world [2] including weather forecast monitoring stations for Armenia.
The data are available as city pages and can be downloaded from the site in machine-readable formats:
- Yerevan https://worldweather.wmo.int/en/json/66_en.json
- Sevan https://worldweather.wmo.int/en/json/68_en.json
- Kapan https://worldweather.wmo.int/en/json/69_en.json
- Vanadzor https://worldweather.wmo.int/en/json/67_en.json
- Dilijan https://worldweather.wmo.int/en/json/2079_en.json
- Jermuk https://worldweather.wmo.int/en/json/2080_en.json
The full list of cities includes identifiers [2] for which data can be retrieved using the API documentation on the website [3].
Links:
[1] https://worldweather.wmo.int
[2] https://worldweather.wmo.int/en/json/full_city_list.txt
[3] https://worldweather.wmo.int/en/dataguide.html
#opendata #armenia #climate #meteorology
Подборка полезных ссылок по данным, технологиям и не только:
- Sparrow [1] движок для извлечения данных из документов и изображений, использует LLM, открытый код под GPL
- Genealogy of Relational Database Management Systems [2] хорошо нарисованная история создания баз данных, полезно для преподавания этой дисциплины. Минус только в том что она 2018 года и последние разработки не охватывает, плюс в том что большая часть фундаментальных трендов охвачена c 70х годов.
- Hamilton [3] ещё один движок с открытым кодом для преобразования данных. Выглядит неплохо, распространяется под BSD лицензией.
- Meaningful metrics: How data sharpened the focus of product teams [4] о том как устроены метрики в Duolingo. Полезное про то как устроены метрики в массовых технологических продуктах, а заодно является ответом на вопросы о том почему Duolingo устроено именно так как оно устроено.
- Bigtable transforms the developer experience with SQL support [5] анонс поддержки SQL в Bigtable. Кажется "а что тут такого?", а как сильно помогает в пользовательском опыте работы с данными там.
Ссылки:
[1] https://github.com/katanaml/sparrow
[2] https://hpi.de/fileadmin/user_upload/fachgebiete/naumann/projekte/RDBMSGenealogy/RDBMS_Genealogy_V6.pdf
[3] https://github.com/dagworks-inc/hamilton
[4] https://blog.duolingo.com/growth-model-duolingo/
[5] https://cloud.google.com/blog/products/databases/announcing-sql-support-for-bigtable
#opensource #dataengineering #dataproducts #metrics #readings
В рубрике интересных продуктов для публикации данных малоизвестный pycsw [1] движок с открытым кодом для публикации метаданных для геоданных. Поддерживает стандарты STAC API, CSW, OpenAPI, OGC Collections, OpenSearch, OAI-PMH и даже SRU, который, скорее, для библиотечных систем.
Имеет немного внедрений, около 50 по всему миру [2] во всяком случае тех что известны самим разработчикам.
Сильно менялся от версии к версии. До версии 3.0 был просто движком для публикации CSW каталогов, а с версии 3.0 чем-то стал конкурировать с геосервером или дополнять, тут уж как посмотреть.
С точки зрения архитектуры штука не то чтобы сильно современная, но открытый код, но расширяется плагинами и, в целом, функции индексации геоданных может выполнять неплохо если прикрутить к нему интерфейс, API для управления и тд.
Ссылки:
[1] https://pycsw.org
[2] https://raw.githubusercontent.com/geopython/pycsw.org/gh-pages/live-deployments.geojson
#opendata #geodata #datacatalogs #opensource
В Haaretz статья о том что [1] Иранские хакеры начали повсеместно публиковать чувствительные израильские документы, а власти Израиля начали давить на все социальные сети и хостинг провайдеры всеми легальными способами чтобы те немедленно удаляли этот и любой про-хамасовский контент.
И, картина была бы неполной, не упоминайся там Телеграм команда которого крайне недружелюбна к требованиям властей и спецслужб, как минимум израильский и не совпади это с арестом Павла Дурова в Париже.
Честно говоря не знаю даже что добавить, но не верю что Павла вот так просто освободят.
Ссылки:
[1] https://archive.is/J9nke
#israel #iran #security #telegram
Если ты знаешь один трюк, рассказывать его нельзя. Если ты знаешь сто трюков, то можно рассказать хоть про три (с)
Недокументированные API - это те API веб сайтов которые существуют и дают доступ к данным/сервисами, но по какой-либо причине явно не документированы владельцем сайта. Это то о чём я раньше читал лекции и недавно упоминал их в контексте презентации Paul Bradshow для дата-журналистов [1]. Журналисты расследователи и дата журналисты используют их достаточно часто. Я лично регулярно сталкиваюсь с этим в задачах архивации сайтов, создания датасетов "из ничего" и в Dateno при индексировании каталогов данных.
Есть несколько трюков в их поиске которые, как оказывается, широкой публике малоизвестны:
1. Многие сайты разрабатываются так что возвращают разный контент на передаваемые заголовки "Accept". Достаточно делать запросы с заголовком "Accept: application/json" чтобы обнаружить что веб страница может быть и JSON документом. Например, сайты на базе движка Blacklight используемого в архивном деле и для ведения цифровых коллекций материалов.
2. У стандартизированных CMS множество стандартизированных интерфейсов о которых владельцы сайтов могут ничего не подозревать. Не совсем "недокументированное API", скорее плохо документированное API по умолчанию. Оно есть пока владелец сайта явным образом не найдёт где его отключить или не предпримет специальных мер по его сокрытию. Явный пример, /wp-json/ у Wordpress, а также множество других примеров в менее известных CMS. На многих порталах открытых данных каталог данных доступен по ссылке /data.json даже если на сайте ссылки на него нет.
3. Разработчики API тоже люди и думают шаблонами и даже на проде оставляют доступ к API через стандартизированные интерфейсы во внутренних ссылках или поддоменах вроде префиксов документов вроде api и api-dev и в виде внутренних ссылок /api, /api-dev, /rest и ещё с десяток других.
Когда надо найти API конкретного сайта то трюков гораздо больше. Главное чтобы такое API реально существовало😉
Ссылки:
[1] /channel/begtin/5662
#opendata #data #tricks #readings
Смотрю презентации выступлений участников DuckCon 5 [1]. Там довольно много насыщенных докладов интересных, как с точки зрения технических особенностей применения DuckDB, так и с продуктовой точки зрения, когда применение в нужном месте даёт качественное повышение эффективности продукта.
Из того что особенно привлекло внимание так это выступление Miguel Filipe из Dune Analytics про то как они применяют DuckDB для предоставления результатов аналитикам из мира крипты [2] и Edward Ruiz из Boston University о том как он разработал на базе duckdb движок dbverse для языка R [3] который даёт существенный прирост скорости в обработке геномных и других научных данных.
В целом просмотренное подтверждает мои мысли что DuckDB хороший внутренний движок и фундаментальная технология для многих потенциальных продуктов.
Ссылки:
[1] https://duckdb.org/2024/08/15/duckcon5.html
[2] https://blobs.duckdb.org/events/duckcon5/miguel-filipe-delighting-users-with-restful-apis-and-duckdb.pdf
[3] https://blobs.duckdb.org/events/duckcon5/ed-ruiz-composable-database-libraries-for-larger-than-memory-scientific-analytics.pdf
#datatools #duckdb #dataengineering
В рубрике больших каталогов открытых данных проект DR Power (egriddata.org) [1] с наборами данных моделей для моделирования системы электроэнергетики США. Содержит 272 тысячи наборов данных, фактически модель по каждому объекту, и почти 800 тысяч файлов, в основном, в специализированных для проектирования электроэнергетики форматах.
Все данные опубликованы на портале на базе ПО DKAN, у которого есть открытое API, но которое явно не справляется с такой нагрузкой.
Ссылки:
[1] https://egriddata.org
#opendata #datasets #energy #usa
Для тех кто любит заниматься дата сторителлингом (журналисты, аналитики) новый полезный инструмент Closeread [1] позволяющий рассказывать истории внутри HTML документов open source системы документирования Quarto [2].
Quarto сама по себе удобная система и я лично давно смотрю на неё с разных сторон и хочу применить в деле. А Closeread ещё и приближает её к задачам рассказывания историй.
И всё это в Markdown, расширяемо, и тд.
А ещё интересно для публикации научных статей, уже есть примеры их подготовки в Quarto и множество шаблонов [3].
Куда ни посмотри, отличный инструмент.
Ссылки:
[1] https://closeread.netlify.app
[2] https://quarto.org
[3] https://github.com/quarto-journals
#opensource #datajournalism #analytics #datadocs #tools
В рубрике закрытых данных в РФ у геопортала Архангельской области на базе ArcGIS закончилась лицензия [1] и слои данных и сервисы с этого сервера более недоступны. Хотя они всё ещё перечислены в их каталоге геоданных [2]. Похоже что геопортал уже, или перевели, или переводят на российскую ГИС Orbis, у которой открытых слоёв с данными нет и в каталоге они не перечислены, но есть недокументированные API. Не совместимые с ArcGIS или с протоколами OGC.
А каталог геоданных в Архангельской области не обновляли уже 3 года.
Ссылки:
[1] http://maps1.dvinaland.ru/arcgis/rest/services/AdressnPlan/Kadastr/FeatureServer/0
[2] https://maps29.ru/catalog/#
[2] https://maps29.ru
#opendata #closeddata #datasets #russia #geodata
В продолжение размышлений о поиске геоданных и связанных с этим сложностей. Я ранее писал про GeoSeer, единственный известный мне поисковик геоданных в мире, но и он сравнительно небольшой. А вот в качестве альтернатив ему выступают уже не поисковики, а каталоги георесурсов. В первую очередь поисковики в экосистеме ArcGIS по их каталогам открытых данных и георесурсов и некоторое, небольшое число альтернатив.
Например, Spatineo Directory [1] от финских геоконсалтеров Spatineo. Там более 87 тысяч георесурсов, в виде точек API по стандартам WFS, WMS, WMTS, но без сбора информации о слоях, поэтому это не поисковик, а именно каталог. Его существенный минус в то что более менее там систематизированы только точки API из развитых стран.
Другой, неожиданно, государственный проект это FGDS Status Checker [2] гигантский каталог геовебсервисов созданный как сервис проверки их доступности. Список вебсервисов там огромный, но почти полностью ориентированный на США и почти не охватывающий морские территории. Есть подозрение что Spatineo делали свой каталог с оглядкой именно на этот продукт, поскольку функции схожи.
Но ещё больше каталогов которые прекратили своё существование. К примеру WFS Geodata Catalog от германского GeoClub. Сейчас можно найти только скриншот.
Ещё был Pyxis crawler с каталогом из 29+ тысяч датасетов, вот он ближе к GeoSeer, но индексировал всего 1572 источника и его тоже больше нет. Тоже остался тоже скриншот.
И был ещё такой поисковик Geometa, но теперь даже его скриншот найти оказалось непросто.
Фактических попыток систематизировать и сделать доступными геоданные и геосервисы было много. Можно сказать что у Dateno тоже есть подзадача в части геоданных.
В каталоге Dateno сейчас 4.4 миллиона наборов геоданных извлеченных из 3127 геопорталов. При этом в реестре Dateno всего 5955 геопорталов и после индексации оставшихся объём геоданных существенно вырастет, кроме того много геоданных в других типах дата каталогов: порталах открытых данных, научных репозиториях и тд., это тоже добавит число геоданных.
Но пока приходится держать в голове что в части геоданных относительно сравнимой референсной базой является GeoSeer.
Ссылки:
[1] https://directory.spatineo.com
[2] https://statuschecker.fgdc.gov
#opendata #geodata #datasets #datacatalogs #dateno
Свежая научная статья Why TPC Is Not Enough: An Analysis of the Amazon Redshift Fleet [1] изнутри Amazon AWS с анализом около 32 миллионов таблиц и около 500 миллионов запросов за 3-х месячный период, а также открытый датасет который лежит в основе этой статьи и её выводов.
Для дата инженерии там немало инсайтов:
1. До сих пор использование parquet это редкость, большая часть клиентов AWS используют сжатые GZip'ом CSV и JSON файлы.
2. Самый популярный тип данных varchar, более 52%. Это ещё раз подтверждает что на AWS явно основное применение не для математических расчётов, анализа геномных данных и тд.
3. Реально больших данных мало, больше 99.8% запросов работают менее чем с 10TB.
По поводу последнего в блоге MotherDuck, пост со ссылкой на эту статью [3] как раз про то что "больших данных не существует" и то что статья про данные AWS это подтверждает. Реальная потребность в обработке очень больших данных невелика.
Ссылки:
[1] https://assets.amazon.science/24/3b/04b31ef64c83acf98fe3fdca9107/why-tpc-is-not-enough-an-analysis-of-the-amazon-redshift-fleet.pdf
[2] https://github.com/amazon-science/redset?tab=readme-ov-file
[3] https://motherduck.com/blog/redshift-files-hunt-for-big-data/
#datasets #data #datatools #dataresearch
В рубрике как это устроено у них специализированные OpenDAP Hyrax порталы для публикации океанографических и климатических данных. Развивается одноимённой НКО [1], изначально создано в научных центрах NOAA и поддерживается 3-мя агентствами в США: NOAA, NSF и NASA, а также Австралийским метеорологическим бюро.
Поддерживает множество стандартов публикации данных таких как HDF4, HDF5, NetCDF3, NetCDF4, FITS, NcML, THREDDS и другие.
Применяется, как минимум, в паре десятков проектов связанных с данными об океанах и климате по всему миру. Например:
- http://servdap.legi.grenoble-inp.fr/opendap/hyrax/
- https://ladsweb.modaps.eosdis.nasa.gov/opendap/hyrax/
- https://ppdb.us.edu.pl/opendap/
Как правило, раскрываемые в этих серверах данные большого объёма, по несколько терабайт на каждой инсталляции и содержат преимущественно численные значения.
Другие продукты в этой области это ERDDAP [2] и THREDDS Data Server (TDS) [3], также имеют только это узкое применение.
В принципе особенность развития работы с данными в климатологии и наук о Земле в наличие большого числа каталогов данных, открытых данных, но по собственным стандартам, в специализированном ПО, не пересекающимися, ни с наиболее популярными инструментами в data science, ни с открытыми данными.
Ссылки:
[1] https://www.opendap.org
[2] https://www.ncei.noaa.gov/erddap/index.html
[3] https://www.unidata.ucar.edu/software/tds/
#opendata #climate #meteorology #datacatalogs #thredds #opendap
Полезные ссылки про данные, технологии и не только:
- FOR-species20K dataset [1] датасет результатов лазерного сканирования более 20 тысяч деревьев и идентификация их видов на основе этих данных
- DuckDB Tricks – Part 1 [2] полезные трюки по работе с данными с помощью DuckDB.
- ncWMS Guide [3] руководство по серверу WMS ncWMS, активно используется вместе с серверами Thredds в метеорологии. Начал их активно добавлять в реестр каталогов данных, скоро проиндексируются в Dateno
- Mapbender 4.0 [4] вышла 4-я версия Mapbender, популярного open source геопортала используемого в ЕС во многих странах.
- SuperMap [5] популярный в Китае геосервер, альтернатива ArcGIS. Используется во многих китайских госорганах, компаниях и активно распространяется в южной, восточной и юго-восточной азии. Имеет частичную совместимость с ArcGIS
- Mealie [6] сервер для ведения рецептов, открытый код и импорт из разных источников. Локализован на многие языки включая русский.
- Slackdump [7] архиватор публичных и личных сообщений из Slack'а. Не требует админских привилегий, открытый код.
Ссылки:
[1] https://zenodo.org/records/13255198
[2] https://duckdb.org/2024/08/19/duckdb-tricks-part-1
[3] https://reading-escience-centre.gitbooks.io/ncwms-user-guide/content/
[4] https://mapbender.org/aktuelles/details/mapbender-version-400-released/
[5] https://www.supermap.com/en-us/
[6] https://github.com/mealie-recipes/mealie
[7] https://github.com/rusq/slackdump
#opensource #data #datatools #geodata #geoportals #tools #datasets
Городские дашборды Гонконга [1] из плюсов выглядят довольно неплохо, из минусов данные не обновляли с февраля 2024 г. Интегрированы с национальным порталом открытых данных [2] где много разных данных и API.
В восточной и юго-восточной азии, в принципе, популярны городские и страновые дашборды, но всё время остаётся ощущение что они какой-то эксперимент.
Ссылки:
[1] https://dashboard.data.gov.hk/city-at-a-glance
[2] https://data.gov.hk/tc/
#opendata #data #hongkong #dashboards #dataviz
К вопросу о наличии данных о странах, есть два взгляда на это. Первый есть ли вообще какие-то данные о стране в структурированном или неструктурированном виде, не обязательно из источников внутри страны. И второй в том есть ли структурированные источники данных внутри страны. В Dateno идёт агрегация структурированных источников и данные по странам, находятся, или в глобальных агрегаторах вроде индикаторов Всемирного банка, BIS, WHO и других, либо из самих стран, либо, реже, из глобальных и региональных систем раскрытия научных или статистических данных.
И сейчас есть 24 страны по которым нет источников структурированных данных внутри страны. Фактически, ни одного каталога данных: открытые данные, геопорталы, индикаторы, ничего нет.
Страны можно разделить на 3 типа:
- совсем небольшие развитые: Монако, Сан Марино. Их данные агрегируются странами их окружающими
- страны в длительном политическом / экономическом кризисе
- совсем бедные страны
По последним двум группам минимальные инфраструктурные данные есть на Humanitarian Data Exchange [1].
А про развитые страны где тоже маловато данных я ранее писал. Но мало, не значит нет.
В любом случае в Dateno есть уже полное покрытие всех стран именно за счёт данных из глобальных агрегаторов.
┏━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Alpha-2 ┃ Name ┃ Internet TLD ┃
┡━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ NE │ Niger (the) │ .ne │
│ TM │ Turkmenistan │ .tm │
│ AF │ Afghanistan │ .af │
│ SD │ Sudan (the) │ .sd │
│ SL │ Sierra Leone │ .sl │
│ KN │ Saint Kitts and Nevis │ .kn │
│ ER │ Eritrea │ .er │
│ KM │ Comoros (the) │ .km │
│ SM │ San Marino │ .sm │
│ SY │ Syrian Arab Republic (the) │ .sy │
│ CF │ Central African Republic (the) │ .cf │
│ GQ │ Equatorial Guinea │ .gq │
│ GA │ Gabon │ .ga │
│ GW │ Guinea-Bissau │ .gw │
│ VC │ Saint Vincent and the Grenadines │ .vc │
│ GN │ Guinea │ .gn │
│ SZ │ Eswatini │ .sz │
│ TD │ Chad │ .td │
│ GD │ Grenada │ .gd │
│ MC │ Monaco │ .mc │
│ KP │ Korea (the Democratic People's Republic of) │ .kp │
│ ST │ Sao Tome and Principe │ .st │
│ DJ │ Djibouti │ .dj │
│ TL │ Timor-Leste │ .tl │
├─────────┼────────────────────────────────────────────────┼──────────────┤
│ Total │ 24 │ │
└─────────┴────────────────────────────────────────────────┴──────────────┘
Про уход Notion из России, это, увы, неизбежное и в большинстве уходов хуже всего то по каким критериям большая часть сервисов определяют российскую аффиляцию. Какое-то время назад я переписывался с JetBrains по поводу использования их продукта и задавал им вопросы по поводу использования их продукта не в РФ и может ли компания использовать продукт если кто-то из команды будет иметь доступ к нему из РФ. Ответ был - нет, не может.
То есть даже если компания зарегистрирована в Казахстане или Армении, если даже там работает большая часть команды, в команде есть кто-то кто даже если изредка, но работает из РФ, например, приезжая к родственникам, это может рассматриваться как нарушение условий использования сервиса. Потому что дословно "ни один сотрудник не имеет права использовать продукт из России".
В этом проблема и с Notion, в этом могут быть будущие проблемы с использованием Google Workspace и других популярных сервисов, хостинга и тд, просто по критериям блокировки использования по подключению из сетей аффилированных с РФ.
У практически всех популярных онлайн сервисов много альтернатив, лично я надеюсь что больше развития получат open source продукты по модели local-first.
#tools #sanctions #opensource
В рубрике интересных малоизвестных проектов по публикации данных WMO Information System (WIS) 2.0 [1] проект Всемирной метеорологической организации по стандартизированному и систематизированному сбору данных о местной погоде от национальных метеорологических агентств. WIS 2.0 представляет собой набор стандартов по предоставлению данных и для упрощения работы по стандартам WMO предоставляет открытое и бесплатное ПО WIS 2 in a box [2] в которое поступает данные со станций метеонаблюдения и данные предоставляются в виде OGC API (стандарт геоданных) через встроенный внутрь движок pygeoapi [3].
Все публикуемые в WIS 2.0 in a box стандартизированы, там всего несколько коллекций: метаданные, станции, уведомления о данных и ежечасные синоптические наблюдения.
Большая часть инсталляций WIS 2.0 in a box общедоступны, но и не очевидно может быть где найти, но и это не так сложно, если захотеть.
Вот примеры серверов с WIS 2 in a box:
- США https://wis2node.nws.noaa.gov
- Белиз https://wis.nms.gov.bz
- Казахстан https://wis2box.kazhydromet.kz
- Россия http://wis2box.mecom.ru
- Китай https://wis2node.wis.cma.cn/
И так далее, таких инсталляций довольно много, что делает pygeoapi одним из довольно популярных движков для публикации геоданных.
P.S. Мне так и не удалось найти инсталляции WIS 2.0 in a box в Армении, возможно его там и нет, а данные передаются каким-то другим образом. Как я помню, синоптические данные в странах СНГ собирались через Росгидромет.
Ссылки:
[1] https://community.wmo.int/en/activity-areas/wis
[2] https://docs.wis2box.wis.wmo.int/en/1.0b7/index.html
[3] https://pygeoapi.io/
#opendata #datacatalogs #geodata #datasets #synoptic #weather
В качестве мини-хобби, очень мини, я время от времени систематизирую ссылки по темам в жанре awesome list на Github с некоторой надеждой что над этими списками не я один буду работать. Надежды, как правило, не оправдываются, за редким исключением.
Список Awesome Digital Preservation, за время существования всего 14 лайков. У цифровой архивации мало фанатов, увы.
Или, например, у меня есть список Awesome Open Data software с ПО и стандартами по работе с открытыми данными. Почти всё ПО из реестра каталогов данных в Dateno, плюс ссылки на форматы файлов и стандарты обмена данными. Звездочек маловато, всего 24, не самая популярная тема.😜
Или вот Awesome Data Takeout со ссылками на сервисы получения всех своих данных из онлайн сервисов. 54 звезды, тоже, очень мало.
Для дата журналистов Awesome data journalism со списками инструментов для визуализации и не только. Набрало, 178 звезд, давно не обновлялось.
Russian Awesome Open data каталог источников открытых данных по РФ. Составлялся очень давно, как-то собрал 200 звездочек, уже практически не пополняется. Вместо него развивали datacatalogs.ru
Побольше в Awesome Forensic Tools с подборкой ресурсов в задачах цифрового дознания. Набрало 472 лайка при том что я почти не прилагал усилий по его пополнению, только один раз собрал всё вместе.
И, наконец, Awesome Status Pages собравшее 2738 лайков. Активное настолько что утомляет, сплошным потоком разработчики создают очередные сервисы проверки и публикации статусов сервисов и используют всякую маркетинговую мишуру чтобы их продвинуть. Дважды предлагали выкупить у меня эту страницу. Чувствую зря я её не продал;)
В общем-то по настоящему выстрелило только последнее, хотя списки составлять я лично люблю. Списки это же частный вид таблицы, можно ещё жанр завести. Awesome table of <something>, но в форматы Github'а или Telegram'а они плохо укладываются. Но может найдется близкий интересный формат
#opendata #datajournalism #data #digitalforensics #readings #thoughts
На днях я накатывал очередной обновление реестра каталогов данных, Dateno registry [1] тот самый который раньше был Common Data Index, а потом стал ядром поисковика по данным.
Важно то что он сам по себе также является продуктом, открытым, бесплатным, под свободной лицензией как база источников открытых и общедоступных данных. Самое очевидное применение его разработчиками национальных порталов открытых данных для агрегации на них данных с региональных, муниципальных и других порталов своей страны.
Некоторые цифры реестра видны на сайте, а некоторые можно подсчитать поработав в этим датасетом напрямую. Такие цифры на сегодня.
По типам каталогов данных
- 10 099 каталогов данных всего, из них:
— 5944 каталога геоданных
— 2732 портала открытых данных
— 871 репозиторий научных данных
— 276 каталогов индикаторов
— 276 всех остальных каталогов данных
По точкам подключения к API
- 35 404 точек подключения к API 99 различных типов API
По внешним идентификаторам:
- 777 идентификаторов каталогов данных в других источниках таких как re3data, datacatalogs.org, roar, wikidata и других
По используемому ПО:
- 119 типов ПО каталогов зарегистрировано
- 89% каталогов внесены с идентификацией типа ПО и только 11 процентов как отдельная разработка
По предметным областям
- 2158 каталогов имеют тематическую привязку в виде хотя бы одной темы, это около 21% всех каталогов данных
Это самый крупный каталог источников данных на сегодняшний день, сравнимый только с re3data и fairsharing, но они используются только для научных баз данных.
А наибольшие ограничения у реестра сейчас в том что у 66% каталогов данных не указан тип владельца и у 15% не идентифицирована страна к которой каталог относится. Если страну ещё можно идентифицировать по доменной зоне, то тип владельца каталога определяется, пока, только вручную. А приоритет ручной проверки проставлен от числа наборов данных в каталоге. Если в поисковый индекс Dateno попадает источник где есть более 1000 наборов данных то он становится кандидатом для ручной проверки и обновления метаданных.
И это, напомню, цифры именно по реестру каталогов данных. Потому что по индексируемым датасетам статистика совсем другая.
Ссылки:
[1] https://dateno.io/registry
#opendata #data #datasets #datacatalogs
Полезные ссылки про технологии, данные и не только:
- Top Programming Languages 2024 [1] от IEEE Spectrum, для интриги не назову языки лидеры. Но всё очевидно:)
- GCSE results 2024: The main trends in grades and entries [2] лонгрид про данные результатов британского экзамена GCSE от Education Datalab.
- New Washington Post AI tool sifts massive data sets [3] в Axios о том что у Washington Post новый ИИ инструмент для просеивания данных, через него уже прогнали базу видеороликов кандидатов в президенты [4].
- Using Perplexity to prepare to job interview [5] автор описывает инструкции и шаблон промпт по подготовке к интервью компании на основании описания вакансии. Эта идея имеет больше глубины чем кажется на первый взгляд. Применимо не только к подготовке к интервью, но и в принятии решения откликаться ли на вакансию.
- Benchmarking energy usage and performance of Polars and pandas [6] сравнение энергопотребления при использовании Polars и Pandas. Интересен сам факт сравнения, но объекты сравнения подобраны плохо. Сравнивать надо с теми же движками что применялись в 1 billion rows challenge, а не вот так. Pandas уже какое-то время рассматривается как референсный продукт, хуже которого быть нельзя в части скорости работы с данными.
- No, 80% of data isn’t spatial (and why that is a good thing) [7] автор опровергает, вернее, пытается опровергнуть тот факт что 80% датасетов это геоданные. Нууу, вот тут то можно и поспорить. Количественно точно не 80%. А вот качественно, вернее объёмно по хранению... До того как объёмы геномных данных не начали накапливаться десятками петабайтов, а это где-то лет 5 назад началось, геоданные, с учётом данных наук о Земле, могли по объёму быть и более 80%. Сейчас я думаю что геномные данные составляют не менее 50%: данных.
Ссылки:
[1] https://spectrum.ieee.org/top-programming-languages-2024
[2] https://ffteducationdatalab.org.uk/2024/08/gcse-results-2024-the-main-trends-in-grades-and-entries/
[3] https://www.axios.com/2024/08/20/washington-post-ai-tool-data
[4] https://www.washingtonpost.com/elections/interactive/2024/republican-campaign-ads-immigration-border-security/
[5] https://www.linkedin.com/posts/patleomi_i-just-unlocked-a-really-cool-new-use-case-activity-7232456130281549825-onDm
[6] https://pola.rs/posts/benchmark-energy-performance/
[7] https://www.spatialstack.ai/blog/no-80-of-data-isn-t-spatial-and-why-that-is-a-good-thing
#data #ai #geodata #readings
К вопросу об обработке данных с минимальным футпринтом (потреблением памяти оперативной и при хранении). Я добавил к библиотеке iterable пример по обработке дампов Википедии [1].
Для тех кто не сталкивался ранее, Фонд Викимедия обеспечивает открытость всех вариантов Википедии на сайте дампов [2] где они доступны в виде файлов SQL для загрузки в MySQL совместимые СУБД сжатых GZip и в виде дампов XML сжатых Bzip2. Если хочется поработать с этими данными локально, то надо или воссоздавать SQL базу данных из SQL файлов или работать с большими XML документами внутри которых страницы и другие объекты. Размер этих XML документов может быть весьма велик, до десятков гигабайт и обрабатывать их DOM парсерами весьма накладно.
Для некоторых задач Dateno мне нужны дампы Википедии, так чтобы к ним можно было строить запросы, но без желания воспроизводства инфраструктуры с MySQL и, в целом, хочется обрабатывать их оптимизировано.
Поэтому в примере выше использование библиотеки iterable для преобразования одной из маленьких Wiki (simplewiki) с дампом в 308MB в формате xml.bz2.
Идея в том чтобы:
1. Превратить его в формат для работы с помощью DuckDB
2. Сохранить минимально возможный объем для локального хранения, обработки и анализа.
3. Иметь возможность проделывать вме это на десктопе и с минимальным потреблением оперативной памяти.
В итоге пример можно посмотреть в репозитории. Два скрипта.
- convert.py преобразует xml.bz2 файл в jsonl.zst.
- enrich.py добавляет в полученный файл дополнительные метаданные по категориям вики страниц.
Почему jsonl и zst ? Потому что DuckDB умеет этот формат. После преобразования можно работать с ним напрямую без доп. преобразований.
Итог:
1. Сжатый XML дамп в 308MB преобразуется в сжатый JSONl файл в 325 MB
2. Время преобразования на простом десктопе порядка 2 минут.
3. С итоговым результатом можно работать как с базой данных DuckDB и делать запросы.
Еще лучше было бы будь возможность преобразовать в parquet, но и такой вариант пригоден к дальнейшей работе. К тому же parquet наиболее эффективен на хорошо сжимаемых колонках, а тут много викитекста для которого колоночное сжатие того же эффекта не несёт.
Пример на то и пример чтобы продемонстрировать саму идею. Simplewiki небольшая вики и на русскоязычной или испаноязычной википедиях процесс займёт дольше времени, но всё это демонстрация того что с этими данными можно работать локально и с удобными инструментами.
P.S. Если кто-то знает хорошие движки и примеры быстрого преобразования викидампов в компактные локальные базы данных, поделитесь плз.
Ссылки:
[1] https://github.com/apicrafter/pyiterable/tree/main/examples/simplewiki
[2] https://dumps.wikimedia.org
#dataengineering #datatools #opendata #wikipedia
Кстати, помните я расхваливал китайский портал/агрегатор научных данных SciDb [1].
Так вот его можно не только хвалить. После некоторого исследования его содержания он на 100% соответствует подходу "главное не быть, а казаться". Из заявленных 10 миллионов наборов данных лишь 18 тысяч имеют присоединённые файлы и загружены через сам портал, ещё 754 тысячи собраны из нескольких больших открытых порталов научных данных таких как Zenodo и PANGAEA, а всё остальное - это просто слепок поискового индекса по данным DataCite, сильно замусоренного и, объективно, без значимых метаданных, да и не факт что ссылки на сами данные.
С одной стороны, как обидно, так мало данных. С другой стороны, очередное подтверждение приоритетов индексирования и то что из SciDB можно собирать только те данные что туда были загружены. Другой вопрос что отфильтровать их непросто.
В любом случае удивительно то что вместо индексации тех же геномных данных китайцы пошли по этому пути.
Ссылки:
[1] https://www.scidb.cn
#opendata #china #datasets #datacatalogs
Один из крупнейших проектов с большими научными данными - это Китайский национальный центр биоинформации через сайт которого доступно более 53 Петабайт геномных данных [1]. Причём в августе 2021 года их было всего 5 Петабайт и сейчас можно наблюдать 10-кратный рост за 3 года. Такими темпами к концу 2025 года будут все 100 Пб.
Внутри центра много разных баз данных и архивов, от нескольких терабайт, до десятка петабайт. Все данные доступны в форматах специфичных в для биоинформатики и геномных исследований.
Часть этих данных полностью открытые и их можно сразу скачать через FTP или HTTP интерфейсы, часть требуют процедуры получения доступа через профильный комитет доступа к данным Data Access Committee(DAC) [2].
Ссылки:
[1] https://www.cncb.ac.cn/services
[2] https://ngdc.cncb.ac.cn/gsa-human/browse/HRA002875
#opendata #china #data #genomics #bigdata
Почему я в последнее время много думаю и пишу про геоданные?
Есть 4 основных типов общедоступных данных данных которые собираются в Dateno:
- открытые данные (opendata). С ними всё довольно понятно, их много, не не бесконечно много. Большая часть порталов известны, далее просто длительная методическая работа по их систематизации и сбору датасетов
- научные данные. Тут не всё так понятно, и этих данных по объёму более всего в мире, но в каждой науке свои виды каталогов данных, стандарты и тд. За пределами отдельных научных дисциплин у этих данных не так много пользы
- статистика и индикаторы. Нужны всем, чаще стандартизированы, поддаются систематизированному сбору и "расщепляются" на множество поддатасетов в привязке к конкретным странам и территориям. Много усилий требуется по агрегации национальных каталогов статистики.
- геоданные. Их много, чаще стандартизированы, но поиск и каталогизация явно недостаточны. Предыдущие попытки чаше безуспешны.
Остальные типы данных - это данные для машинного обучения, данные из коммерческих маркетплейсов или датасеты из порталов микроданных (социология), все они сильно меньше количественно.
Существенный количественный рост данных в Dateno будет от трёх категорий: научные данные, данные индикаторов и геоданные.
При этом научные данные можно _очень быстро_ загрузить из 3-4 крупных источников и это добавит +20 млн датасетов и создаст огромные пузыри данных по нескольким языкам, категориям и темам.
Данные индикаторов стремительно превратят Dateno в портал по макроэкономике/макростатистике. Их также можно загрузить +5 млн датасетов в короткое время.
А в агрегированных геоданных сейчас есть объективный "пузырь", огромное число датасетов по Германии отчего в любом поисковике по данным доля геоданных их Германии достигает 40-60% от общего числа. Если не больше.
Конечно, в какой-то момент, можно перестать думать про этот баланс и залить в Dateno несколько десятков миллионов датасетов и уже потом заниматься вопросами качества индекса. Так, например, сделали в агрегаторах научных данных типа SciDb и OpenAIRE. Там очень много мусора который создаёт количество датасетов, но который и почти не найдёшь потому что эти мусорные данные даже не подпадают под фасеты. В общем-то там ставка однозначно сделана на количество датасетов, а в этом смысле нет проблемы достигнуть того же.
#opendata #data #dateno #thoughts #geodata
В рубрике как это устроено у них раскрытие данных в штате Нью Джерси, США. Раскрытие данных в штате осуществляется в рамках
NJ Geographic Information Network [1] проекте основанном NJOGIS (New Jersey Office of GIS).
В рамках этого проекта публикуются геоданные штата, начиная с информации о дорогах, кадастровых участках и иных данных большая часть которых доступна через портал в облаке ArcGIS [3], а также на сайте проекта публикуются изображения аэрофотосъёмки c 1920 по 2020 годы [4] доступные, как в виде сервисов по стандарту WMS, так и данных для массовой выгрузки.
Что может показаться необычным, но, на самом деле, уже становится стандартным способом раскрытия многих данных, так это то что все крупные датасеты предоставляются не только для выгрузки по прямым ссылкам, но и изнутри инфраструктуры Amazon AWS с помощью их утилиты для командной строки.
Общий объём данных измеряется десятка терабайт, начиная от простых CSV таблиц, до большого числа GeoTIFF файлов оптимизированных для облаков.
Ссылки:
[1] https://njgin.nj.gov
[2] https://njgin.nj.gov/njgin/about/ogis/
[3] https://njogis-newjersey.opendata.arcgis.com/
[4] https://njgin.nj.gov/njgin/edata/imagery/index.html
#opendata #usa #datasets #geodata #datacatalogs
В рубрике как это устроено у них национальный портал открытых данных Германии GovData.de [1] включает более 117 тысяч наборов данных, большую часть которых агрегируют из региональных порталов открытых данных отдельных территорий и городов, более всего, 28 тысяч из земли Schleswig-Holstein, но и остальные данные чаще региональные и хорошо обновляемые. Федеральный портал стремительно пополняется, ещё несколько месяцев назад там было около 88 тысяч наборов данных.
Внутри портала работает CKAN, поверх него сделан интерфейс с помощью Liferay.
Особенность портала в том что на нём далеко не все открытые данные Германии и на портале данных ЕС имеется 726+ тысяч наборов данных. Остальные 609 тысяч наборов данных собираются из каталога геоданных Германии GDI.
В Dateno тоже есть данные по Германии и основные данные не с госпортала GovData, а как раз с геопорталов отдельных земель. Собственно обилие данных по Германии даёт значительное искажение картины доступности данных по Западной Европе в Европейском портале и в Dateno. Что вызвано тем что данных в Германии, действительно, раскрывается очень много и тем что нужно больше индексировать источники данных по другим европейским странам.
А пока можно обратить внимание что крупные национальные порталы вроде GovData также идут по пути развития фасетного поиска. Больше интересных фильтров, больше возможности найти нужные наборы данных
Ссылки:
[1] https://www.govdata.de
#opendata #germany #europe #datasets #data
К вопросу о poor man data engineering, как обрабатывать данные в условиях ограниченных ресурсов с минимальными нагрузками на диск и на оперативную память, в первую очередь.
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
В рубрике как это устроено у них, подборка общедоступных каталогов данных Республики Беларусь:
Статистика
- http://dataportal.belstat.gov.by Портал статистических данных Белстата. Экспорт данных в XML, SDMX, XLS. Есть недокументированное API
Геоданные
- https://meta.geo.by/geoserver сервер геоданных на базе GeoServer. По умолчанию требует авторизации, но прямые ссылки на OGC API доступны
- https://gisoopt.by/arcgis/rest/services - ArcGIS сервер национального парка Нарочанский
- https://oopt.gis.by/arcgis/rest/services/ - ArcGIS сервер Национальной академии геоинформационных систем
- https://gis.maps.by/arcgis/rest/services/ - ArcGIS сервер Госкартгеоцентра
- https://vitebsk.gismap.by/arcgis/rest/services - ArcGIS сервер с геоданными Витебска
Государственного портала открытых данных в РБ никогда не существовало.
Общественный портал opendata.by закрылся несколько лет назад.
#opendata #datacatalogs #belarus #data