Geoexplorer Berlin [1] сервис навигации по геоданным Берлина, интерфейс над их каталогом данных на базе Geonetwork.
Отличительная особенность в интеграции ChatGPT в интерфейс и это выражается в генерации описания того зачем нужен конкретный датасет, дословно: "На какие вопросы отвечает этот датасет?" и в автодокументировании данных. А также в поиске по данным на естественном языке. Немецком языке, конечно же.
Данных там немного, но функции любопытные. Есть что изучить и применить.
Разработано в Technologie Stiftung Berlin [2], открытый код под лицензией MIT [3]
Ссылки:
[1] https://geoexplorer.odis-berlin.de/
[2] https://www.technologiestiftung-berlin.de/
[3] https://github.com/technologiestiftung/odis-geoexplorer
#opendata #geodata #datasets #ai #opensource #germany #berlin
Отличительная особенность в интеграции ChatGPT в интерфейс и это выражается в генерации описания того зачем нужен конкретный датасет, дословно: "На какие вопросы отвечает этот датасет?" и в автодокументировании данных. А также в поиске по данным на естественном языке. Немецком языке, конечно же.
Данных там немного, но функции любопытные. Есть что изучить и применить.
Разработано в Technologie Stiftung Berlin [2], открытый код под лицензией MIT [3]
Ссылки:
[1] https://geoexplorer.odis-berlin.de/
[2] https://www.technologiestiftung-berlin.de/
[3] https://github.com/technologiestiftung/odis-geoexplorer
#opendata #geodata #datasets #ai #opensource #germany #berlin
В рубрике как это устроено у них данные кадастра Франции доступны как открытые данные для массовой выгрузки (bulk download) [1] их можно скачать в форматах EDIGEO, DXF или TIFF и использовать в собственных приложениях. Особенность в том что доступны они не через API, а в виде сжатых файлов которые можно скачать одномоментно. Общий объём данных несколько десятков, может быть даже сотен гигабайт в сжатом виде. А также доступны регулярные полные слепки кадастра начиная с февраля 2017 года.
Ссылки:
[1] https://cadastre.data.gouv.fr/
[2] https://cadastre.data.gouv.fr/data/dgfip-pci-vecteur/2024-07-01/edigeo/feuilles/
#opendata #france #datasets #data #cadastre #land
Ссылки:
[1] https://cadastre.data.gouv.fr/
[2] https://cadastre.data.gouv.fr/data/dgfip-pci-vecteur/2024-07-01/edigeo/feuilles/
#opendata #france #datasets #data #cadastre #land
Ещё немного про всякое сугубо техническое, сейчас в Dateno постепенно идёт переход от индексирования тысяч маленьких порталов с общедоступными данными и метаданными, к охвату крупных каталогов. Ключевое отличие таких крупных каталогов данных в том что необходимо писать скрейперы под каждый индивидуально, а это хоть и несложно, но означает увеличение кода скрейпинга многократно что постепенно будет усложнять сопровождение кода и так далее. Но это не проблема, это вполне измеримая техническая задача.
Что сложнее так то что многие из таких крупных каталогов данных - это базы индикаторов. Часть из них написаны на типовом ПО, большая часть на нетиповом, но что характерно для большей части таких каталогов так то что сбор метаданных и данных (значений) индикаторов по трудоёмкости почти не различаются
Это сильно отличает такие порталы от порталов открытых или научных данных, где выкачать метаданные можно быстро и они имеют относительно разумные размеры, а вот данных могут быть там сотни гигабайт и терабайт, их сбор и обработка уже сложнее.
А в случае индикаторов, хорошие владельцы таких баз данных всё чаще дают возможность выкачать их целиком в режиме bulk download. Как минимум это ECB, Eurostat, FAO, Ilostat и ещё многие. Данные там почти всегда CSV или сжатые CSV и вот тут то срабатывает магия инструментов вроде duckdb. Во всех ситуациях когда CSVшки в кодировке utf8 и имеют предсказуемые схемы данных, с помощью duckdb можно многократно ускорять их обработку заменяя обработку через датафреймы на прямые SQL запросы к CSV, даже без копирования данных в БД и не строя ни одного индекса.
В общем могу сказать что в роли "дешёвого ETL инструмента для бедных" duckdb работает прекрасно. К примеру DISTINCT по разреженному полю по CSV файлу в 15GB и 22 миллиона записей без индекса отрабатывается на 19.8 секунд. Это в режиме когда совсем без оптимизаций, без преобразований в parquet. А если в parquet преобразовать то, ожидаемо, DISTINCT отрабатывает за 0.5 секунд. Выбор очевиден 🛠 надо использовать!
Например, про данные из другого проекта, если кто-то надумает использовать данные по госконтрактам [1], то они вполне себе читаются с помощью duckdb особенно после преобразований в parquet. Например, jsonl файл с госзаказчиками вполне себе легко преобразуется в parquet после всего операции по преобразованиям занимают сотые доли секунд. В этом смысле единственный недостаток открытых данных из Госзатрат только в том что они сжаты в zip, а если сжать их в gz или публиковать в parquet, то можно ещё и ускорить подготовку данных.
Таких примеров много, главный вывод в том что можно удешевить ресурсные требования во многих задачах и многие R&D задачи решать без дополнительных серверных ресурсов, экспериментируя локально.
Ссылки:
[1] https://clearspending.ru/opendata/
#duckdb #tech #dataengineering #etl
Что сложнее так то что многие из таких крупных каталогов данных - это базы индикаторов. Часть из них написаны на типовом ПО, большая часть на нетиповом, но что характерно для большей части таких каталогов так то что сбор метаданных и данных (значений) индикаторов по трудоёмкости почти не различаются
Это сильно отличает такие порталы от порталов открытых или научных данных, где выкачать метаданные можно быстро и они имеют относительно разумные размеры, а вот данных могут быть там сотни гигабайт и терабайт, их сбор и обработка уже сложнее.
А в случае индикаторов, хорошие владельцы таких баз данных всё чаще дают возможность выкачать их целиком в режиме bulk download. Как минимум это ECB, Eurostat, FAO, Ilostat и ещё многие. Данные там почти всегда CSV или сжатые CSV и вот тут то срабатывает магия инструментов вроде duckdb. Во всех ситуациях когда CSVшки в кодировке utf8 и имеют предсказуемые схемы данных, с помощью duckdb можно многократно ускорять их обработку заменяя обработку через датафреймы на прямые SQL запросы к CSV, даже без копирования данных в БД и не строя ни одного индекса.
В общем могу сказать что в роли "дешёвого ETL инструмента для бедных" duckdb работает прекрасно. К примеру DISTINCT по разреженному полю по CSV файлу в 15GB и 22 миллиона записей без индекса отрабатывается на 19.8 секунд. Это в режиме когда совсем без оптимизаций, без преобразований в parquet. А если в parquet преобразовать то, ожидаемо, DISTINCT отрабатывает за 0.5 секунд. Выбор очевиден 🛠 надо использовать!
Например, про данные из другого проекта, если кто-то надумает использовать данные по госконтрактам [1], то они вполне себе читаются с помощью duckdb особенно после преобразований в parquet. Например, jsonl файл с госзаказчиками вполне себе легко преобразуется в parquet после всего операции по преобразованиям занимают сотые доли секунд. В этом смысле единственный недостаток открытых данных из Госзатрат только в том что они сжаты в zip, а если сжать их в gz или публиковать в parquet, то можно ещё и ускорить подготовку данных.
Таких примеров много, главный вывод в том что можно удешевить ресурсные требования во многих задачах и многие R&D задачи решать без дополнительных серверных ресурсов, экспериментируя локально.
Ссылки:
[1] https://clearspending.ru/opendata/
#duckdb #tech #dataengineering #etl
Полезное чтение про данные технологии и не только:
- Querying 1TB on a laptop with Python dataframes [1] статья от разработчиков обёртки для систем управления запросами к базам данных Ibis про обработку 1TB данных в виде адаптированного бенчмарка TPC-H на ноутбуке с помощью разных движков для датафреймов. Надо правда оговорится что ноутбук там не абы какой а MacBook Pro с 96GB RAM, но это не отменяет того факта что RAM в 10 раз меньше чем обрабатываемых данных. Главный вывод - duckdb выше всяких похвал, единственный движок который отработал все запросы до конца.
- Whenever [2] свежая библиотека для работы с датами и временем в Python, изначально написана на Rust. Помимо того что очень быстро работает и это очень актуально при обработке больших объёмов данных, она ещё и всегда учитывает переход на летнее время.
- datawizard: Easy Data Wrangling and Statistical Transformations [3] пакет для R для манипуляции данными. Казалось бы вопрос, кто сейчас пользуется R для таких задач? Но точно пользуются и для тех кто это делает такой пакет может оказаться очень полезным.
- Confronting Impossible Futures [4] полезное чтение о том что развитие, в том числе любой сценарий развития ИИ, необходимо учитывать в корпоративных стратегиях. Несмотря на то что всё ещё идёт продолжающийся взлёт хайпа вокруг этой темы, будет ещё много событий которые могут создать новые бизнес модели, сломать имеющиеся и тд.
- Applied forecasting [5] открытый курс по прикладному прогнозированию. Видео, слайды, примеры на R, выглядит достаточно просто чтобы садиться за изучение и достаточно сложно чтобы курс был интересным.
- Questionable practices in machine learning [6] а теперь дети запомните слова которые нельзя говорить (с) статья про спорные практики в машинном обучении. Большая их часть возникает от того что где-то не подумали, где-то ошиблись, где-то нехватает практического/теоретического знания у ML разработчиков, но есть и те которые нельзя сотворить случайно. Статья полезная, больше про технологии чем про этику и про автоматизацию контроля качества ML моделей.
- The biggest-ever global outage: lessons for software engineers [7] подробный разбор ситуации с недоступностью миллионов компьютеров на базе Windows из-за антивируса CrowdStrike и того какие выводы из неё можно извлечь. Многое не только про эту историю с CrowdStrike, но и предыдущие проблемы с их антивирусом и другие примеры больших сбоев других софтверных вендоров.
- TabularFM: An Open Framework For Tabular Foundational Models [8] открытый код, научная статья и модели на HuggingFace по извлечению смысла из табличных данных. Это, конечно, упрощённое описание того что такое Tabular Foundation Model, но можно сказать что это применение нейросетей к табличным данным.
Ссылки:
[1] https://ibis-project.org/posts/1tbc/
[2] https://github.com/ariebovenberg/whenever
[3] https://easystats.github.io/datawizard/index.html
[4] https://www.oneusefulthing.org/p/confronting-impossible-futures
[5] https://af.numbat.space/
[6] https://arxiv.org/abs/2407.12220
[7] https://newsletter.pragmaticengineer.com/p/the-biggest-ever-global-outage-lessons
[8] https://www.semanticscholar.org/paper/TabularFM%3A-An-Open-Framework-For-Tabular-Models-Tran-Hoang/977fec09a458fe326e5059774e3f05ab695acf2a
#readings #ai #data #opensource
- Querying 1TB on a laptop with Python dataframes [1] статья от разработчиков обёртки для систем управления запросами к базам данных Ibis про обработку 1TB данных в виде адаптированного бенчмарка TPC-H на ноутбуке с помощью разных движков для датафреймов. Надо правда оговорится что ноутбук там не абы какой а MacBook Pro с 96GB RAM, но это не отменяет того факта что RAM в 10 раз меньше чем обрабатываемых данных. Главный вывод - duckdb выше всяких похвал, единственный движок который отработал все запросы до конца.
- Whenever [2] свежая библиотека для работы с датами и временем в Python, изначально написана на Rust. Помимо того что очень быстро работает и это очень актуально при обработке больших объёмов данных, она ещё и всегда учитывает переход на летнее время.
- datawizard: Easy Data Wrangling and Statistical Transformations [3] пакет для R для манипуляции данными. Казалось бы вопрос, кто сейчас пользуется R для таких задач? Но точно пользуются и для тех кто это делает такой пакет может оказаться очень полезным.
- Confronting Impossible Futures [4] полезное чтение о том что развитие, в том числе любой сценарий развития ИИ, необходимо учитывать в корпоративных стратегиях. Несмотря на то что всё ещё идёт продолжающийся взлёт хайпа вокруг этой темы, будет ещё много событий которые могут создать новые бизнес модели, сломать имеющиеся и тд.
- Applied forecasting [5] открытый курс по прикладному прогнозированию. Видео, слайды, примеры на R, выглядит достаточно просто чтобы садиться за изучение и достаточно сложно чтобы курс был интересным.
- Questionable practices in machine learning [6] а теперь дети запомните слова которые нельзя говорить (с) статья про спорные практики в машинном обучении. Большая их часть возникает от того что где-то не подумали, где-то ошиблись, где-то нехватает практического/теоретического знания у ML разработчиков, но есть и те которые нельзя сотворить случайно. Статья полезная, больше про технологии чем про этику и про автоматизацию контроля качества ML моделей.
- The biggest-ever global outage: lessons for software engineers [7] подробный разбор ситуации с недоступностью миллионов компьютеров на базе Windows из-за антивируса CrowdStrike и того какие выводы из неё можно извлечь. Многое не только про эту историю с CrowdStrike, но и предыдущие проблемы с их антивирусом и другие примеры больших сбоев других софтверных вендоров.
- TabularFM: An Open Framework For Tabular Foundational Models [8] открытый код, научная статья и модели на HuggingFace по извлечению смысла из табличных данных. Это, конечно, упрощённое описание того что такое Tabular Foundation Model, но можно сказать что это применение нейросетей к табличным данным.
Ссылки:
[1] https://ibis-project.org/posts/1tbc/
[2] https://github.com/ariebovenberg/whenever
[3] https://easystats.github.io/datawizard/index.html
[4] https://www.oneusefulthing.org/p/confronting-impossible-futures
[5] https://af.numbat.space/
[6] https://arxiv.org/abs/2407.12220
[7] https://newsletter.pragmaticengineer.com/p/the-biggest-ever-global-outage-lessons
[8] https://www.semanticscholar.org/paper/TabularFM%3A-An-Open-Framework-For-Tabular-Models-Tran-Hoang/977fec09a458fe326e5059774e3f05ab695acf2a
#readings #ai #data #opensource
Ibis
Querying 1TB on a laptop with Python dataframes – Ibis
the portable Python dataframe library
По моему уже все написали про новую языковую модель Llama 3.1 [1] от Meta которая больше и лучше всех остальных моделей с открытым кодом. Как минимум полезно как альтернатива сервисам OpenAI, и, в принципе, для обучения локально на собственных данных.
Ссылки:
[1] https://www.theverge.com/2024/7/23/24204055/meta-ai-llama-3-1-open-source-assistant-openai-chatgpt
#ai #opensource #llama #meta
Ссылки:
[1] https://www.theverge.com/2024/7/23/24204055/meta-ai-llama-3-1-open-source-assistant-openai-chatgpt
#ai #opensource #llama #meta
Forwarded from Open Data Armenia
У нашей команды первое расширение! Ищем активного армяноязычного координатора сообщества и партнерств в Ереване на частичную занятость. Верим, что подходящий нам человек где-то совсем рядом, так что подавайтесь сами и отправляйте знакомым, которые подходят под описание.
Вакансия целиком: https://opendata.am/2024/07/20/job-opening-community-and-partnerships-coordinator/.
Вакансия целиком: https://opendata.am/2024/07/20/job-opening-community-and-partnerships-coordinator/.
Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
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
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
Статистическая служба Малайзии внедряет AI Helper [1] в сайт для разработчиков прилагаемый к их порталу статистических данных. На простые вопросы вполне эффективно отвечает и даже умеет генерировать код для языков разработки которых нет в примерах на сайте. На сайте сейчас все примеры на Python и R, но можно получить код для Java сделав такой запрос к AI Helper'у.
В данном случае применение ИИ гос-вом самое что ни на есть безобидное.
Ссылки:
[1] https://developer.data.gov.my/#using-the-ai-helper
#opendata #ai #statistics #malaysia
В данном случае применение ИИ гос-вом самое что ни на есть безобидное.
Ссылки:
[1] https://developer.data.gov.my/#using-the-ai-helper
#opendata #ai #statistics #malaysia
В рубрике закрытых данных в РФ Департамент транспорта Москвы ограничил доступ к реестру легковых такси [1], он доступен только с заполнение ГРЗ и вводом каптчи.
Ранее реестр такси был доступен в виде таблицы на сайте мэрии Москвы mos.ru
В отличие от других данных здесь меньше вероятность применения государственной цензуры и куда больше вероятность сокрытия персональных данных.
Причём произошло это примерно год назад.
Правда ещё есть реестр такси Московской области объединённый с реестром такси Москвы [2], но формально он реестром такси Москвы не является.
Что первично, раскрытие данных или приватность? В РФ до недавних пор было первое, в ЕС приватность чаще на первом месте.
Ссылки:
[1] https://transport.mos.ru/auto/reestr_taxi
[2] https://mtdi.mosreg.ru/taxi-cars
#opendata #closedata #taxi #moscow #moscowregion #privacy
Ранее реестр такси был доступен в виде таблицы на сайте мэрии Москвы mos.ru
В отличие от других данных здесь меньше вероятность применения государственной цензуры и куда больше вероятность сокрытия персональных данных.
Причём произошло это примерно год назад.
Правда ещё есть реестр такси Московской области объединённый с реестром такси Москвы [2], но формально он реестром такси Москвы не является.
Что первично, раскрытие данных или приватность? В РФ до недавних пор было первое, в ЕС приватность чаще на первом месте.
Ссылки:
[1] https://transport.mos.ru/auto/reestr_taxi
[2] https://mtdi.mosreg.ru/taxi-cars
#opendata #closedata #taxi #moscow #moscowregion #privacy
Reddit выпилился из всех поисковых систем кроме Google [1], а в гугле он до сих пор только из-за AI сделки которую они заключили. Правда мне не удалось воспроизвести это с Bing, но получилось с Яндексом. Такое ощущение что в индексе Яндекса остались только ссылки на сообщества и без описаний.
Это всё про будущее контентных проектов наглядно. Крупные контентные проекты будут банить не только AI краулеры, а все поисковые краулеры которые им не платят. В какой-то момент рекламная модель существования поисковиков может начать ломаться (а может уже ломается?)
Ссылки:
[1] https://9to5google.com/2024/07/24/reddit-search-engine-block-google-deal/
#search #ai #reddit
Это всё про будущее контентных проектов наглядно. Крупные контентные проекты будут банить не только AI краулеры, а все поисковые краулеры которые им не платят. В какой-то момент рекламная модель существования поисковиков может начать ломаться (а может уже ломается?)
Ссылки:
[1] https://9to5google.com/2024/07/24/reddit-search-engine-block-google-deal/
#search #ai #reddit
Свежие результаты опроса разработчиков от Stackoverflow [1].
Если совсем коротко,то PostgreSQL + JS.
Если не совсем, то стоит посмотреть разные срезы, они показательны в том что разработчики знают и что хотят знать.
Для меня более значимо то чего там нет, а там нет многих технологий и инструментов которые, к примеру, я использую и которые наиболее популярны сейчас в работе с данными. Это к тому что дата инженерия и аналитика отошли уже от "чистой разработки". Например, у Elasticsearch есть значимые альтернативы. Duckdb спешно набирает популярность и тд.
Ссылки:
[1] https://survey.stackoverflow.co/2024/
#software #opensource #surveys
Если совсем коротко,то PostgreSQL + JS.
Если не совсем, то стоит посмотреть разные срезы, они показательны в том что разработчики знают и что хотят знать.
Для меня более значимо то чего там нет, а там нет многих технологий и инструментов которые, к примеру, я использую и которые наиболее популярны сейчас в работе с данными. Это к тому что дата инженерия и аналитика отошли уже от "чистой разработки". Например, у Elasticsearch есть значимые альтернативы. Duckdb спешно набирает популярность и тд.
Ссылки:
[1] https://survey.stackoverflow.co/2024/
#software #opensource #surveys
Не карта, а инспектор рентгеновских данных (с)
Новый сервис от Overture Maps, консорциума по расширению данных OSM новыми инструментами и данными в виде как бы карты, но не карты [1]. В описании [2] можно узнать что он построен на динамической подгрузке geoparquet файлов из дампов данных Overture, внутри там WebAssembly с кодом на Rust, а тайлы подгружаются в форме PMTiles [3].
Штука любопытная более чем, и всё с открытым кодом.
Туда же заодно, открылась бета версия карт от Apple [4], позиционируются они явно как альтернатива Google Maps. Но Firefox не поддерживается, увы.
Ссылки:
[1] https://explore.overturemaps.org
[2] https://docs.overturemaps.org/blog/2024/07/24/explore-site/
[3] https://docs.protomaps.com/pmtiles/
[4] https://beta.maps.apple.com
#opensource #apple #maps #geodata #overture
Новый сервис от Overture Maps, консорциума по расширению данных OSM новыми инструментами и данными в виде как бы карты, но не карты [1]. В описании [2] можно узнать что он построен на динамической подгрузке geoparquet файлов из дампов данных Overture, внутри там WebAssembly с кодом на Rust, а тайлы подгружаются в форме PMTiles [3].
Штука любопытная более чем, и всё с открытым кодом.
Туда же заодно, открылась бета версия карт от Apple [4], позиционируются они явно как альтернатива Google Maps. Но Firefox не поддерживается, увы.
Ссылки:
[1] https://explore.overturemaps.org
[2] https://docs.overturemaps.org/blog/2024/07/24/explore-site/
[3] https://docs.protomaps.com/pmtiles/
[4] https://beta.maps.apple.com
#opensource #apple #maps #geodata #overture
А вот и появился настоящий, а не выдуманный "убийца Google", а заодно и других поисковых систем и, возможно, Perplexity - это SearchGPT [1], продукт который OpenAI тестирует пока на 10 тысячах пользователей.
Поломает это, правда, не только бизнес модель поиска Гугла, но и Яндекса, и потенциально столкнётся с сильным раздражением владельцев контента.
Впрочем застать при этой жизни падение монополии Google на поиск - это было бы любопытно.
Ссылки:
[1] https://www.theverge.com/2024/7/25/24205701/openai-searchgpt-ai-search-engine-google-perplexity-rival
#ai #openai #searchgpt #google #search
Поломает это, правда, не только бизнес модель поиска Гугла, но и Яндекса, и потенциально столкнётся с сильным раздражением владельцев контента.
Впрочем застать при этой жизни падение монополии Google на поиск - это было бы любопытно.
Ссылки:
[1] https://www.theverge.com/2024/7/25/24205701/openai-searchgpt-ai-search-engine-google-perplexity-rival
#ai #openai #searchgpt #google #search
На HuggingFace смешное приложение по генерации "бесконечных датасетов" [1]. Нет, сами датасеты оно не создаёт, пока что, только описания и разметку как будто они созданы.
Ссылки:
[1] https://huggingface.co/spaces/infinite-dataset-hub/infinite-dataset-hub
#ai #funny #humor #datasets
Ссылки:
[1] https://huggingface.co/spaces/infinite-dataset-hub/infinite-dataset-hub
#ai #funny #humor #datasets